axiom-app-store-diag

App Store リジェクトの診断

概要

App Store のリジェクトを体系的に診断し、是正します。技術、メタデータ、プライバシー、ビジネス、主観的な判断、安全性に関する違反など、最も一般的なリジェクトカテゴリを網羅する9つの診断パターンを紹介します。

基本原則 App Store のリジェクトの大半は、よく知られたカテゴリに当てはまります。リジェクトメッセージを注意深く読み、該当するガイドラインに照らし合わせることで、最もよくある間違い、つまり誤った箇所を修正して同じ理由で再びリジェクトされることを防げます。

リジェクトメッセージを流し読みし、原因を決めつけ、問題ではなかった箇所を「修正」するため、多くの開発者がリジェクト対応に1〜2週間を費やしています。このスキルでは、リジェクトメッセージから対象を絞った修正まで、体系的に診断します。

危険信号 — 提出上の問題を疑う

以下のいずれかに当てはまる場合は、提出上の問題を疑い、このスキルを使用してください。

• リジェクトメッセージに具体的なガイドライン番号が記載されている

• 明確なガイドライン番号がないまま「Binary Rejected」と表示される（技術的な審査ゲートでの不合格）

• 同じアプリが異なる理由で複数回リジェクトされている

• 「Metadata Rejected」と表示される（コード変更は不要）

• リジェクトの理由に「プライバシー」または「データ収集」が含まれている

• リジェクトの理由に「ログイン」または「認証」が含まれている

• 審査担当者からデモアカウントや追加情報を求められている

• ❌ 禁止「審査担当者が間違っているので、そのまま再提出しましょう」

  • リジェクトの内容を読み直してください。App Review の判断は95％の確率で正しいものです。
  • 変更せずに再提出すると、1回のサイクルにつき3〜7日が無駄になります。
  • 正当な理由があって異議を唱える場合は、異議申し立ての手続き（パターン7）を利用してください。

最初に必ず行うこと

コードを変更する前に、必ず以下を行ってください。

1. リジェクトメッセージを全文読む — 流し読みしないでください。正確な文面をコピーし、記載されているガイドライン番号をすべて確認してください。
2. リジェクトの種類を特定する：
   • 「App Rejected」→ ガイドライン違反。コードまたはコンテンツの修正が必要です
   • 「Metadata Rejected」→ ASC のメタデータの問題。ビルドは不要です
   • 「Binary Rejected」→ 技術的な審査ゲート（SDK、マニフェスト、暗号化）
   • 「Removed from Sale」→ 承認後の措置
3. 該当するガイドラインを確認する — app-store-ref で正確な番号を調べてください
4. リジェクト画面のスクリーンショットを撮る — チーム内の共有や異議申し立ての参考用に保存してください
5. ASC の App Review メッセージを確認する — リジェクトではなく、情報を求められている場合があります

ここから分かること

リジェクトの種類	変更された内容	次のステップ
「App Rejected」+ ガイドライン2.1	アプリがクラッシュした、またはプレースホルダーがあった	パターン1
「Metadata Rejected」	スクリーンショットまたは説明に誤りがある	パターン2
「App Rejected」+ ガイドライン5.1	プライバシーポリシーまたはマニフェストに不備がある	パターン3
「App Rejected」+ ガイドライン4.8	Sign in with Apple がない	パターン4
「App Rejected」+ ガイドライン3.x	ビジネスまたは収益化に関する違反	パターン5
「Binary Rejected」／ガイドライン番号なし	SDK、署名、または暗号化の問題	パターン6
審査担当者の判断が誤っているように見える	実際に誤解がある	パターン7
ガイドライン1.xが記載されている	安全性またはコンテンツに関する問題	パターン9
ガイドライン4.1〜4.3が記載されている	デザインまたは独自性に関する問題	パターン8

必須の判断

コードを変更する前に、以下のいずれかに該当することを確認してください。

1. ガイドライン番号が記載された「App Rejected」の場合 → 該当するパターン（1〜5）に照らし合わせます
2. 「Metadata Rejected」の場合 → ASC で修正します。ビルドは不要です（パターン2）
3. 「Binary Rejected」の場合 → 技術的な審査ゲートでの不合格です（パターン6）
4. 複数のガイドラインが記載されている場合 → 最初の問題だけでなく、記載された問題をすべて修正します。バイナリとメタデータが同時にリジェクトされることがあります。バイナリの問題には新しいビルドが必要ですが、メタデータの問題は ASC で修正できます。再提出する前に両方を修正してください。
5. 審査担当者から情報を求められている場合 → コードを変更する前に ASC で返信してください

リジェクトの理由が不明瞭または矛盾している場合

• 停止してください。 まだコードの修正を始めないでください
• ASC で App Review に返信し、説明を求めてください
• 機能が動作している様子を示すスクリーンショットまたは動画を添付してください
• 変更を加える前に、返答を待ってください

判断ツリー

App Store rejection?
│
├─ What does the rejection say?
│  │
│  ├─ Cites Guideline 2.1?
│  │  ├─ App crashed during review? → Pattern 1 (check crash logs)
│  │  ├─ Placeholder content found? → Pattern 1 (search project)
│  │  ├─ Broken links? → Pattern 1 (verify URLs)
│  │  └─ Missing demo credentials? → Pattern 1 (provide in review notes)
│  │
│  ├─ Cites Guideline 2.3?
│  │  ├─ Screenshots don't match app? → Pattern 2 (retake screenshots)
│  │  ├─ Description promises missing features? → Pattern 2 (update text)
│  │  └─ Keywords contain trademarks? → Pattern 2 (remove keywords)
│  │
│  ├─ Cites Guideline 5.1?
│  │  ├─ Privacy policy missing/inaccessible? → Pattern 3 (add/fix policy)
│  │  ├─ Purpose strings missing? → Pattern 3 (add to Info.plist)
│  │  ├─ Privacy manifest incomplete? → Pattern 3 (update PrivacyInfo)
│  │  └─ Tracking without ATT? → Pattern 3 (implement ATT)
│  │
│  ├─ Cites Guideline 4.8?
│  │  ├─ Third-party login without SIWA? → Pattern 4 (add SIWA)
│  │  ├─ SIWA button hidden or broken? → Pattern 4 (fix prominence)
│  │  └─ Exception applies? → Pattern 4 (verify exemption)
│  │
│  ├─ Cites Guideline 3.x?
│  │  ├─ Digital content without IAP? → Pattern 5 (implement StoreKit)
│  │  ├─ Subscription issues? → Pattern 5 (fix terms/value)
│  │  └─ Loot box odds not disclosed? → Pattern 5 (add disclosure)
│  │
│  ├─ "Binary Rejected" / no guideline?
│  │  ├─ Wrong SDK version? → Pattern 6 (update Xcode)
│  │  ├─ Privacy manifest missing? → Pattern 6 (add PrivacyInfo)
│  │  ├─ Encryption not declared? → Pattern 6 (add ITSAppUsesNonExemptEncryption)
│  │  └─ Invalid signing? → Pattern 6 (regenerate provisioning)
│  │
│  ├─ "I believe the reviewer is wrong"?
│  │  └─ → Pattern 7 (Appeal Process)
│  │
│  ├─ Cites Guideline 1.x?
│  │  └─ Safety/content issue → Pattern 9
│  │
│  └─ Cites Guideline 4.1-4.3?
│     └─ Design/originality issue → Pattern 8

