For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /ja/docs/mobile/publishing.md (or send Accept: text/markdown).
アプリストアへの公開
動作するbuildとユーザーがインストールできるreleaseを分けて考えます。
最初のストアへの提出を段階的に準備します
まず、モバイル ビルドを使用してネイティブ開発ビルドを作成し、テストします。ストアに送信すると、コンパイルされたアプリとそのリストが審査のために Google または Apple に送信されます。これは、Expo Go プレビューを開くのと同じではありません。独自の Expo および関連するストア開発者アカウント、テスト済みの HTTPS バックエンド、最終的なアプリ名/アイコン、スクリーンショット、サポート連絡先、公開プライバシー ポリシー URL が必要です。
最初のアップロードの前に、エディターで apps/mobile/app.json を開き、独自の製品のアプリ名、スラッグ、ios.bundleIdentifier、および android.package を設定します。 apps/mobile/eas.json を開き、必要に応じて iOS 申請チームのアプリ識別子を自分のアプリ識別子に置き換えます。出荷される識別子は一例です。正確なフィールドについてはモバイル ビルドを読み、コーディング エージェントにビルド前に 2 つのファイルを確認するよう依頼してください。
eas がインストールされていない場合は、npm install --global eas-cli を実行します。リポジトリ ルートから以下のログイン コマンドを使用し、ブラウザ認証を完了してから、[ビルド] で 1 つのプラットフォームのビルド コマンドを選択して送信します。ビルドのダッシュボード ログを読みます。送信を試みる前に、.aab または .ipa が成功するまで待ってください。 EAS は、プロジェクトのリンクと資格情報への署名を求めます。これらはキット販売者のものではなく、あなたのアカウントに属します。
バイナリがアップロードされたら、Play Console または App Store Connect でアプリを開き、リストと必要なアンケートに記入し、作業中のレビュー担当者のサインイン手順を追加して、そこでレビューのために送信します。内部ドラフトのアップロードは公開リリースではありません。レビューで拒否された場合は、再送信する前に拒否内の正確なポリシーのリンクを開いて問題を修正してください。
corepack pnpm --filter @supastack/mobile exec eas loginアカウントを一度セットアップする
ストアの送信には、EAS ビルドと送信用の無料の Expo アカウント、Google Play Console 開発者登録、iOS 用の Apple Developer Program メンバーシップの 3 つのアカウントが必要です。ビルドする前に、EAS CLI をインストールし、eas login を実行します。どちらのストアの登録も確認に数日かかる場合があるため、早めに登録を開始してください。
最初のアップロード前にアプリケーション識別子の名前を変更します — android.package と ios.bundleIdentifier は、apps/mobile/app.json. では com.supastack.app として出荷されます。Google Play は最初のアップロード時にパッケージ名をロックするため、識別子が間違っている場合は、名前の変更ではなく新しいアプリのエントリを意味します。
EAS に署名を管理させます
apps/mobile/eas.json は、開発、プレビュー、および運用ビルド プロファイルを定義します。運用プロファイルを使用すると、EAS は Android キーストアと iOS 配布証明書をインフラストラクチャ上に生成して保持できます。後で eas credentials で検査し、ローカル キーストアをリポジトリから除外します。
Automated Play の送信には、Play Console → Setup → API アクセスの下でリンクされた Google Play サービス アカウント JSON キーとリリース許可が必要です。それを apps/mobile/secrets/play-store-service-account.json (eas.json が予期するパスと git 無視ディレクトリ) に保存します。新しいアプリの最初のアップロードは、依然として Play Console で手動で行われます。 eas submit は 2 番目のリリースから引き継ぎます。
ビルドして送信する
ビルドは EAS インフラストラクチャ上で実行されるため、バイナリに Android Studio や Xcode をインストールする必要はありません。実稼働プロファイルは、ストア対応の Play 用 .aab と、リモート管理のバージョン番号を持つ App Store 用の .ipa を生成します。プレビュー プロファイルは、物理デバイス QA 用の内部配布 APK を生成します。
出荷された送信プロファイルは、Play 内部トラックをドラフト リリースとしてターゲットにしています。レビューに合格した後に Play Console 内でプロモートするまでは、テスターには何も届きません。
corepack pnpm --filter @supastack/mobile build:android
corepack pnpm --filter @supastack/mobile submit:android
corepack pnpm --filter @supastack/mobile build:ios
corepack pnpm --filter @supastack/mobile submit:ios
# Internal-testing APK for a physical device:
corepack pnpm --filter @supastack/mobile build:android:previewPlay Console フォームに記入します
バイナリと同様に、宣言されたコンテンツに対してプレイ レビュー ゲートを設けます。公開プライバシー ポリシー URL、データ セーフティ フォーム、コンテンツ レーティング アンケート、対象ユーザー、カテゴリなどです。アプリの実際の動作からのデータの安全性についての回答 — キットは認証のためにアカウントの電子メールを収集し、プラットフォームの安全なストレージにセッション トークンを保存し、設定された API とのみ通信します。製品に追加するものはすべてその上に追加します。
サインインが必要な iOS アプリの場合は、アプリ レビューに動作するデモ アカウントとレビュー ノートの手順を提供します。ソーシャル サインイン オプションを選択する前に、Apple の現在のログイン サービス ルールとその例外を確認してください。要件はアプリの実際のログイン フローによって異なります。公式ガイドラインは、上記の最初の投稿セクションにリンクされています。
最初に RevenueCat の後ろでゲート購入
アプリでモバイル購入を提供する場合は、付属の RevenueCat フローを構成します。つまり、MOBILE_PURCHASES_PROVIDER=revenuecat と EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat を設定し、一致する iOS または Android 公開キー SDK を指定します。ネイティブ アプリは購入と復元をサポートしています。いずれかの後に、サーバーで確認されたワークスペース資格からアクセスが更新されます。 Stripe Checkout はモバイル フローでは使用されません。購入がオフになっている場合、または必要な構成が欠落している場合は、ペイウォールを利用できないようにします。構成されたストア製品を検証し、ストア テスト アカウントを使用して EAS 開発ビルドで購入、復元、資格を更新します。アプリと地域に適用される要件については、現在のストア ガイダンスを確認してください。
提出前チェックリスト
送信する前に、独自のテスト アプリとストア アカウントを使用して、以下のすべての項目を確認してください。
- android.package と ios.bundleIdentifier の名前が所有する識別子に変更されました
- ビルド環境の EXPO_PUBLIC_API_URL は本番環境 API を指します
- プライバシー ポリシーは公開 URL でホストされ、ストアの掲載情報にリンクされています
- データ セーフティ フォームは実際のコレクションと一致します: 認証メール、API トラフィック、製品が追加するものすべて
- App Store のレビュー ノートにある動作するデモアカウントの認証情報
- ペイウォールが非表示になっているか、検証済みの RevenueCat 資格によって裏付けられています
- ディープリンクの復帰、セッションの復元、物理デバイスでのサインアウトの検証
- ストアごとに用意されたスクリーンショットとアセットのリスト
拒絶反応から立ち直る
拒否はポリシー参照とともに届きます。症状を推測するのではなく、宣言された原因を修正します。データ セーフティの不一致は通常、アプリではなくフォームが間違っていることを意味します。ログインが必要な拒否は、通常、レビュー ノートにデモ アカウントがなかったことを意味します。修正にわかりやすい名前を付けたリリース ノートを付けて再提出してください。
完全なウォークスルー (認証情報コマンド、コンソールの操作順序、拒否プレイブック) は、リポジトリの docs/mobile-store-submission.md にあります。
インストールとセットアップ
ネイティブ公開にはApple/Google開発者アカウント、アプリ識別子、署名資格情報、ストア審査が必要です。EAS production profileはbuild番号を自動加算し、submit.productionはGoogle Play内部テストへdraftを送ります。bundle identifierとschemeはapps/mobile/app.config.tsにあります。
Webとストアは別々に公開されます。APIは最も古い対応buildと互換にするか、新機能をサーバー状態で制御してください。
corepack pnpm --filter @supastack/mobile build
eas build --profile production --platform ios
eas build --profile production --platform android
eas submit --profile production --platform ios
eas submit --profile production --platform android実装ワークフロー
ネイティブ購入を有効にする前にRevenueCat project、ストア商品、entitlementを設定します。サーバーsecret keyとWebhook Authorizationはサーバー環境のみ、iOS/Android SDK keyは公開build値です。本番ではsandboxを無効にします。
スクリーンショット、説明、プライバシー回答、購入開示など、製品のストア資料を準備します。アプリがアクセスを表示する前に、購入と復元をサーバーの最新subscriber状態で確認します。
検証とトラブルシューティング
実機で提出するartifactそのものを検証します。ログインcallback、session復元、購入と復元、サーバーentitlement更新、workspace切替、deep link、オフライン動作を確認してください。ローカルExpo exportはストア提出用buildではありません。
build番号、ストアtrack、審査状態、接続先API環境を記録します。審査却下も公開工程の一部です。根拠なくコードを疑わず、必要に応じて説明やcapabilityを修正します。
次はDesktopタブで、同じ製品をTauri shellで確認します。