Apple App Store 申請手続きチェックリスト

1. 全体フロー

[Apple Developer Program 加入]   ← 個人 $99/年, 法人は D-U-N-S 必要
              │
              ▼
[Bundle ID / 証明書 / Provisioning]   ← Xcode 自動管理でも可
              │
              ▼
[App Store Connect でアプリ作成]
              │
              ▼
[ストアページ情報入力]   ← アイコン / スクショ / 説明文 / プライバシー
              │
              ▼
[Xcode で Archive → Upload]   ← Bundle Version は単調増加
              │
              ▼
[ビルド処理待ち（5〜30 分）]
              │
              ▼
[(任意) TestFlight でベータ確認]
              │
              ▼
[App Review に提出]
              │
              ▼
[Waiting → In Review → Approved / Rejected]
              │                            │
              ▼                            ▼
       [Ready for Sale]         [Resolution Center で対応]

所要時間の目安: 初回申請は事前準備（D-U-N-S, 銀行情報, 証明書類）に 1〜2 週間、その後の作業は実働 2〜3 日。審査自体は通常 24〜48 時間で結果が出る（Reject だと往復が増える）。

2. Apple Developer Program 加入

• Apple ID を作成し、二要素認証を有効化（必須）
• Apple Developer Program に登録（個人 / 組織 / Enterprise から選択、年間 $99）
• 組織として登録する場合: D-U-N-S 番号を取得（Dun & Bradstreet で無料、ただし反映に 1〜4 週間かかることがある）
• App Store Connect → Agreements, Tax, and Banking で各種契約に署名
  • Free Apps Agreement（基本必須）
  • Paid Apps Agreement（有料アプリ / IAP / 広告収益化する場合）
  • Tax Forms（W-8BEN など、米国非居住者でも要提出）
  • Banking Information（受け取り口座、収益化する場合）
• EU に配信するなら Trader Status を申告（DSA 対応、2024 年 2 月以降必須）

注意: 法人で D-U-N-S を新規取得する場合、登記情報と 完全に一致する 名前 / 住所で取らないと Apple 側で照合が通らず登録が止まる。途中で修正できないので最初から正確に。

3. Bundle ID / 証明書 / Provisioning

• Apple Developer Portal → Identifiers で App ID（Bundle ID）を作成（例: com.example.myapp）
• Bundle ID はあとから変更不可。命名は慎重に（逆ドメイン形式）
• 必要な Capabilities を有効化（Push / Sign in with Apple / iCloud / Associated Domains など）
• Distribution Certificate を作成（または Xcode の Automatically manage signing に任せる）
• App Store Provisioning Profile を作成（自動管理なら自動生成）
• Push Notification を使うなら APNs 認証鍵（.p8）を作成（証明書 .p12 より新しく管理が楽）
• Sign in with Apple を使うなら Service ID / Domain 設定（Web 連携時）

TIPS: 個人開発なら Xcode の Automatically manage signing に任せて OK。手動管理は CI / 複数アプリで秘密鍵を共有するときに必要になる。

4. App Store Connect でアプリ作成

App Store Connect（appstoreconnect.apple.com）→ My Apps → 「+」→ 新規 App。

• Platform を選択（iOS / iPadOS / macOS / tvOS / visionOS / watchOS）
• Name（30 文字以内、App Store 表示名。あとで変更可だが審査必要）
• Primary Language 設定（ローカライズの基準言語）
• Bundle ID を選択（Apple Developer Portal で作成済みのもの）
• SKU を入力（社内管理用 ID、半角英数字、あとから変更不可）
• User Access（Full / Limited）を設定

5. App Information（基本情報）

左メニュー → App Information で記入する情報。言語ごとに別々に入れる項目があるので、ローカライズ対象の各言語で記入する。

• Subtitle（30 文字、検索結果の補助タイトル）
• Privacy Policy URL（必須、HTTPS かつ常時アクセス可能）
• Category Primary / Secondary を選択
• Content Rights: 第三者コンテンツを含むかどうか申告
• Age Rating アンケートに回答（暴力 / 性的表現 / 賭博 / 薬物 / アルコール / タバコ / 衝撃的なテーマなど）
• License Agreement はデフォルト EULA で OK（カスタムを使うなら別途文面を用意）