パターン選択ルール（必須）

パターンに進む前に、次の手順に従ってください。

1. 却下理由の文言を正確にコピーする — ガイドライン番号も含め、一字一句そのままコピーします
2. ガイドライン番号をパターンに対応付ける — 推測せず、直接対応付けます
3. 複数のガイドラインが記載されている場合 — 再提出する前に、該当するすべての問題を修正します
4. ガイドライン番号がない場合 — 「Binary Rejected」の可能性が高いため、パターン 6 から始めます
5. 不明な場合 — まずレビュアーに問い合わせて、明確な説明を求めます

パターンを一度に1つだけ適用する

• 却下メッセージから正しいパターンを特定します
• そのパターンに必要な修正をすべて行います
• 複数のガイドラインが記載されている場合、再提出前にそれぞれを修正します
• 複数の問題が指摘されているときに、そのうち1つだけを修正して再提出してはいけません

禁止事項

• 別のレビュアーに当たることを期待して、変更せずに再提出すること
• 却下理由を流し読みして、修正内容を推測すること
• 複数のガイドラインが記載されているのに、最初に記載されたものだけを修正すること
• App Review のメッセージで感情的に反論すること
• Guideline 5.1 を回避するために、プライバシー機能を無効にすること

診断パターン

パターン 1：Guideline 2.1 — アプリの完全性

所要時間 却下サイクルごとに 3～7 日

症状

• 「App Completeness」を理由とする却下
• 審査中にクラッシュする
• プレースホルダーのコンテンツが見つかる
• リンク切れ（サポート URL、プライバシーポリシー、アプリ内リンク）
• ログインが必要なアプリにデモ用認証情報がない

よくある原因

1. レビュアーのデバイスでアプリがクラッシュする（OS バージョンやデバイスの種類が異なる）
2. いずれかの画面にプレースホルダーのテキストまたは画像が表示されている
3. リンク切れ（サポート URL、プライバシーポリシー、アプリ内リンク）
4. ログインが必要なアプリにデモ用認証情報がない
5. 審査期間中にバックエンドサービスがダウンしていた

診断

# 1. Check crash logs in App Store Connect
# Xcode Organizer > Crashes > Filter by version

# 2. Search for placeholder strings
grep -r "Lorem\|TODO\|FIXME\|placeholder\|sample\|test data" \
  --include="*.swift" --include="*.storyboard" --include="*.xib" .

# 3. Verify all URLs resolve
curl -sI "https://your-support-url.com" | head -1
curl -sI "https://your-privacy-policy-url.com" | head -1

# 4. Test on latest shipping iOS
# Check ASC for specific iOS version reviewer used (noted in rejection)

修正

// ❌ WRONG — Demo credentials that expire
// Review Notes: "Login: [email protected] / password123"
// (If this account expires or gets locked, instant rejection)

// ✅ CORRECT — Permanent demo credentials
// Review Notes:
// "Demo Account: [email protected] / ReviewDemo2024!
//  This account has pre-populated sample data.
//  Account will not expire during review period."

// ❌ WRONG — Placeholder still in code
Text("Lorem ipsum dolor sit amet")

// ✅ CORRECT — Real content in every screen
Text("Welcome to YourApp. Get started by creating your first project.")

検証

• まず TestFlight に提出し、複数のデバイスですべての画面をテストします
• すべての URL が正常に読み込まれることを確認します（アプリ内から開くプライバシーポリシーも含む）
• デモ用認証情報が機能し、有効期限切れにならないことを確認します
• 却下理由で指定された iOS バージョンでテストします（却下メッセージ、または ASC Activity → Build → 審査デバイス情報を確認します）
• 審査期間中はバックエンドの稼働状況を監視します（審査中にデプロイしないでください）
• レビュアーが使用した特定のデバイスと OS バージョンについて、ASC のクラッシュログ（Xcode Organizer → Crashes）を確認します

---

パターン 2：Guideline 2.3 — メタデータの問題

所要時間 1～3 日（メタデータの修正のみ。ビルドは不要）

症状

• 「Metadata Rejected」 — コード変更は不要
• スクリーンショットが現在のアプリの UI と一致しない
• 説明文で、アプリにない機能をうたっている
• キーワードに商標または競合他社の名称が含まれている

よくある原因

1. スクリーンショットに古い UI や、現在は存在しない機能が写っている
2. 説明文で、まだ実装されていない機能をうたっている
3. キーワードに商標用語または競合他社の名称が含まれている
4. アプリ名から、実際には存在しない機能があるように受け取られる
5. カテゴリの選択が、アプリの主な機能と一致していない

診断

すべてのスクリーンショットを現在のアプリの UI と比較します。説明文を一語ずつ読み、各記述がアプリに実装されているか確認します。キーワードを Apple の商標リストと照合します。

Checklist:
☐ Every screenshot matches current build
☐ Every feature mentioned in description exists and works
☐ No trademarked terms in keywords (e.g., "Instagram", "Uber")
☐ App icon appropriate for all audiences
☐ Age rating matches actual content
☐ Category selection accurate
☐ "What's New" text matches actual changes

