App Store申請チェックリスト（2026年版）：Xcode 26でのビルドからSubmit for Review（審査へ提出）まで

App Store申請チェックリストとは、申請前にすべて揃えておくべき項目のリストです。動作するビルド、正確なストア掲載情報、事実に即したプライバシーに関する回答、そして審査担当者がアプリを使えるだけの十分な情報が含まれます。ビルドが通っただけでは不十分です。以下の6つのセクションはApp Store Connectで求められる順番に沿っており、それぞれの冒頭に、すぐ行動に移せる短い答えを載せています。

Submitを押す前に、App Store申請には何が必要ですか？

App Store申請には、バージョンに紐づけられた処理済みのビルド、そのバージョンの必須メタデータ、スクリーンショット、プライバシーポリシー、App Review用の連絡先情報、そしてログイン機能があるアプリなら動作するデモ用の認証情報が必要です。App ReviewガイドラインにあるApple自身の「Before You Submit（提出前に）」リストには、さらに2つの項目があります。「審査期間中にバックエンドサービスを有効にし、稼働してアクセス可能な状態にしておくこと」と、わかりにくい機能を審査メモで説明することです。

どのアカウント設定とアプリレコード設定を準備しておくべきですか？

有効なApple Developerメンバーシップ、署名済みビルドとバンドルIDが一致するアプリレコード、そしてAccount Holder、Admin、App Managerのいずれかのロールを持つチームメンバーが必要です。これらはAppleのSubmit an appページで提出に必要とされているロールです。

レコード作成時には、名前、プライマリ言語、SKUを選びます。SKUは内部用で、顧客に表示されることはありません。有料アプリやアプリ内課金を販売する場合は、先に有料版アプリ契約、税務情報、銀行口座情報を済ませておきましょう。ビルドに問題がなくても、契約が未署名のままだと商用ローンチが止まることがあります。

2026年のApp Storeアップロードにはどんなビルド要件がありますか？

2026年10月時点で、Appleの今後の要件ページには「App Store Connectにアップロードするアプリは、iOS 26、iPadOS 26、tvOS 26、visionOS 26、またはwatchOS 26のSDKを使用し、Xcode 26以降でビルドする必要があります」（2026年4月28日以降）と記載されています。また、iOSおよびiPadOSアプリは「iOS 13以降をターゲットにする必要があります」（2026年9月9日以降）とも書かれています。

• アップロードのたびにビルド番号を上げ、バージョン番号が出荷予定のリリースと一致していることを確認する。
• 自分のマシンだけでなく、CI（Codemagic、Expo EAS、GitHub Actionsなど）のXcodeイメージも更新する。
• 処理が終わったら、輸出コンプライアンスの確認に回答し、処理済みのビルドをバージョンに紐づける。
• TestFlightビルドを実機にインストールし、オンボーディング、サインイン、オフライン時の状態、購入、購入の復元をテストする。シミュレータで動いても、配布されたビルドが動く証明にはならない。
• アップロード後にApp Store Connectから届くメールを読む。プライバシーマニフェストやSDKバージョンに関するITMS警告は、放置するとブロッカーになる。

ガイドライン2.1(a)は、そうしなかった場合の結果をはっきりと述べています。「不完全なアプリバンドルや、クラッシュする、または明らかな技術的問題があるバイナリはリジェクトします。」アーカイブする前に、プレースホルダー画面、デバッグメニュー、リンク切れを取り除いてください。これらのチェックは、ガイドライン2.1向けのリリースビルドテスト計画で詳しく解説しています。

App Store Connectで必須のスクリーンショットとメタデータは？

2026年10月時点で、Appleのスクリーンショット仕様では「Dynamic Island搭載iPhone（中サイズディスプレイ）」のスクリーンショットが最低1枚必要です。たとえば縦向きで1206 × 2622や1179 × 2556です。iPadで動作するアプリには、2064 × 2752や2048 × 2732などのiPad 13インチのスクリーンショットも最低1枚必要です。

「デバイスサイズごとに、.jpeg、.jpg、.png形式で最大10枚のスクリーンショットをアップロードできます」。また「画像にアルファチャンネルや透過を含めることはできません」。インターフェイスがサイズ間で同じなら、必須の最高解像度だけをアップロードすれば、App Store Connectが縮小します。ガイドライン2.3.3では、スクリーンショットは「タイトル画像、ログインページ、スプラッシュ画面だけでなく、使用中のアプリを示すべき」とされています。

• 誰のためのアプリか、最初のセッションで何ができるかを説明文に書く。
• 名前、サブタイトル、キーワードは関連性のあるものにする。キーワードを重複させたり、競合の名前を使ったりしない。
• サポートURLとプライバシーポリシーのURLがログインなしで表示されることを確認する。
• 年齢制限指定の質問票には、アプリが実際に含む内容とできることに基づいて回答する。
• ユーザーが目にするペイウォールも含め、スクリーンショットには現在のビルドを使う。

プライバシーに関する回答をアプリの実態と一致させるには？