6. 価格と配信地域

• Price（Free / Tier 1〜）を選択
• Availability: 配信地域選択（全 175 ヵ国 / 特定地域 / 中国本土除外など）
• Pre-Orders を使うか（任意、最大 1 年先まで予約受付可能）
• Volume Purchase Program（教育 / B2B 一括販売）を有効化するか
• Educational Discount を有効化するか

初回は無料 / 全地域から始めて、運用が安定してから絞るのが安全。中国本土だけは ICP ライセンスなど別要件があるので、最初は外しておくのも一手。

7. プライバシー（最重要）

近年、Reject の最大要因はプライバシー関連。App Privacy / Privacy Manifest / ATT / Usage Description の 4 つすべてを整合させる必要がある。

7.1. App Privacy（栄養成分表示）

App Store Connect → App Privacy で収集データの種類と用途を申告。第三者 SDK の収集も自分のアプリの収集として申告するのが落とし穴。

• 使用している全 SDK のプライバシー情報を確認（Firebase / GA / AdMob / Sentry / etc.）
• 「データを収集しない」と宣言する場合: 本当にゼロか再確認（解析 SDK が入っていないか）
• 収集する場合、以下を全データタイプ × 用途で記入
  • トラッキングに使うか（広告 ID 連携など）
  • ユーザーの ID / 端末にリンクされるか
  • 用途（Analytics / App Functionality / Advertising / Personalization など）
• Privacy Policy URL の内容と App Privacy の申告が一致しているか確認

7.2. Privacy Manifest（PrivacyInfo.xcprivacy）

2024 年 5 月以降、サードパーティ SDK を使うアプリでは PrivacyInfo.xcprivacy の同梱が必須。アップロード時にチェックされる。

• アプリ本体に PrivacyInfo.xcprivacy を追加（Xcode → New File → App Privacy）
• NSPrivacyTracking: トラッキングを行うか（true / false）
• NSPrivacyTrackingDomains: トラッキング用ドメイン一覧（ATT 許可がない場合 SKAdNetwork に強制される）
• NSPrivacyCollectedDataTypes: 収集データの種類（App Privacy と整合させる）
• NSPrivacyAccessedAPITypes: 使用 API と Reason（UserDefaults / FileTimestamp / SystemBoot / DiskSpace / ActiveKeyboards）
• 使用しているサードパーティ SDK が Privacy Manifest を含んでいるか確認（Apple 指定の SDK は署名された Privacy Manifest 必須）
• アップロード後、ITMS-91053 などの警告メールが来ていないか確認

典型的な Reason 値: UserDefaults なら CA92.1（同じアプリ内で書き読み）、FileTimestamp なら C617.1（自分が作ったファイル）。Apple のドキュメント "Describing use of required reason API" に対応表がある。

7.3. ATT / Usage Description

Info.plist に Usage Description（使用理由文）を入れていない API を呼ぶとアプリがクラッシュする。使う API すべてに対応する文言を必ず入れる。

• IDFA（広告識別子）を使う場合: NSUserTrackingUsageDescription + ATT プロンプト実装
• 子ども向けアプリでは ATT は使わない（NSUserTrackingUsageDescription も入れない）
• NSCameraUsageDescription（カメラ）
• NSMicrophoneUsageDescription（マイク）
• NSPhotoLibraryUsageDescription / NSPhotoLibraryAddUsageDescription（写真ライブラリ）
• NSLocationWhenInUseUsageDescription / NSLocationAlwaysAndWhenInUseUsageDescription（位置情報）
• NSContactsUsageDescription（連絡先）
• NSCalendarsUsageDescription / NSRemindersUsageDescription（カレンダー / リマインダー）
• NSMotionUsageDescription（モーションセンサー）
• NSBluetoothAlwaysUsageDescription（Bluetooth）
• NSLocalNetworkUsageDescription（ローカルネットワーク、iOS 14+）
• 説明文は具体的に: 「機能のため」では Reject される。「○○機能で△△するために使用します」と書く

8. ストアページ（アイコン・スクショ・テキスト）

8.1. アイコン