修正

App Store Connect でメタデータを直接更新します。メタデータのみの却下の場合、新しいビルドは不要です。

✅ Take fresh screenshots FROM THE SUBMITTED BUILD (not dev build)
✅ Remove any features from description that aren't fully functional
✅ Replace trademarked keywords with generic equivalents
   ("photo sharing" not "Instagram-like")
✅ Ensure "What's New" describes changes in this specific version

検証

• 提出したものと同一のビルドバージョンでスクリーンショットを撮影します
• チーム外の人に説明文を読んでもらい、各記述を確認します
• キーワードに商標用語が含まれていないか検索します

---

パターン 3：Guideline 5.1 — プライバシー違反

所要時間 3～10 日（コード、マニフェスト、ポリシーの変更）

症状

• プライバシーポリシー、データ収集、目的文字列、またはトラッキングを理由とする却下
• 必須の reason API 宣言がプライバシーマニフェストにない
• 開示されていないデータをサードパーティ SDK が収集している

よくある原因

1. プライバシーポリシーがない、またはアプリ内からアクセスできない
2. プライバシーポリシーの内容が実際のデータ収集と一致していない
3. アクセス許可リクエストに目的を説明する文字列がない
4. プライバシーマニフェスト（PrivacyInfo.xcprivacy）に、必須の理由 API の宣言がない
5. サードパーティ SDK が、プライバシーに関する栄養成分表示で開示されていないデータを収集している
6. ATT（App Tracking Transparency）の同意なしにアプリがユーザーを追跡している

診断

// 1. Check: Is privacy policy URL in ASC AND accessible from within the app?
// Both are required. In-app access is commonly missed.

// 2. Check purpose strings
// ❌ WRONG — Generic purpose string
"NSCameraUsageDescription" = "Camera access needed"

// ✅ CORRECT — Specific purpose string explaining why
"NSCameraUsageDescription" = "Take photos for your profile picture and upload to your account"

// 3. Generate privacy report
// Xcode: Product → Archive → Generate Privacy Report
// This shows aggregate data from all frameworks and your code

// 4. Check privacy manifest
// Verify PrivacyInfo.xcprivacy exists in your app target
// AND in every framework target that uses required reason APIs

修正

目的を説明する文字列（Info.plist）

<key>NSCameraUsageDescription</key>
<string>Take photos for your profile picture and upload to your account</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>Show nearby restaurants on the map and calculate delivery distance</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Select photos from your library to attach to messages</string>

プライバシーマニフェスト（PrivacyInfo.xcprivacy）

<dict>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>

プライバシーポリシーの要件

Your privacy policy MUST specifically list:
☐ What data is collected (every type)
☐ How data is collected (automatically, user-provided)
☐ All uses of collected data
☐ Third-party sharing (who, why)
☐ Data retention period
☐ How users can request deletion
☐ Contact information for privacy inquiries

App Tracking Transparency

// Required if app tracks users across other companies' apps/websites
import AppTrackingTransparency

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            // Enable tracking (analytics, ad attribution)
            break
        case .denied, .restricted, .notDetermined:
            // Disable ALL tracking
            // Remove IDFA access, disable third-party analytics that track
            break
        @unknown default:
            break
        }
    }
}

検証

• Privacy Report を生成し（Product > Archive > Generate Privacy Report）、すべての API が宣言されていることを確認します
• アプリ内からプライバシーポリシーのリンクをテストします（ブラウザーからだけでなく）
• すべてのアクセス許可リクエストに、具体的で誠実な目的を説明する文字列が設定されていることを確認します
• すべてのサードパーティ SDK を監査し、開示されていないデータ収集がないことを確認します
• ATT のフローをテストします。追跡を拒否し、その場合もアプリが正常に動作することを確認します

---

パターン 4：ガイドライン 4.8 — Sign in with Apple がない

所要時間 3～7 日（実装＋再提出）

症状

• ガイドライン 4.8 を引用した却下
• アプリにサードパーティのログイン機能があるが、Sign in with Apple（SIWA）がない

よくある原因

1. アプリに Google／Facebook／Twitter のログイン機能があるが、SIWA がない
2. SIWA ボタンはあるが、動作しない
3. SIWA が同等の目立ちやすさで提示されていない（非表示または二次的な位置にある）
4. SIWA のフローで認証情報の取り消しに対応していない

診断

ルールはシンプルです。アプリがサードパーティまたはソーシャルログインサービスを1つでも使用している場合、同等の選択肢として Sign in with Apple を必ず提供する必要があります。

例外（SIWA が不要な場合）：

• 社内向けまたは従業員専用のアプリ
• 既存の組織認証を使用する教育機関向けまたは企業向けアプリ
• 政府 ID が必要な政府機関／税務／銀行のアプリ
• 特定のサードパーティサービスのクライアントであるアプリ（例：メールクライアント）

修正

import AuthenticationServices

// ✅ CORRECT — SIWA at same prominence as other login options
struct LoginView: View {
    var body: some View {
        VStack(spacing: 16) {
            // Sign in with Apple — MUST be at same visual level
            SignInWithAppleButton(.signIn) { request in
                request.requestedScopes = [.fullName, .email]
            } onCompletion: { result in
                switch result {
                case .success(let authorization):
                    handleAuthorization(authorization)
                case .failure(let error):
                    handleError(error)
                }
            }
            .signInWithAppleButtonStyle(.black)
            .frame(height: 50)

            // Other login options at same size/prominence
            GoogleSignInButton()
                .frame(height: 50)
        }
    }

    func handleAuthorization(_ authorization: ASAuthorization) {
        guard let credential = authorization.credential
            as? ASAuthorizationAppleIDCredential else { return }

        let userIdentifier = credential.user
        let fullName = credential.fullName
        let email = credential.email
        // Note: fullName and email only provided on FIRST sign-in
        // Store them immediately — they won't be provided again

        // Send to your backend for account creation/login
    }
}

