承認のメールが届いたのは、日本時間の午前3時すぎでした。
そのときは「自動でリリース」を選んだまま提出していたので、私が寝ている間にストアの表示が新しいバージョンへ切り替わっていました。告知の文面はまだ下書きで、スクリーンショットの差し替えも翌日に回す予定でした。実害はありませんでしたが、順番が逆になったことだけが妙に後を引きました。
審査にかかる時間は、こちらから短くできません。ただ、審査が明けた瞬間にそのまま公開する必要はありません。承認と公開は、両ストアとも別々のスイッチとして用意されています。ここを分けておくだけで、待ち時間の読めなさが公開作業に波及しなくなります。
承認と公開は、別のスイッチになっています
まず、ふたつのストアで「何をこちらが握れるのか」を並べておきます。
| 項目 | App Store | Google Play |
|---|---|---|
| 審査の所要時間 | 開発者側で制御できません | 開発者側で制御できません |
| 承認後の公開タイミング | バージョンのリリース設定で3択 | 公開の管理（Managed publishing）の on / off |
| 設定する場所 | App Store Connect のバージョン画面 | Play Console の公開の概要 |
| 設定する単位 | バージョンごと（提出のたびに選ぶ） | アプリごと（一度入れれば継続） |
| 提出ツールとの関係 | eas submit はアップロードのみ |
eas submit の設定と噛み合わせが要ります |
いちばん見落としやすいのは最後の行です。Rork から書き出したプロジェクトを EAS で提出していると、公開のタイミングまで eas.json で決まっていそうに見えます。実際にはストア側の設定が上位にあり、片方だけ変えると噛み合わなくなります。
App Store Connect は、提出のたびに3択を選び直します
App Store Connect のバージョン画面には、リリース方法が3つ用意されています。
| 設定 | 承認後の挙動 | 向いている場面 |
|---|---|---|
| 自動的にリリース | 承認され次第、公開されます | 告知を伴わない不具合修正 |
| 手動でリリース | 「デベロッパによるリリース待ち」で止まります | 告知や他ストアと足並みを揃えたいとき |
| 指定日以降に自動リリース | 承認後、指定した日時を過ぎてから公開されます | 公開日が先に決まっているとき |
3つめは日時を自分のローカル時間で入力します。海外向けの告知と合わせる場合、ここで時差を一度計算しておかないと、意図した時間帯からずれます。
私は既定を「手動でリリース」にしています。理由は単純で、承認の連絡が来る時刻をこちらで選べないからです。深夜に承認されても、朝いちばんに自分の目でストアの表示を確認してから押せば、順番が入れ替わりません。
なお、この設定はバージョンごとに保持されるため、次のバージョンを提出するときにまた選ぶことになります。提出前チェックの項目に入れておくと取りこぼしが減ります。
Google Play は「公開の管理」を先に入れておきます
Play Console 側は、アプリ単位で 公開の管理（Managed publishing）を有効にします。有効にすると、審査を通った変更が「公開可能」の一覧に溜まり、こちらが押すまで公開されません。既定では、承認され次第そのまま公開されます。
有効にしておくと嬉しいのは、ストア掲載情報の変更とアプリ本体の更新を同時に出せることです。スクリーンショットだけ先に新しくなって、機能はまだ古い、という中途半端な状態を避けられます。
ここで、EAS で提出している場合に一度は踏む箇所があります。公開の管理を有効にしたまま eas submit を実行すると、変更を自動で審査へ送る動作とぶつかって提出が失敗します。eas.json 側で、審査へは自分で送る旨を明示しておきます。
{
"submit": {
"production": {
"android": {
"serviceAccountKeyPath": "./secrets/play-service-account.json",
"track": "production",
"releaseStatus": "completed",
"changesNotSentForReview": true
}
}
}
}changesNotSentForReview を true にすると、アップロードまでが EAS の担当になり、審査へ送る操作と公開の操作は Play Console 側に残ります。公開の管理を使うなら、この2つはセットだと考えておくと迷いません。
逆に、公開の管理を使わないアプリでこの値を true のままにすると、アップロードしたのに審査へ送られないまま止まります。テスト用のアプリと本番のアプリで設定を使い回すときは、ここだけ見直してください。
期限のある配信は、逆算の起点を審査の手前に置きます
公開日を自分で決められるようにしても、審査の所要時間そのものは不確定なままです。対象 API レベルの期限のように、外側から日付が決まっている配信では、そのぶんを見込んで逆算します。
私が実際に使っている見込みは、次の3つです。
- リジェクト1回ぶんの往復を最初から日程に入れておく。初回で通ることを前提にすると、指摘が来た時点で日程が崩れます。
- TestFlight の外部テストを先に通しておく。外部テスターへの配布にはベータ App Review が必要で、これは製品版の審査とは別の枠です。バージョンの初回ビルドで一度通しておくと、権限の説明文やメタデータのような、審査で指摘されやすい部分を前倒しで拾えます。内部テスターだけならこの審査は挟まりません。
- 提出そのものの締切を、公開希望日から数日前に置く。「この日までに出す」を決めておかないと、審査待ちの時間を微修正で食い潰します。
Android 側の期限が絡む更新については、Rork のプロジェクトで targetSdkVersion 36 を通すまでに直した3か所 に、実際に直した箇所をまとめてあります。提出まわりで番号が衝突したときは 「Version code 1 has already been used」の番号は、app.json と EAS のどちらが持っているか が近い話です。
今日のうちに変えておける設定
次の提出を待たずに済ませられるものが2つあります。
Play Console を開いて、対象のアプリで公開の管理を有効にしてください。eas submit を使っているなら、あわせて eas.json に changesNotSentForReview を足します。これはアプリ単位の設定なので、一度入れれば以降の提出に効き続けます。
App Store Connect のほうは、提出のたびに選び直す項目です。提出前の手順書に「リリース設定を手動へ」の1行を足しておくのがいちばん確実でした。
審査の列に並んでいる間、こちらにできることは多くありません。それでも、列を抜けた先の1手だけは自分の手元に残せます。公開の瞬間を選べるようになると、告知も差し替えも、慌てずに順番どおり進められるようになります。
最後までお読みいただきありがとうございました。提出まわりの段取りを整えるときの参考になれば嬉しいです。