eas submitでストアに提出する
ここまで、ストア側の受け皿と認証情報を用意し、productionのビルドプロファイルとsubmitプロファイルを整えました。準備は整ったので、iOSをTestFlightへ届ける流れを実際に確かめ、続いてAndroidを内部テストトラックへ届ける流れを紹介します。
iOSビルドをTestFlightに届ける
まず、提出に使うiOSビルドをproductionプロファイルで作成します（リスト4）。
eas build --platform ios --profile production
previewプロファイルが内部配布を前提とするのに対し、productionプロファイルではApp Store用の.ipaファイルを生成します。ストア提出用の署名を施した成果物になる点も違いです。
なお、iOSビルドの実行時には、クレデンシャルの生成や検証のためにAppleアカウントへのログインを促されることがあります。第9回で解説したeas credentialsと同じ仕組みがビルドの中で動いているだけなので、画面の案内に従って進めれば問題ありません。
ビルドが完了したら、作成された最新のiOSビルドをApp Store Connectへ提出します（リスト5）。
eas submit --platform ios --latest
--latestは、そのプラットフォームで最後に完了したビルドを指します。別のビルドを提出したい場合は、ビルドIDを指定する--id、ローカルファイルを指定する--path、URLを指定する--urlでも対象を選べます。
提出を実行すると、ターミナルに提出先のASC App IDや使用するAPI Key、対象ビルドのサマリーが表示され、EAS側の提出処理が始まります。ビルドのときにFreeプランで経験したような長い順番待ちはなく、筆者の環境では2分ほどで完了しました。完了メッセージには、Apple側の処理に5～10分程度かかる案内と、TestFlightページへのリンクも表示されます（図3）。
提出状況はexpo.devのプロジェクトダッシュボードでも確認できます。Submissions画面から個々の提出を開くと、ステータスや対象ビルドに加えて、ビルドの取得からApp Store Connectへのアップロードまでの処理ログも確認できます（図4）。
EAS SubmitからApp Store Connectへの提出が完了すると、App Store Connect側でビルドの処理が始まります。処理には数分～数十分かかる場合がありますが、完了するとTestFlightに提出済みのビルドが現れます（図5）。
図5でビルドがすんなり「提出準備完了」になっているのは、サンプルのapp.jsonの ios.infoPlistにITSAppUsesNonExemptEncryption: falseを設定してあるためです。この設定がない場合、暗号化技術の輸出コンプライアンスに関する質問に答えるまで、ビルドをテストに使えません。標準的なHTTPS通信しか使わないアプリなら、falseを設定しておくと提出のたびに質問に答える手間を省けます。
ここで注意したいのは、eas submitが届ける範囲はApp Store Connectまでである点です。App Storeの公開審査へ提出する操作は、App Store Connect側で行います。まずTestFlightで実機の動作を確認し、問題がないことを確かめてから審査に出す流れを推奨します。
Androidビルドをinternalトラックに届ける
Androidも同じ流れで提出できます。前章で用意したsubmit.productionプロファイルの設定を使い、最新のAndroidビルドをGoogle Playへ送ります（リスト6）。
eas submit --platform android --latest
前章の設定では、trackをinternal、releaseStatusを draftとしていました。この設定に従い、Google Playの内部テストトラックにドラフトのリリースが作成されます。Play Consoleで内容を確認し、テスターへ配布する準備を進められます。
eas submit:list で提出履歴を確認する
提出の履歴を一覧で確認するにはeas submit:listを使います（リスト7）。
eas submit:list eas submit:view <id>
eas submit:listでは、提出ID、プラットフォーム、ステータス、対象ビルド、提出日時などが新しい順に表示され、特定の1件だけ詳しく見る場合はeas submit:view <id>に提出IDを渡します。前回確認したeas build:list / eas build:viewと対になるコマンドで、ビルドは成功しているのに提出が完了していない、といった状態の切り分けに役立ちます。
EAS Submitの嬉しさは、ビルドと同じeasコマンド体系のまま、macOSやXcodeを開かずにiOSもAndroidもストアへ届けられることです。EASがなければ、プラットフォームごとに提出手段を用意し、別の道具に持ち替える必要がありました。XcodeやTransporterなど従来の提出手段にもそれぞれ確立した役割がありますが、Expoのワークフローの中で完結することがEAS Submitの本質的な価値です。
前回紹介した「マネージドFastlane」という見方も、ここでつながります。EAS Submitの内部でも、Fastlaneの deliver / supply相当の知見が活用されており、ストアごとの提出処理をEASが引き受けています。
まとめ
今回は、ビルドしたアプリをストアへ届けるための一連の流れを見てきました。最初に確認したのは、App Store ConnectやGoogle Play Consoleにアプリの受け皿を用意し、認証情報と権限を整える作業です。ここだけはEASに任せられない、人間の仕事になります。
受け皿ができたら、eas.jsonにsubmitプロファイルを定義します。提出先や認証情報、Androidのトラックなどをプロジェクトの設定として管理することで、担当者の記憶に頼らず、同じ手順を繰り返せるようになります。
iOSでは、eas submitを実行してApp Store Connectへ提出し、TestFlightにビルドが届くところまで実演しました。Androidについては、Play Consoleとサービスアカウントを準備し、内部テストトラックへ提出するまでの流れを解説するにとどめています。どちらも同じeasコマンド体系で扱えることが、EAS Submitの嬉しさです。
前回の「ビルドの民主化」に続き、今回は「リリース作業の民主化」です。かつて専任のリリース担当者に集まりがちだった提出作業が、eas.jsonとコマンドによる再現可能な手順になりました。個人や小さなチームでも、ストアへ届ける流れを共有しやすくなります。
次回（第12回）は、ストアに届ける流れをさらに便利にする話題を扱います。ビルドの成功を待って自動で提出まで進めるeas build --auto-submitと、ストアの説明文やキーワードをコードとして管理するEAS Metadataです。今回整えた提出の流れを、より省力化していきましょう。