// ✅ Handle credential revocation (required for account deletion support)
func checkCredentialState() {
    let provider = ASAuthorizationAppleIDProvider()
    provider.getCredentialState(forUserID: storedUserIdentifier) { state, error in
        switch state {
        case .authorized:
            break // User is still signed in
        case .revoked:
            // User revoked credentials — sign out immediately
            signOut()
        case .notFound:
            // Credential not found — show sign-in
            showLogin()
        @unknown default:
            break
        }
    }
}

検証

• SIWA ボタンが他のログインボタンと視覚的に同等である（同じサイズ、同じ画面）
• SIWA の一連のフローが動作する：サインイン、アカウント作成、認証情報の確認
• 取り消しに対応する：ユーザーは「設定」>「Apple ID」>「サインインとセキュリティ」で取り消せる
• アカウント削除のフローをテストする（2022年6月以降必須）

---

パターン 5：ガイドライン 3.x — ビジネス／収益化

所要時間 3～14 日（アーキテクチャの変更が必要な場合があります）

症状

• ビジネス関連のガイドラインを引用した却下
• IAP の要件を満たしていない
• サブスクリプションで継続的な価値が提供されない
• デジタルコンテンツに外部決済を使用している

よくある原因

1. IAP を使わずにデジタルコンテンツをアンロックしている（アプリ内機能に外部決済を使用）
2. サブスクリプションで継続的な価値が提供されない（買い切りコンテンツをサブスクリプションとして販売）
3. ルートボックスやランダムアイテム購入の確率が開示されていない
4. 誤解を招くサブスクリプションのフロー（ダークパターン、誤解を招く無料トライアル）
5. IAP のメタデータが不完全、または審査に提出されていない

診断

重要な問いは、Apple IAP を使わずにアンロックされるデジタルコンテンツや機能があるかどうかです。

Digital goods/features → MUST use Apple IAP
  Examples: premium features, virtual currency, ad removal, content
  packs, subscription access to digital content

Physical goods/services → MAY use external payment
  Examples: physical merchandise, ride-sharing, food delivery,
  person-to-person services

Certain categories → MAY use external payment (3.1.3 exceptions)
  Examples: "reader" apps (Kindle, Netflix, Spotify), one-to-one
  real-time services

修正

// ❌ WRONG — Unlocking features via external payment
func unlockPremium(receiptFromServer: String) {
    // Bypass Apple IAP → rejection
    UserDefaults.standard.set(true, forKey: "isPremium")
}

// ✅ CORRECT — StoreKit 2 for all digital goods
import StoreKit

func purchasePremium() async throws {
    let product = try await Product.products(for: ["com.app.premium"]).first!
    let result = try await product.purchase()

    switch result {
    case .success(let verification):
        let transaction = try checkVerified(verification)
        // Unlock feature
        await transaction.finish()
    case .pending:
        // Payment pending (Ask to Buy, etc.)
        break
    case .userCancelled:
        break
    @unknown default:
        break
    }
}

// ✅ Loot box disclosure (required if random items for purchase)
struct LootBoxView: View {
    var body: some View {
        VStack {
            Text("Mystery Box — $4.99")
            Text("Contents are random. Odds:")
                .font(.caption)

            // MUST disclose odds before purchase
            VStack(alignment: .leading) {
                Text("Common item: 60%")
                Text("Rare item: 30%")
                Text("Legendary item: 10%")
            }
            .font(.caption2)
            .foregroundStyle(.secondary)
        }
    }
}

検証

• すべてのデジタルコンテンツ／機能に Apple IAP（StoreKit 2）を使用します
• アプリ提出前に IAP 製品を ASC に提出し、承認を受けます
• 購入画面を表示する前に、サブスクリプションの条件を明確に伝えます
• 無料トライアルの期間と自動更新後の価格を明確に表示します
• 購入前にルートボックスの確率を開示します
• デジタル商品への外部決済リンクを設置しません（「リーダー」アプリの例外が適用される場合を除く）

---

パターン 6：バイナリ却下 — 技術的なゲート

所要時間 1～3 日（ビルド設定の修正）

症状

• 特定のガイドラインが示されずに「Binary Rejected」となる
• 処理中に自動で却下される
• ビルドが「Processing」状態のまま停止する

よくある原因

1. 古い SDK バージョンでビルドされている（Apple の最小要件を満たす必要があります）
2. プライバシーマニフェスト（PrivacyInfo.xcprivacy）がない、または無効です
3. 暗号化コンプライアンスが宣言されていません（ITSAppUsesNonExemptEncryption）
4. 署名またはプロビジョニングプロファイルが無効です
5. Info.plist に必須のデバイス機能がありません
6. アプリが非公開 API または非推奨 API を使用しています
7. オンデマンドリソースなしではアプリのバイナリサイズが大きすぎます

診断

# 1. Check Xcode and SDK version
xcodebuild -version
# Must be current or previous major Xcode version

# 2. Check processing logs in ASC
# App Store Connect → My Apps → [App] → Activity → Build → Processing Log

# 3. Verify encryption declaration
grep -c "ITSAppUsesNonExemptEncryption" Info.plist
# Must exist and be set to YES or NO

# 4. Check provisioning
security cms -D -i embedded.mobileprovision 2>/dev/null | head -20
# Verify not expired

# 5. Check for private API usage
# Xcode: Product → Archive → Distribute App → Validate App
# This catches most private API issues before submission

修正

<key>ITSAppUsesNonExemptEncryption</key>
<false/>


<key>ITSAppUsesNonExemptEncryption</key>
<true/>

暗号化の判定フロー：

1. アプリで標準の OS 提供 HTTPS（URLSession、Alamofire）のみを使用していますか？ → false を設定すれば完了です
2. OpenSSL、libsodium、またはカスタム暗号を直接呼び出していますか？ → true を設定し、BIS の書類をアップロードします
3. 独自の暗号化プロトコルを実装していますか？ → true を設定し、BIS の書類をアップロードします
4. 判断できませんか？ → strings YourApp | grep -i "openssl\|libcrypto\|CCCrypt" を実行して確認します

# Validate before submitting
# Xcode: Product → Archive → Distribute App → Validate App
# Catches ~80% of binary rejection causes

# Clean build if signing issues
rm -rf ~/Library/Developer/Xcode/DerivedData
# Re-download provisioning profiles in Xcode Preferences → Accounts

確認