• App Store 用 1024 × 1024 PNG（角丸なし、透過なし、PNG 形式のみ）
• アプリ内アイコンを各サイズで書き出し（既存ツール tool/ios_icon.html で一括生成可能）
• マスター画像とストアアイコンのデザインを完全一致させる（不一致は Reject 対象）
• Tinted Icon（iOS 18+ ダークモード用）も用意（任意）

8.2. スクリーンショット

App Store ではデバイスサイズごとに別々のスクショが必要。最大デバイスサイズを用意すれば下のサイズは Apple が自動で縮小してくれるが、できれば各サイズ手動で作るのが推奨。

• 最大 10 枚 / デバイスサイズ（最初の 3 枚が検索結果プレビューで表示される）
• 既存ツール tool/screenshot.html で各サイズに変換
• App Preview 動画（任意、最大 3 本、15-30 秒、M4V/MP4/MOV、デバイス録画推奨）
• ステータスバーのモック（時刻 9:41 / 電池 100% / 電波フル）が定番

8.3. テキスト

• Promotional Text（170 文字、リリース後も審査なしで変更可能。期間限定キャンペーン告知などに）
• Description（4000 文字、最初の数行が「もっと読む」前に表示される）
• Keywords（100 文字、カンマ区切り、競合アプリ名や Apple 商標は禁止）
• Support URL（必須、問い合わせ先 / FAQ ページ）
• Marketing URL（任意、製品ランディングページ）
• What's New（バージョンアップ時、4000 文字。新規 1.0 では空欄可）

8.4. ローカライズ

• 対応言語ごとに、Subtitle / Description / Keywords / Promotional Text を翻訳
• スクリーンショット内の文字も該当言語にローカライズ（推奨）
• アプリ内ローカライズと一致しているか確認

9. ビルド作成とアップロード

9.1. Xcode 側の事前確認

• CFBundleShortVersionString（マーケティングバージョン、例: 1.2.0）を設定
• CFBundleVersion（ビルド番号）を単調増加させる（過去と同じ番号は再アップロード不可）
• Build Configuration: Release
• Team / Bundle Identifier 確認
• Code Signing が正しく動いている（Automatic 推奨）
• Capabilities が必要な分だけ ON（過剰だと Reject 対象）
• Info.plist の Usage Description が全て埋まっている
• PrivacyInfo.xcprivacy がターゲットに含まれている
• Debug 用コード（print のテスト出力, デバッグメニュー, テストアカウントの自動入力）が Release ビルドで除去されている
• SwiftUI Preview 用コードが Release ビルドに混入していないか確認
• Strip Debug Symbols 設定 + dSYM 生成（クラッシュ解析用）

9.2. Archive とアップロード

• スキーム → デスティネーションを Any iOS Device (arm64) に
• Product → Archive
• Organizer で Validate App（事前検証、署名 / Privacy Manifest など事前チェック）
• Distribute App → App Store Connect → Upload
• アップロード時に dSYM を含めるにチェック（クラッシュレポートのシンボリケーション用）
• CLI なら xcodebuild archive + xcodebuild -exportArchive + xcrun altool / notarytool

9.3. 処理待ち と Export Compliance

• アップロード完了後、App Store Connect で 「処理中」 → 5〜30 分待つ
• Export Compliance（暗号化使用申告）に回答
• HTTPS / 標準暗号化のみなら Info.plist に ITSAppUsesNonExemptEncryption = NO を入れて毎回の質問を省略
• 処理失敗メールが来ていないか確認（ITMS-XXX エラーコードで原因調査）

よくある処理失敗: ITMS-91053（必須 Reason API 未宣言）、ITMS-90683（Usage Description 不足）、ITMS-90338（dSYM 不足）、ITMS-90809（非推奨 API 使用）。エラーメールが来たら指定の項目を埋めて再アップロード。

10. TestFlight（任意・推奨）

本番審査の前に身内 / ベータユーザーに配って動作確認するフェーズ。新規 1.0 では本番と同じビルドを TestFlight で先にテストするのが定石。