プライバシーに関する回答をアプリと一致させるには、組み込んでいるすべてのSDKとそれぞれが収集するデータを一覧にし、そのリストをもとにApp Privacyへの記入、プライバシーポリシーの作成、アプリ内の挙動の設定を行います。ガイドライン2.3では、「プライバシー情報を含む」メタデータがアプリを正確に反映していなければならないとされています。

ガイドライン5.1.1(i)はこう定めています。「すべてのアプリは、App Store Connectのメタデータ欄とアプリ内のアクセスしやすい場所に、プライバシーポリシーへのリンクを含めなければなりません。」ガイドライン5.1.1(v)はさらに「アプリがアカウント作成に対応している場合、アプリ内でアカウント削除も提供しなければなりません」と付け加えています。アナリティクス、クラッシュレポート、広告、ログインのSDKは回答内容を変えることが多いため、プライバシーラベルのSDK監査で確認してください。また、アプリと同梱するすべてのSDKが、使用するrequired-reason APIをカバーしたPrivacyInfo.xcprivacyプライバシーマニフェストを含んでいるかも確認しましょう。

App Review Informationには何を含めるべきですか？

App Review Information（App Review に関する情報）には、確実に返信する連絡先、有効期限が切れない動作するデモ用認証情報、そして審査担当者を主要機能へ直接案内するメモを含めるべきです。ガイドライン2.1(a)は「アプリにログイン機能がある場合は、デモアカウント情報を含めてください（そしてバックエンドサービスをオンにしてください！）」と求めています。アカウントの代わりに組み込みのデモモードを使う場合は、Appleの事前承認が必要です。

審査メモの具体例を示します。「提供した審査用アカウントでサインインしてください。Libraryを開き、サンプルプロジェクトを選んでExportをタップしてください。このアカウントではすべてのプレミアム機能が解放されています。位置情報機能はシミュレートされた都市を使用するため、移動の必要はありません。」審査担当者を空のアカウント、期限切れになるワンタイムコード、あなたがオンラインで承認しているときしか機能しないフローに誘導してはいけません。審査に耐えるログインの作り方は、デモアカウント設定ガイドで紹介しています。

App Store Connectでアプリを審査に提出する方法は？

アプリを審査に提出するには、ビルドをバージョンに紐づけ、Add for Reviewをクリックし、続けてSubmit for Reviewをクリックします。Add for Reviewだけでは、Appleに何も送信されません。以下の手順は、2026年10月時点のAppleのSubmit an appページに沿っています。

1. Appsでアプリを選択し、サイドバーでアプリのバージョンをクリックする。
2. Buildセクションまでスクロールし、正しいビルドが紐づいていることを確認する。
3. App Store Version Releaseセクションで、ローンチ日を自分で決めたい場合は手動リリースを選び、Saveをクリックする。
4. Add for Reviewをクリックし、既存の下書き提出物を選ぶか新しく作成する。ステータスがReady for Reviewに変わる。
5. Submit for Reviewをクリックする。審査が始まると、ステータスがIn Reviewに変わる。
6. 提出したメタデータとメモのコピーを保存し、審査用連絡先のメールに質問が届いていないか確認する。

提出がリジェクトされて戻ってきたら、何かを変更する前に、ガイドライン番号と審査担当者の説明を読んでください。メタデータの修正だけで済むものもあれば、新しいビルドが必要なものもあります。どちらに該当するかの見分け方は、App Storeリジェクト対応ガイドで解説しています。

他の開発者は申請時にどこでつまずいたのか？

以下の公開事例はどちらも、開発者の手元ではアプリが動いており、問題はアップロードされたビルドか審査担当者の最初のセッションで初めて表面化しました。

Adaloフォーラムのある開発者は、「提供されたデモアカウントの認証情報でサインインできませんでした」という理由でガイドライン2.1のリジェクトを受けました。認証情報は正しかったものの、ユーザーセッションが登録される前にログインボタン上で条件付きナビゲーションが実行されていたため、最初のログインタップでは何も起こらず、2回目のタップでようやく動作していました。ログインボタンの遷移先を、条件付きアクションを持たせた空の中継画面に変更して修正し、再提出しました。

JUCEフォーラムのある開発者は、アップロード後に「ITMS-91053: Missing API declaration」を受け取りました。その内容は、新しいアップロードには「アプリのプライバシーマニフェストにNSPrivacyAccessedAPITypes配列を含める必要がある」というものでした。指摘されたカテゴリはSystemBootTimeとFileTimestampで、別のユーザーはUserDefaultsを報告していました。解決策は、承認済みの理由コードを記載したPrivacyInfo.xcprivacyファイルをXcodeのリソースとして追加することでした。あるユーザーは最初のバージョンでtypeキーを入れ忘れたため、修正するまで無効なマニフェストとしてITMS-91056が発生しました。

どちらの開発者も、自分の環境でしかテストしていませんでした。Submit for Reviewを押す前に、Appleが実際に受け取るビルドを新規ログインでテストし、アップロード後のメールをすべて読んでください。申請パッケージを第三者の目で確認してほしい場合は、申請サポートサービスをご覧ください。