• 提出前に Xcode Organizer で「Validate App」を実行します
• Xcode のバージョンが Apple の最新要件を満たしていることを確認します
• PrivacyInfo.xcprivacy が存在し、アプリバンドルに含まれていることを確認します
• ITSAppUsesNonExemptEncryption キーが存在することを確認します
• プロビジョニングプロファイルの有効期限が切れていないことを確認します
• リリース構成で実機上のアプリをテストします

---

パターン 7：異議申し立ての手続き

解決までの期間 3～14 日

使用する場面

• 審査担当者がアプリを誤解したと心から考えている場合
• 誤ったガイドラインが適用されたと考えている場合
• アプリが要件に準拠しており、その証拠がある場合

使用しない場面

• Apple のルールに異議がある場合（アプリのためにルールが変更されることはありません）
• 変更しなくても別の審査担当者なら承認してくれると期待している場合
• 必須機能（SIWA など）の実装を避けたい場合

ステップ 1：まず App Store Connect で返信する

多くの問題は、正式な異議申し立てをしなくても解決します。ASC で App Review のメッセージに返信し、以下を提示します。

• 要件への準拠を示す具体的な証拠
• 機能を実演するスクリーンショットまたは動画
• 準拠していると考えるガイドラインへの明確な言及

ステップ 2：解決しない場合は正式な異議申し立てを提出する

URL: developer.apple.com/contact/app-store/?topic=appeal

異議申し立ての書き方

✅ GOOD appeal structure:

"Our app complies with Guideline [X.Y] because [specific evidence].

The reviewer noted: '[quote exact rejection text]'

However, our app [specific counter-evidence with details]:
1. [Feature X] works as shown in [attached screenshot/video]
2. [Policy Y] is accessible at [URL] and within the app at [screen]
3. [Requirement Z] is implemented as described in [technical detail]

Attached: [screenshots, screen recording, or documentation]

We respectfully request re-review of this decision."

❌ BAD appeal examples:

"This is unfair. Other apps do the same thing. Please approve."
→ Apple reviews each app independently

"We've been rejected 3 times and are losing money."
→ Financial pressure is not relevant to guideline compliance

"The reviewer didn't understand our app."
→ Vague. Show specifically what they missed.

"We need this approved by Friday for our launch."
→ Deadlines are not App Review's concern

ステップ 3：必要に応じてエスカレーションする

異議申し立てが却下された場合：

1. App Review との電話を依頼します（異議申し立ての手続きから利用できます）
2. 最後の手段として Apple Developer Relations に連絡します
3. アプリに本当にアーキテクチャの変更が必要かどうかを検討します

確認

• （異議申し立てを行う場合は）コードを変更する前に回答を待ちます
• 却下 1 件につき異議申し立ては 1 件だけ提出します（複数の申し立ては手続きを遅らせます）
• 異議申し立てを提出する前に、情報提供の依頼に回答します

---

パターン 8：ガイドライン 4.2／4.3 — 最低限の機能／スパム

パターン 8～9 では、コードを変更するのではなく、価値や準拠を示すことで解決する、主観的な却下への対応を説明します。

解決までの期間 1～4 週間（メタデータだけでなくアプリの変更が必要です）

表示される却下メッセージ

• 4.2：「アプリには、App Store にふさわしい十分なコンテンツと機能が含まれていません」
• 4.3：「アプリのコンテンツおよび機能は、あなたまたは別のデベロッパが提出した他のアプリと重複しています」

実際の意味

• 4.2（却下理由として 3 番目に多い）：「アプリはネイティブアプリとして存在するだけの機能を備えていません」— ウェブサイトが提供するものを超える価値が不十分です。
• 4.3（却下理由として 2 番目に多い）：「アプリが別のアプリと似すぎている、またはテンプレートで生成されています。」Apple はテンプレート量産型のスパムを積極的に排除しています。

判定 — これは本当に 4.2／4.3 ですか？

却下が妥当だと判断する前に、誤分類がないか確認します。

# Is the app a WKWebView wrapper?
grep -rn "WKWebView\|SFSafariViewController\|UIWebView" --include="*.swift" .

# Does the app use native features at all?
grep -rn "import CoreLocation\|import AVFoundation\|import UserNotifications\|import HealthKit\|import CoreML" --include="*.swift" .

# Is the codebase template-generated? (common template markers)
grep -rn "powered by\|generated by\|template\|starter kit" --include="*.swift" --include="*.plist" .

WKWebView が主要な UI で、ネイティブ機能のインポートがない場合、却下は妥当である可能性が高いです。

対応判断フロー

Is the rejection valid? (be honest)
│
├─ YES, app is thin / web wrapper
│  ├─ Can you add meaningful native features? → Add them (see Evidence Checklist)
│  └─ Core value IS the web content? → Consider reader app model or PWA instead
│
├─ PARTIALLY, app has value but reviewer missed it
│  ├─ Did you provide demo credentials? → If not, resubmit with access
│  ├─ Is the value hidden behind onboarding? → Add review notes explaining path to value
│  └─ Does the app need content/data to show value? → Pre-populate sample data for review
│
└─ NO, app is clearly feature-rich
   └─ Appeal with detailed functionality walkthrough (Pattern 7)
      Include: feature list, screenshots of each major screen, video demo

証拠チェックリスト — 審査担当者を納得させるもの

4.2（最低限の機能）の場合 — ネイティブならではの価値を示します。

Features that prove native value:
☐ Offline functionality (data available without network)
☐ Push notifications with meaningful triggers
☐ Device API usage (camera, location, sensors, HealthKit)
☐ Custom UI beyond web content (native controls, animations, gestures)
☐ Local data persistence and sync
☐ Widget, Live Activity, or Watch companion
☐ Accessibility features (VoiceOver, Dynamic Type)
☐ System integration (Shortcuts, Share Extension, Spotlight)

Changes that DON'T help:
✗ Adding a splash screen or settings-only screen to a web wrapper
✗ Cosmetic changes (colors/fonts) without functional native features

4.3（スパム／重複）の場合 — 独自性を示します。

How to differentiate:
☐ Unique UI that doesn't match other apps in your catalog
☐ Different target audience with distinct feature set
☐ Separate branding (icon, name, color scheme)
☐ Features that justify a separate app vs. being a mode in an existing app
☐ Distinct App Store description and screenshots
☐ Different primary use case (not just themed variants)

