app-store-review

App Store 審査の準備

提出前に、App Store での却下につながるリスクを見つけます。ポリシー、SDK、プライバシー、エンタイトルメント、決済、メタデータの確認結果は、永続的な事実ではなく、現在のリリースに関する証拠として扱ってください。

目次

• 主な却下理由と回避方法
• PrivacyInfo.xcprivacy -- プライバシーマニフェストの要件
• データの使用、共有、プライバシーポリシー（ガイドライン 5.1.2）
• アプリ内課金と StoreKit のルール（ガイドライン 3.1.1）
• HIG 準拠チェックリスト
• App Tracking Transparency（ATT）
• EU デジタル市場法（DMA）に関する考慮事項
• エンタイトルメントと機能
• 提出ワークフロー
• メタデータのベストプラクティス
• 異議申し立てのプロセス
• よくある間違い
• 審査チェックリスト
• 参考資料

監査は毎回、最新の App Review Guidelines、Upcoming Requirements、スクリーンショットの仕様、理由が必要な API のドキュメント、該当するストアフロント／エンタイトルメントの決済ルールを取得するところから始めてください。リリースを妨げる各項目について、確認日と情報源を記録します。その後、アーカイブをビルドして提出物そのものを検証し、ブロッカーと改善項目を分け、証拠の不一致を一度に 1 種類ずつ修正してから、再ビルドしたアーカイブに対して同じ確認を再実行します。

キーワード、スクリーンショットのキャプション、プロダクトページのメタデータ、またはメタデータが却下されるリスクに関するプロンプトには、コンプライアンスの観点から回答し、キーワード調査、ランキング戦略、コンバージョン最適化、スクリーンショットの並べ替え、A/B テストは app-store-optimization の対象であることを明示してください。App Review のメタデータに関する案内は、正確性、各フィールドの上限、誤解を招くコンテンツのリスク、スクリーンショットの準拠性に限定してください。日付付きの形式、スクリーンショット、ツールチェーンに関する情報は、現在のリリース要件から読み込んでください。

提出準備状況を完全に監査する場合は、アップロード／審査を妨げる問題と通常の改善項目を分けてください。プライバシーマニフェスト、App Store のプライバシーに関する申告、プライバシーポリシー、ATT の状態、実行時のネットワーク動作、SDK の動作を相互に照合します。申告内容は、観測された動作と一致している必要があります。

提出を妨げる確認項目

通常の改善項目に先立ち、以下をブロッカーとして扱ってください。

• アーカイブが、現在の Xcode またはプラットフォーム SDK のアップロード下限を満たしていない
• プライバシーに関する証拠の不一致が未解決である。これらはPrivacyInfo.xcprivacy の要件に従って解消してください
• StoreKit のルールに準拠しない決済経路がある
• 現在の App Store Connect の仕様で必須となっているスクリーンショット一式が不足している
• 以下のガイドライン 2.1 の完全性に関する証拠に照らして、審査用アクセスに問題がある

主な却下理由と回避方法

ガイドライン上のリスク	リリースの証拠
2.1 完全性	プレースホルダー、動作しない／空のフロー、アクセスできないハードウェア専用機能、または有効なデモ用認証情報と審査メモがないログインゲートが存在しないこと。
2.3 メタデータ	アプリ名、カテゴリ、説明、キーワード、スクリーンショットが、提出するバイナリと実際の UI を正確に表していること。
4.2 最低限の機能	アプリが、簡素なウェブサイトやシステム動作の単純な重複を超える、アプリ固有の有意義な価値を提供していること。
2.5.1 ソフトウェア要件	アーカイブが公開 API を使用し、文書化された例外に該当しない限り、審査済みの機能を変更するコードをダウンロードしないこと。

これらは最新のガイドラインと提出するアーカイブそのものに照らして検証してください。以前のリリースチェックリストに記載されたバージョン要件やスクリーンショット要件を引き継がないでください。

PrivacyInfo.xcprivacy — プライバシーマニフェストの要件

アプリのコード、実行ファイル、動的ライブラリ、またはサードパーティ製 SDK が、Apple の理由が必須の API カテゴリを使用する場合、または収集データ／トラッキング動作を宣言する場合、プライバシーマニフェストが必要です。

参照： references/privacy-manifest.md で、完全な構造、理由コード、チェックリストを確認してください。

概要

