アプリをリリースする前に確認する7項目
ビルドが通ったことと、ユーザーがストアから使えることは別です。作業を段階に分けると、どこで止まっているかが見える。
先に結論
「ビルド成功」を「リリース完了」と数えない。
ビルド、ストア処理、テスト配布、実機QA、審査情報、提出、公開後確認を別々に記録します。ひとつの画面だけで完了判定をしないのが最短ルートです。
7段階に分ける
| 段階 | 確認すること |
|---|---|
| 1. 仕様 | 主要機能、対象OS、ログイン、課金、プライバシーの範囲を確定する。 |
| 2. ローカル | 型、Lint、ビルド、主要画面の表示を確認し、再現手順を残す。 |
| 3. EAS | どのプロファイル・バージョン・ビルド番号で作ったかを記録する。 |
| 4. ストア処理 | アップロード後に処理が完了し、対象バージョンへ選択できるかを見る。 |
| 5. 実機QA | インストール、起動、主要導線、ネットワーク切替、権限、異常終了を確認する。 |
| 6. 審査情報 | 説明、スクリーンショット、連絡先、ログイン情報、審査メモを揃える。 |
| 7. 公開後 | 公開ページ、インストール、初回起動、問い合わせ導線を確認する。 |
公式情報で押さえるところ
Expo公式は、EAS BuildをExpo/React Nativeのバイナリを作るサービスと説明し、EAS Submitはストアへバイナリを送る手段として案内しています。iOSではアップロード後にApp Store Connectで処理され、TestFlightから本番公開へは別途ビルド選択と審査提出が必要です。
Expo公式：EAS Build ／ Expo公式：Submit to app stores ／ Apple公式：提出ビルドの選択
審査前に見落としやすいこと
- ログインが必要な機能に、審査用のアクセス方法がない
- バックエンドを停止したまま審査に出している
- スクリーンショットと実際のアプリの表示が違う
- テスト端末でしか起きないクラッシュを確認していない
- 公開後のサポートURLや問い合わせ先が未整備
Appleは、クラッシュやバグ、正確なメタデータ、審査用のアクセス方法、稼働中のバックエンド、実機テストを審査前の確認事項として挙げています。審査通過は保証されないため、チェック結果と未確認項目を分けて記録します。
このブログでの運用
アプリごとに「実装完了」「検証完了」「ストア処理完了」「審査提出」「公開」を別の状態で管理します。AIがコードと検証を進めても、本人のアカウント権限や実機操作が必要なゲートは、未完了のまま明記します。