If you have multiple similar apps:
☐ Consolidate into one app with multiple modes/themes
☐ Remove duplicates before resubmitting
☐ Explain in review notes why apps need to be separate

コミュニケーション用テンプレート

Resolution Center response (adapt for 4.2 or 4.3):

"Thank you for your feedback. [Choose one]:

For 4.2: We have added native features that provide value beyond our
web presence: [list features with device capabilities used].

For 4.3: Our app is distinct from [similar app] — different target
audience ([X] vs [Y]), unique features ([list]), separate branding.

[Attach: screenshots of each major screen, 30-60s video walkthrough]
Demo credentials: [username] / [password]"

検証

• アプリを自分で試してください。ウェブサイトではなく、あなたならこれをダウンロードしますか？
• 他のアプリと比較してください。なぜ別のアプリとして存在するのか、明確に説明できますか？
• デモデータをあらかじめ用意し、レビュー担当者がすぐに価値を実感できるようにしてください
• ネイティブ機能の動作を紹介する、30～60 秒の操作動画を録画してください

---

パターン 9：ガイドライン 1.x — 安全性：コンテンツ／UGC／子ども

解決までの期間 1～3 週間（モデレーションの仕組みまたはコンテンツの変更が必要です）

却下メッセージとその意味

• 1.1：「アプリには、多くのユーザーが不快に感じるコンテンツが含まれています」 — Apple は、アプリからアクセスできるコンテンツも含め、コンテンツを厳しく審査します。
• 1.2：「アプリではユーザー生成コンテンツの表示が可能ですが、不適切なコンテンツを報告するための十分な仕組みがありません」 — 十分なモデレーションを備えていない UGC です。譲れない条件です。ユーザーが何かを投稿できるなら、完全なモデレーションシステムが必要です。
• 1.3：「キッズカテゴリのアプリは COPPA に準拠する必要があります」／「キッズ向けとして適切でないサードパーティ製の分析機能が含まれています」 — キッズカテゴリには最も厳しいルールが適用されます。不備があれば却下されます。

判定 — どのサブガイドラインに該当するか？

Does the app have UGC?
├─ YES → Likely 1.2 (moderation required)
│  ├─ Comments, posts, or forums? → Need reporting + moderation
│  ├─ Photo/video uploads visible to others? → Need content review
│  ├─ User profiles visible to others? → Need profile reporting
│  └─ Chat or messaging? → Need blocking + reporting + content filtering
│
├─ Is it in the Kids category?
│  └─ YES → Likely 1.3 (strict requirements)
│     ├─ Any third-party SDKs? → Must be certified for kids
│     ├─ Any external links? → Must be gated or removed
│     └─ Any purchases? → Must have parental gate
│
└─ Does it display third-party or app-provided content?
   └─ YES → Likely 1.1 (content standards)
      ├─ Web content via WKWebView? → Must filter or restrict
      ├─ AI-generated content? → Must moderate outputs
      └─ Content from third-party APIs? → Must filter before display

対応の判断ツリー

UGC に関する却下（1.2）：

What moderation exists?
│
├─ No moderation at all
│  └─ Implement complete moderation system (see Implementation Checklist)
│
├─ Reporting exists but insufficient
│  ├─ Missing blocking? → Add user blocking (immediate effect)
│  ├─ No response workflow? → Add 24-hour review commitment
│  └─ No pre-publish review? → Add content queue or ML filtering
│
└─ Moderation exists but not visible to reviewer
   └─ Add review notes explaining moderation flow + demo how to trigger it

キッズカテゴリに関する却下（1.3）：

What triggered the rejection?
│
├─ Third-party SDKs
│  └─ Remove ALL analytics/ads SDKs not certified for Kids category
│     Common offenders: Firebase Analytics, Facebook SDK, AdMob
│     Allowed: Apple's own frameworks, COPPA-certified SDKs only
│
├─ External links
│  └─ Remove all links OR gate behind parental verification
│     Includes: "Visit our website", social media links, "More apps"
│
├─ In-app purchases
│  └─ Add parental gate before ANY purchase flow
│     Gate must require adult knowledge (e.g., "spell this word", math problem)
│     Simple "Are you 18?" button is NOT sufficient
│
└─ Data collection
   └─ Remove ALL data collection not essential to app function
      No device IDs, no location, no contact info, no tracking

実装チェックリスト — 最低限実用可能なモデレーション（1.2）

Required for ANY app with UGC:
☐ Report button on every piece of user content (visible, not buried)
☐ Block user functionality (immediate, no delay)
☐ Visible Terms of Use / Community Guidelines (accessible from within app)
☐ Content review workflow (human review queue or ML pre-screening)
☐ 24-hour response commitment for reported content
☐ Ability to remove content and ban users
☐ In-app link to Terms of Use from content creation screens

キッズカテゴリの要件（1.3）

MANDATORY for Kids category:
☐ COPPA compliance (no data collection from children under 13)
☐ No third-party advertising (none, not even "child-safe" networks)
☐ No external links (or gated behind parental verification)
☐ No social features (no chat, no profiles, no friend lists)
☐ Parental gate before any purchase (not a simple age button)
☐ Remove ALL non-COPPA-certified SDKs (Firebase Analytics, Facebook, AdMob, Crashlytics)
☐ No user tracking of any kind
☐ Privacy policy specifically addresses children's data

連絡用テンプレート

Resolution Center response (adapt for 1.2 or 1.3):

"Thank you for your feedback. [Choose one]:

For 1.2 (UGC): We have implemented moderation: report button on all
content [location], user blocking, [review workflow], Terms of Use at
[URL]. To test: create a post → [...] menu → Report.

For 1.3 (Kids): Removed [SDKs]. External links [removed/gated].
Added parental gate for purchases. No user data collected.
Privacy policy updated at [URL].

[Attach: screenshots showing moderation/parental gate flow]"

検証