• 理由が必須の API カテゴリは、ファイルのタイムスタンプ、システムの起動時刻、ディスク容量、アクティブなキーボード、UserDefaults です。これらを使用する場合は、それぞれ承認済みの理由コードが必要です。
• 最終提出の前に、Apple の最新の理由が必須の API に関するドキュメントを再確認し、適用範囲が広すぎる、都合のよい、または独自に作成した理由コードを選ばないでください。
• 理由が必須の API の宣言は、その API を使用するコードを含むバンドルに記述します。マニフェストに関係するコードを含むすべてのアプリターゲット、実行ファイル、動的ライブラリ、フレームワーク、または SDK バンドルに、対応するマニフェスト宣言が必要です。
• データを収集する、理由が必須の API を使用する、データ収集／トラッキングを有効にする、またはトラッキングドメインに接続する各 SDK、実行ファイル、または動的ライブラリについて、そのコードを含むバンドルでマニフェストへの対応が必要です。SDK のコードは、SDK 自身の使用状況の報告をホストアプリのマニフェストに委ねることはできません。
• マニフェストの宣言は、App Store のプライバシー情報ラベル、SDK の動作、アプリが提示する機能と一致している必要があります。

データの使用、共有、プライバシーポリシー（ガイドライン 5.1.2）

• App Store Connect でプライバシーポリシーの URL を設定し、アプリ内からもアクセスできるようにする必要があります。
• プライバシーポリシーには、収集するデータ、その使用方法、共有先を正確に記載する必要があります。
• App Store のプライバシー情報ラベルは、実際のデータ収集方法と一致している必要があります。
• プライバシーラベル、プライバシーマニフェスト、SDK の開示情報、実行時の動作は、すべて一貫している必要があります。

アプリ内課金と StoreKit のルール（ガイドライン 3.1.1）

デジタル商品、機能、サブスクリプション、仮想通貨、広告の削除、デジタルチップには、現行のガイドラインの例外、ストアフロントのルール、または承認済みの権利が適用される場合を除き、通常 IAP が必要です。物理的な商品や現実世界のサービスには、通常の支払いフローを使用します。購入前に、価格、期間、更新／トライアル条件、請求頻度、キャンセル条件を提示してください。商品分類、復元、権利の検証、保留／中断された購入、Ask to Buy を確認してください。実装には storekit を読み込み、準拠と表示する前に、地域ごとの最新ルールと外部リンクに関するルールを再確認してください。

HIG 準拠チェックリスト

ナビゲーション、モーダル、ウィジェット、システム機能、起動画面、空の状態に関する HIG の全チェック項目は、review-checklists.md から読み込んでください。

App Tracking Transparency（ATT）

ATT が必要な場合

アプリが、他社のアプリや Web サイトをまたいでユーザーをトラッキングする場合は、次の対応が必要です。

1. トラッキング機能を持つ SDK の動作も含め、アプリ間または Web サイト間のトラッキングが発生する前に、ATTrackingManager.requestTrackingAuthorization で許可を求める
2. ユーザーの選択を尊重する。ユーザーが許可しない場合は、アプリ間および Web サイト間のトラッキングを無効にする
3. トラッキングへの同意をアプリ機能の利用条件にしない（「トラッキングに同意しないと、このアプリは使用できません」という要求は却下されます）
4. トラッキングの目的を説明する明確な文言を NSUserTrackingUsageDescription に設定する

ATT が不要な場合

アプリ間または Web サイト間でユーザーをトラッキングしない場合は、ATT の確認画面を表示しないでください。不要な ATT の確認画面は Apple に却下されます。

ATT の実装

import AppTrackingTransparency

@MainActor
func requestTrackingPermission() async {
    let status = await ATTrackingManager.requestTrackingAuthorization()
    switch status {
    case .authorized:
        // Enable tracking, initialize ad SDKs with tracking
        break
    case .denied, .restricted:
        // Use non-personalized ads and disable cross-app/cross-website tracking
        break
    case .notDetermined:
        // Should not happen after request, handle gracefully
        break
    @unknown default:
        break
    }
}

タイミング： アプリがアクティブになり、トラッキングの許可を求める理由をユーザーが理解できる状況になってから、ATT の許可を求めてください。初回起動直後に確認画面を表示したり、別のシステム権限の確認画面と重ねて表示したりしないでください。

EU デジタル市場法（DMA）に関する考慮事項

代替配信、ブラウザーエンジン、公証、外部決済の各経路は、地域および権利に応じて異なります。最新のストアフロントのルールを再確認し、サポートされていない経路はブロッカーとして扱ってください。

エンタイトルメントと機能