• アップロード済みビルドに対し Export Compliance 回答済み
• 内部テスター（最大 100 人、App Store Connect の Users 招待）— 即配信可能、ベータ審査不要
• 外部テスター（最大 10,000 人、メール / 公開リンクで招待）— 初回はベータ審査必要（24-48h）
• Test Information を記入（Beta App Description / Email / Feedback URL / What to Test）
• ベータビルドの有効期限は 90 日（過ぎると新ビルドのアップロードが必要）
• クラッシュ / フィードバックを TestFlight アプリ経由で受領

11. App Review への提出

App Store Connect → アプリ → 「+ Version or Platform」でバージョンを作成（または既存バージョンに対してビルドを紐付け）。

• Build を選択（処理済みのビルドが選択肢に出る）
• Version Information（What's New / Description / Keywords / etc.）の最終確認
• App Review Information セクション
  • サインインが必要なら Demo Account（必須、確実に動くアカウント）を提供
  • Notes に審査担当者向けの注意事項を記入（特殊機能の使い方、外部 API 依存、テスト手順など）
  • Contact Information（First / Last / Phone / Email）— Apple からの問い合わせに使われる
  • Attachment（任意、動作証明動画 / 補足資料）
• Version Release オプションを選択
  • Manually release（手動。自分でボタン押す）
  • Automatically release（承認後即リリース）
  • Scheduled release（指定日時、PT/UTC 注意）
• Phased Release（段階的リリース）を有効化するか — 7 日間で 1% → 2% → 5% → 10% → 20% → 50% → 100%
• Submit for Review をクリック

新規アプリ（1.0）は通常より審査が厳しい。 説明文 / スクショ / 機能のすべてが整合していること、Demo Account が完璧に動くことを直前に確認。提出後 24-48 時間で In Review → 結果通知。

12. よく Reject されるパターン

13. 審査ステータスと Reject 対応

13.1. ステータスの流れ

[Prepare for Submission]   ← 入力中
        │
        ▼
[Waiting for Review]   ← 提出済み（通常 24h 以内に進む）
        │
        ▼
[In Review]   ← 審査中（数時間〜1 日）
        │
        ├──→ [Pending Developer Release]   ← 承認、手動リリース待ち
        │           │
        │           ▼
        │    [Ready for Sale]   ← 配信中
        │
        └──→ [Rejected]   ← 拒否、Resolution Center で対応

13.2. Rejected された場合

• Resolution Center で具体的な指摘内容と Guideline 番号を確認
• 指摘が解釈の問題なら Reply で反論 / 質問（バイナリ再アップ不要）
• コード修正が必要なら新ビルドをアップロードし、修正点を Notes に記入して再提出
• Apple のガイドライン解釈に異議があれば App Review Board にアピール（同じレベル・別審査官の判断を仰ぐ）
• 繰り返し落ちる場合は Apple Developer Forums や Code-Level Support 相談を検討

Rejected の心構え: 初回はほぼ何かしら指摘される。短文で礼儀正しく Reply し、修正は指摘範囲だけに絞る（範囲外を弄ると別の Reject 理由を生む）。返答待ちは新規申請より早く 24h 以内が多い。

14. リリース後

• App Store でアプリページが表示されているか確認（反映に最大 24 時間）
• 実機で App Store からダウンロードして起動確認
• Phased Release 中なら毎日％を確認、重大なクラッシュが出たら停止 or 緊急アップデート
• App Analytics で DAU / インプレッション / コンバージョン率を確認
• Xcode Organizer の Crashes でクラッシュレポート確認（dSYM 上げ忘れていなければシンボリケーションされる）
• Reviews & Ratings を監視、低評価レビューには Developer Response で返信
• 問題発生時は Expedited Review（緊急審査リクエスト、ユーザー影響を明記）を申請
• バージョンアップ時は同じ流れで再申請（What's New に変更点記入）

15. 参考リンク

• App Store Review Guidelines — 審査ガイドライン本体
• Human Interface Guidelines — UI/UX ガイドライン
• App Store Connect Help — Connect 操作マニュアル
• Privacy Manifest Files — Privacy Manifest 公式ドキュメント
• Describing use of required reason API — Reason 値一覧
• App Privacy Details — App Privacy 申告ガイド
• Contact Us / Expedited Review — 緊急審査リクエスト窓口
• Standard EULA — デフォルト使用許諾契約