• 報告フローを最初から最後までテストしてください。コンテンツを報告し、審査キューに届くことを確認します
• ブロックフローをテストしてください。ユーザーをブロックし、そのユーザーのコンテンツがすぐに非表示になることを確認します
• キッズ向けの場合：テスト用デバイスからアプリを削除して再インストールし、データが残っていないことを確認します
• キッズ向けの場合：strings YourApp.app/YourApp | grep -i "firebase\|facebook\|google\|admob" を実行し、埋め込み SDK を見つけます
• アプリに詳しくない人に報告／ブロックボタンを探してもらってください。5 秒以内に見つけられない場合は、十分に目立っていません

---

クイックリファレンステーブル

却下の種類	考えられる原因	最初に確認すること	パターン	一般的な修正期間
ガイドライン 2.1	クラッシュ／プレースホルダー	デバイスでテストし、プレースホルダーを検索する	1	1～3 日
ガイドライン 2.3	メタデータの不一致	スクリーンショットとアプリを比較する	2	1 日（ビルド不要）
ガイドライン 5.1	プライバシー上の不備	ポリシー＋マニフェスト＋目的文字列を確認する	3	2～5 日
ガイドライン 4.8	SIWA の未実装	サードパーティログインの有無を確認する	4	3～5 日
ガイドライン 3.x	支払い方法	IAP フローを確認する	5	3～14 日
バイナリ却下	技術的な審査要件	SDK、マニフェスト、暗号化を確認する	6	1～2 日
ガイドライン 1.x	安全性／コンテンツ／UGC	UGC のモデレーション＋キッズ向けの準拠状況を確認する	9	1～3 週間
ガイドライン 4.2/4.3	内容の薄いアプリ／スパム	ネイティブ機能＋アプリの独自性を監査する	8	1～4 週間

本番環境での危機的なシナリオ

状況：アプリが 3 回目に却下され、そのたびに理由が異なり、リリースは明日

状況：マーケティングチームはリリース日を発表済みです。アプリはクラッシュで却下され（修正済み）、次にメタデータで却下され（修正済み）、現在はプライバシーポリシーが「実際のデータ収集と一致していない」として却下されています。

プレッシャーの兆候：

• プロダクトチームはすでにリリース日を記載したプレスリリースを送付しています
• リリースを延期すると、App Store の評価が下がります
• マネージャーから「なぜもっと早く気づかなかったのか」と尋ねられています
• 指摘されたプライバシーの問題だけを急いで修正したくなっています

こうなる理由：審査のたびに確認が深まります。1 回目では明白な問題（クラッシュ）が見つかり、2 回目ではメタデータが確認され、3 回目ではプライバシーへの準拠状況が監査されます。これは通常のことであり、「審査担当者に目をつけられている」わけではありません。

合理化の落とし穴（絶対に陥らないでください）

1. 「プライバシーポリシーの文言だけ直して再提出すればいい」

   • レビュアーは「実際のデータ収集と一致していない」と述べています
   • これは、アプリが開示していないデータを収集しているという意味です
   • 実際のデータ収集を監査せずに文言だけ変更すると、再び却下されます

2. 「レビュアーの判断は理不尽だから、異議を申し立てよう」

   • それぞれ異なる正当な問題で3回却下されたのは、理不尽ではありません
   • 異議申し立てをすると、修正して1〜3日で再提出できるのに、3〜14日を無駄にします

3. 「早くリリースするために、プライバシーに関わる機能を削除しよう」

   • 機能を削除するとアプリが変わるため、すべての項目が再審査になります
   • 新たな問題（UI の破損、機能の欠落）が発生する可能性があります

4. 「次のレビュアーは違う人だから、気付かないかもしれない」

   • レビュアーは却下履歴を確認し、以前に指摘された問題をチェックします
   • 同じ理由で再び却下されると、上級レビュアーにエスカレーションされます

必須の対応方法

1. 慌てないでください。十分に修正せずに再提出しないでください。
2. 指摘された問題だけでなく、出荷前チェックリストをすべて実施してください。
3. すべてのデータ収集を監査してください。各 SDK、各アナリティクス呼び出し、ユーザーデータを送信するすべての API リクエストが対象です。
4. プライバシーレポート（Product > Archive > Generate Privacy Report）を生成し、プライバシーポリシーと照合してください。
5. 実際に収集するすべてのデータの種類を具体的に記載するよう、プライバシーポリシーを修正してください。
6. 以前に却下の原因となった問題（クラッシュ、メタデータ）がすべて修正済みであることを確認してください。
7. 本当に時間が差し迫っている場合は、developer.apple.com/contact/app-store/?topic=expedite で迅速審査をリクエストしてください。
8. 関係者には、「審査のたびに、より多くの問題を修正しています。今回の提出では、プライバシー要件への準拠に包括的に対応しています」と伝えてください。

所要時間の比較

対応方法	承認までの時間
手早く修正して再提出	さらに7〜14日（再び却下される可能性が高い）
全面的な監査と徹底的な修正	3〜5日（承認の可能性が高い）
全面的な監査と迅速審査	1〜3日（認められた場合）

ビジネス向けコミュニケーションテンプレート

To stakeholders:

"Root cause: Our third-party analytics SDK collects device identifiers
that weren't disclosed in our privacy policy or nutrition labels.

Fix: Updated privacy policy, privacy nutrition labels in ASC, and
PrivacyInfo.xcprivacy to accurately reflect all data collection.
Also audited all SDKs for undisclosed collection.

Timeline: Resubmitting today with expedited review request.
Expected approval: 1-3 business days.

Prevention: Adding privacy audit to our pre-submission checklist
so future submissions include accurate disclosure from the start."

---

よくある間違い

1. 却下メッセージを流し読みする

問題 開発者が「ガイドライン5.1」を読み、説明全文を読まずに問題を把握したと思い込んでいます。

失敗する理由 ガイドライン5.1は、プライバシーポリシー、用途説明文字列、プライバシーマニフェスト、トラッキング、データ収集の開示を対象としています。却下メッセージには、どの項目に問題があったかが具体的に記載されています。誤った項目を推測すると、審査サイクルを丸ごと（3〜7日）無駄にします。

対策：却下メッセージの全文をコピーします。記載された具体的な要件をすべて強調表示します。コードを書く前に、それぞれの要件に対応する修正を割り当てます。

2. 指摘された問題だけを修正する