各エンタイトルメントには、有効な機能、該当する場合は具体的な用途の説明、および対応するアーカイブ時の動作が必要です。エンタイトルメントと用途の説明にある表と有効なプロパティリストの例を使用してください。

提出ワークフロー

提出前の手順

1. Xcode でアーカイブします。 Product > Archive（配布用の署名 ID が必要です）。Release 構成で警告がゼロの状態でアーカイブが正常にビルドされることを確認してください。
2. App Store Connect にアップロードします。 Organizer ウインドウ（Distribute App > App Store Connect）または xcodebuild -exportArchive を使用します。altool または Transporter による自動アップロードも利用できます。
3. TestFlight の内部テストを行います。 処理後、数分以内に内部テスター（チーム）へビルドが公開されます。少なくとも 2 種類のデバイスサイズで、すべての画面と操作フローを確認してください。
4. TestFlight の外部テストを行います。 外部グループへの初回配信には、ベータ版 App Review が必要です。正式提出の前に、実際のユーザーで検証するために利用してください。
5. App Review に提出します。 App Store Connect でビルドを選択し、すべてのメタデータ欄に入力してスクリーンショットを添付し、Submit for Review をクリックします。審査にかかる時間は異なるため、却下、異議申し立て、メタデータの修正に備えて余裕を持たせてください。

迅速審査のリクエスト

迅速審査は、Apple が文書化している重大または時間的制約のあるケースに限ってリクエストし、App Store Connect の Contact Us フォームで簡潔かつ事実に基づく理由を説明してください。

段階的リリース

ロールアウト率と App Store Connect の設定については、段階的リリースのスケジュールを参照してください。

メタデータのベストプラクティス

名前、サブタイトル、キーワード、スクリーンショット、プレビューは、提出するバイナリと実際の UI に正確に合わせてください。価格、競合他社の用語、誤解を招く表現は使用しないでください。メタデータ準拠チェックリストに記載されている各欄の文字数制限とメディアのルールを守り、調査、ランキング、コンバージョン、スクリーンショットの並べ替え、A/B テストは app-store-optimization に委ねてください。

異議申し立てのプロセス

App Store Connect の Resolution Center で、簡潔な証拠の記録を添えて回答してください。

• 却下理由を、指摘されたガイドラインと提出したアプリの具体的な動作に結び付けます。
• 修正した場合は、変更箇所を明確に示して再提出します。異議がある場合は、提出内容が該当する要件をそれぞれどのように満たしているか説明します。
• 動作するデモ用の認証情報、スクリーンショット、要点を絞った動画による説明など、準拠を再現するために必要な証拠を添付します。
• やり取りを続けても解決しない場合は、Resolution Center または App Store Contact フォーム（App Review > Appeal）から App Review Board へのエスカレーションをリクエストし、提出の全履歴と裏付けとなる証拠を添付します。

Board の決定はその提出に対して最終的なものですが、アプリを変更して再提出することは引き続き可能です。

よくある間違い

1. 用途の説明が曖昧です。 データを使用する具体的な機能を明記してください。
2. コード品質を審査への準拠とみなします。 並行処理やトランザクションの正しさだけでは、プライバシー、支払い、メタデータ、エンタイトルメントに関する証拠の代わりにはなりません。

レビューチェックリスト

提出前に毎回簡易チェックを行います（完全版はreferences/review-checklists.mdを参照してください）。

• ガイドライン 2.1 の完全性およびレビューアクセスが提出をブロックするチェック項目に合格している
• アプリ名とスクリーンショットがバイナリおよび現行リリース要件に一致している
• プライバシー関連の証拠がPrivacyInfo.xcprivacy の要件に合格している
• プライバシーポリシーの URL が設定され、アプリ内からアクセスできる
• 支払いフローがStoreKit のルールに合格している
• ダークモードとダイナミックタイプに対応しており、標準的なナビゲーションパターンを使用している
• アーカイブとエンタイトルメントが提出をブロックするチェック項目に合格している
• ATT の動作がATT の基準に合格している

参考資料

• レビューチェックリスト：references/review-checklists.md
• プライバシーマニフェストガイド：references/privacy-manifest.md
• Apple App Review ガイドライン：https://developer.apple.com/app-store/review/guidelines/
• Apple の今後の SDK 要件：https://developer.apple.com/news/upcoming-requirements/
• App Store Connect のスクリーンショット仕様：https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications/
• Sosumi の required-reason API ドキュメント：https://sosumi.ai/documentation/bundleresources/describing-use-of-required-reason-api