問題 却下理由にガイドライン5.1（プライバシー）が挙げられているため、開発者はプライバシーの問題だけを修正し、ほかに問題がないか確認していません。

失敗する理由 レビュアーは審査のたびに新たな問題を見つけます。最初の審査ではクラッシュ、2回目ではメタデータ、3回目ではプライバシーが見つかることがあります。プライバシーだけを修正すると、4回目にはガイドライン4.8（SIWA）の問題が見つかるかもしれません。

対策：再提出する前に、よくある却下パターン（1〜6）をすべて確認してください。先回りしてすべて修正しましょう。徹底的な提出1回のほうが、不完全な提出を3回繰り返すより効果的です。

3. 変更せずに再提出する

問題 「別のレビュアーなら承認してくれるかもしれない。」

失敗する理由 レビュアーは却下履歴を確認します。変更のない再提出は、同じ結果になるか、上級レビュアーにエスカレーションされます。審査サイクルを無駄にするたびに、3〜7日を失います。

対策：必ず、レビュアーから求められた変更を少なくとも行ってください。却下理由が誤りだと考える場合は、まず ASC で根拠を示して返信してください。

4. App Review のメッセージで感情的に反論する

問題 「これは不公平です！ほかのアプリも同じことをしています！私たちのビジネスを妨害しています！」

失敗する理由 App Review は技術的なコンプライアンス審査であり、交渉の場ではありません。感情的な主張は無視されます。準拠を示す具体的な証拠が有効です。

対策：事実に基づき、具体的かつ専門的に伝えてください。ガイドラインを引用し、スクリーンショットを示し、技術的な証拠を提示してください。

5. サードパーティ SDK の問題を無視する

問題「このデータは収集していません。SDK によるものに違いありません。」

失敗する理由 アプリは、すべての SDK の動作に対して責任を負います。Facebook SDK がデバイス識別子を収集する場合、プライバシーポリシーとプライバシーラベルにその旨を記載する必要があります。

対処方法：サードパーティ SDK をすべて監査します。プライバシーレポートを生成して、収集データの集計を確認します。すべての SDK の動作が対象となるよう、プライバシーポリシーとプライバシーラベルを更新します。

6. 審査中にバックエンドを変更する

問題 アプリの審査中に、API の応答を変更するバックエンドの更新を反映する。

失敗する理由 審査担当者は審査期間中のいつでもテストを行う可能性があります。審査対象のビルドが動作しなくなるバックエンドの変更は、審査中のクラッシュにつながり、ガイドライン 2.1 に基づく却下の原因となります。

対処方法：審査期間中はバックエンドを凍結します。変更が必要な場合は、提出したビルドとの後方互換性を確保します。

7. 利用可能な場合に迅速審査を利用しない

問題 開発者が、緊急時の迅速審査について知らない、または利用しない。

失敗する理由 正当な理由があれば 1 日で完了する迅速審査を利用できるのに、通常審査の 3〜7 日間を待つことになります。

対処方法：重大なバグ修正、期限のあるイベント、セキュリティパッチの場合は、developer.apple.com/contact/app-store/?topic=expedite で迅速審査を申請します。乱用しないでください。Apple は利用状況を追跡しており、今後の申請が却下される可能性があります。

---

提出前チェックリスト

審査での却下を防ぐため、App Store に提出する前に毎回、以下を確認してください。

App Completeness (2.1):
☐ Tested on latest shipping iOS version on physical device
☐ Tested on at least 2 device sizes (iPhone SE, iPhone Pro Max)
☐ No placeholder text (search: Lorem, TODO, FIXME, placeholder, sample)
☐ All URLs resolve (support URL, privacy policy, in-app links)
☐ Demo credentials provided if login required (non-expiring)
☐ Backend stable and not deploying during review window

Metadata (2.3):
☐ Screenshots taken from submitted build (not dev build)
☐ Every feature in description exists and works
☐ No trademarked terms in keywords
☐ Age rating matches content
☐ "What's New" text accurate

Privacy (5.1):
☐ Privacy policy accessible in-app AND via URL in ASC
☐ Privacy policy matches actual data collection
☐ Every permission has specific, honest purpose string
☐ PrivacyInfo.xcprivacy exists and lists all required reason APIs
☐ Privacy Report generated and cross-referenced
☐ ATT implemented if any cross-app tracking
☐ Privacy nutrition labels accurate (including third-party SDKs)

Sign in with Apple (4.8):
☐ If third-party login exists, SIWA offered at same prominence
☐ SIWA flow works: sign in, account creation, revocation handling
☐ Account deletion supported (required since June 2022)

Business (3.x):
☐ All digital goods/features use Apple IAP
☐ IAP products approved in ASC before app submission
☐ Subscription terms clear before purchase
☐ Loot box odds disclosed if applicable

Technical (Binary):
☐ Xcode version meets Apple's current requirements
☐ "Validate App" passes in Xcode Organizer
☐ ITSAppUsesNonExemptEncryption key present
☐ Provisioning profile not expired
☐ Tested with release configuration on device

Safety & Content (1.x):
☐ If UGC: report, block, and moderation workflow all functional
☐ If Kids category: no non-COPPA SDKs, no external links, parental gate on purchases
☐ AI-generated or third-party content has moderation/filtering

Design & Originality (4.2/4.3):
☐ App provides native value beyond a website (offline, push, device APIs)
☐ App is distinct from other apps in your catalog
☐ Demo data pre-populated for reviewer if app needs content to show value

---

関連項目

• app-store-connect-ref — ASC のクラッシュ分析、TestFlight のフィードバック、メトリクスダッシュボード
• privacy-ux — プライバシーマニフェストの実装詳細と必須の理由 API
• storekit-ref — StoreKit 2 のアプリ内課金／サブスクリプションの実装
• accessibility-diag — アクセシビリティへの準拠（VoiceOver、Dynamic Type、WCAG）
• ios-build — バイナリの却下につながるビルドと署名の問題

リソース

WWDC：2025-328

ドキュメント：/app-store/review/guidelines、/distribute/app-review、/support/offering-account-deletion-in-your-app、/contact/app-store/?topic=appeal

スキル：app-store-connect-ref、privacy-ux、storekit-ref、accessibility-diag