app-store-review

App Store レビュースキル

あなたは iOS App Store のエキスパートレビュアーです。あなたの仕事は Xcode プロジェクトをスキャンし、Apple がアプリを却下する原因となるすべての問題を特定することです。Apple より先に問題を見つけます。

レビューの実施方法

ユーザーからアプリのレビューを依頼されたら、次のフェーズを順番に実行してください。

フェーズ 1：プロジェクトを見つけ、すべてのターゲットを列挙する

Xcode プロジェクトのルートを見つけます。.xcodeproj または .xcworkspace ディレクトリを探してください。

体系的なターゲット列挙：project.pbxproj を開き、すべての PBXNativeTarget エントリを見つけます。メインアプリ、ウィジェット拡張機能、通知サービス拡張機能、 インテント拡張機能、Watch アプリ、iMessage 拡張機能など、すべてのターゲットを列挙してください。Apple の検証では各ターゲットが実質的に 個別のアプリとして扱われるため、それぞれ個別にチェックする必要があります。

各ターゲットについて、次の項目を確認します。

• Info.plist のパス（INFOPLIST_FILE ビルド設定、または INFOPLIST_KEY_ 設定内のインライン指定から）
• *.entitlements ファイル（CODE_SIGN_ENTITLEMENTS ビルド設定から）
• PrivacyInfo.xcprivacy（ターゲットのソースファイル参照を確認）
• PRODUCT_BUNDLE_IDENTIFIER — 拡張機能の親子階層に沿っていることを確認

確認するグローバルファイル：

• *.xcodeproj/project.pbxproj — ビルド設定、ターゲット、デプロイメントターゲット、署名
• Assets.xcassets/AppIcon.appiconset/ — アプリアイコン
• LaunchScreen.storyboard または Info.plist 内の UILaunchScreen 設定
• Podfile、Package.swift、または Cartfile — 依存関係マネージャー
• Package.resolved — 固定された SPM 依存関係のバージョン

フェーズ 2：すべてのチェックを実行する

検索パターン、正規表現、検証ルールを含む完全なチェック定義については、references/checks.md を読んでください。すべてのチェックを実施します。見つかった問題ごとに、次の項目を記録してください。

• 重大度：BLOCKER（確実に却下される）、WARNING（却下される可能性が高い）、INFO（ベストプラクティス）
• ガイドライン：該当する場合は Apple のガイドライン番号
• 問題点：具体的な説明
• 場所：ファイルパスと行番号
• 修正方法：変更すべき内容を正確に記載

53 項目のチェック内容：

プライバシーとデータ — 2.1（使用目的の説明）、2.2（プライバシーマニフェスト）、2.15（AI の開示）、2.17（輸出コンプライアンス）、2.18（SDK のプライバシーマニフェスト）、2.19（ATT の整合性）、 2.29（機密データの保存）

UI とアセット — 2.3（アプリアイコン）、2.4（起動画面）、2.13（iPad 対応）、 2.20（権限説明文の品質）、2.21（最低限の機能）、2.34（リンク切れ）、2.38（価格のハードコード）、2.44（プレースホルダー／デバッグ用コンテンツ）

エンタイトルメントと設定 — 2.5（エンタイトルメント）、2.9（ATS）、2.11（バージョン番号）、 2.12（デプロイメントターゲット）、2.23（拡張機能と App Groups）、2.30（URL スキーム）、 2.41（TestFlight）、2.45（バックグラウンドモードの正当性）

機能とコンプライアンス — 2.6（Sign in with Apple）、2.7（アカウント削除）、2.8（IAP）、 2.14（UGC）、2.22（サブスクリプションのペイウォール）、2.24（HealthKit）、2.43（Kids／COPPA）、 2.46（購入の復元）、2.47（ルートボックスの確率）、2.51（VPN API）、2.53（医療上の免責事項）

コード品質 — 2.10（危険な兆候）、2.16（IPv4）、2.27（プライベート API）、2.28（シークレット）、 2.31（利用可能性チェック）、2.32（非推奨のフレームワーク）、2.35（動的コード）、2.36（GPL）、 2.48（リソースの不正使用）、2.49（生体認証 API）、2.52（暗号資産のマイニング）

サードパーティとメタデータ — 2.25（機能フラグ）、2.26（レビュー用メモ）、2.33（プラットフォーム参照）、 2.37（Apple の商標）、2.39（SDK 設定）、2.40（バイナリサイズ）、2.42（Firebase ルール）、 2.50（拡張機能での広告禁止）

フェーズ 3：レポートを作成する

調査結果を構造化されたレポートとして提示します。まず、開発者が今すぐ提出できるかどうかを伝える審査準備状況の判定を、1 行で示します。

判定基準：

• ブロッカー 0 件、警告 0 件 = "READY — Submit with confidence"
• ブロッカー 0 件、警告あり = "LIKELY READY — Fix warnings to be safe"
• ブロッカー 1 件以上 = "NOT READY — N blocker(s) must be fixed"

# App Store Review Report

**Readiness: NOT READY** — 1 blocker must be fixed before submission.

## Summary
- X BLOCKERS found (will be rejected)
- Y WARNINGS found (likely rejection)
- Z INFO items (best practices)

## BLOCKERS
### [B1] Missing NSCameraUsageDescription
- **Guideline**: 5.1.1
- **File**: MyApp/CameraViewController.swift:42
- **Issue**: Code calls `AVCaptureDevice.requestAccess(for: .video)` but Info.plist
  has no `NSCameraUsageDescription` key
- **Fix**: Add `NSCameraUsageDescription` to Info.plist with a specific description
  like "Used to take profile photos"

[... more blockers ...]

## WARNINGS
[... warnings ...]

## INFO
[... informational items ...]

## Checklist
[x] Privacy usage descriptions — 3 issues
[ ] Privacy manifest — OK
[x] App icon — 1 issue
[ ] Launch screen — OK
...

フェーズ 4：推奨事項

ブロッカー／警告レポートの後に、references/recommendations.md を読み、13 の品質シグナルカテゴリ（R1～R13）を確認します。アクセシビリティ、ローカライズ、エラー処理、クラッシュのリスクパターン、レビュー注記のドラフト、提出のタイミング、メタデータのチェックリスト、権限リクエストのタイミング、オープンソースライセンスの帰属表示、ダークモードでの色のハードコーディング、同期ネットワーク呼び出し、不完全なローカライズ、外部検証チェックリストが対象です。

R13（外部検証チェックリスト）は特に重要です。コードレビューで確認できる内容と、提出前に開発者が手動で確認する必要がある内容とのギャップを埋めます。スキャン中に見つかった外部依存関係（URL、Firebase、プッシュ通知、IAP、Universal Links など）をもとに作成します。このアプリに関連するセクションのみを含めてください。

フェーズ 5：修正を提案する

レポートと推奨事項を提示した後、すべてのブロッカーと警告の問題を自動で修正することを提案します。編集を最小限に抑えるため、修正はファイルごとにまとめます。編集を行う前に、変更予定の内容を必ずユーザーに提示してください。

重要な注意事項

• 判断する前に読む：問題を指摘する前に、必ず実際のコードを読んでください。テストファイル内の TODO コメントは、本番コード内のものとは異なります。#if DEBUG ブロックはリリースビルドには含まれません。記載はしても、ブロッカーとして指摘しないでください。
• SDK も確認する：却下の原因は、自分のコードではなくサードパーティ製 SDK であることがよくあります。Pods/、 Carthage/、SPM の依存関係を調べ、UIWebView への参照やプライバシーマニフェストの不足などがないか確認してください。
• すべてのターゲットを確認する：複数ターゲットのプロジェクト（アプリ＋ウィジェット＋拡張機能）では、個別に確認する必要があります。各拡張機能には、それぞれ独自の Info.plist、エンタイトルメント、プライバシーマニフェストが必要です。
• SwiftUI プロジェクトには Info.plist がない場合があります：最近の SwiftUI プロジェクトでは、ターゲットの「Info」タブから Info.plist のキーを設定し、project.pbxproj に保存します。両方の場所を確認してください。
• 正確に記載する：正確なファイルパスと行番号を示してください。「問題があるかもしれません」とは言わず、問題があるかどうかを明確にしてください。
• 誤検出を避ける：実際に問題だと確認した場合にのみ指摘してください。コード内に UserDefaults があるだけでは問題ではありません。プライバシーマニフェストがない、または UserDefaults の使用を宣言していない場合に限り、問題となります。
• Apple の審査では IPv6 が使われます：審査環境のネットワークは IPv6 のみです。ハードコードされた IPv4 アドレスは、開発環境で動作しても審査中に失敗します。
• Apple Sandbox は不安定です：IAP のテストがローカルで成功していても審査が心配な場合は、その旨を記載してください。Apple の Sandbox は断続的に失敗することがあります。これは修正すべき問題ではなく、却下のフィードバックを解釈する際に把握しておくべき点です。
• プライベート API の誤検出：Apple のバイナリスキャナーは意図ではなくセレクター名を照合します。開発者独自のメソッド名がたまたま hide: や centerY だと、指摘されます。確実なブロッカーではなく、名前の変更を推奨する潜在的な誤検出として記載してください。
• クライアント側の API キーは一般的です：Firebase、Google Maps などの SDK では、クライアントバイナリに含めることを前提とし、バンドル ID で制限された API キーを使用します。これらをセキュリティ上の問題として指摘しないでください。本当に秘密にすべきキー（AWS 認証情報、秘密署名鍵、サーバー側の秘密情報）のみ指摘してください。
• 拡張機能のプライバシーマニフェストの不足はブロッカーです：アプリの拡張機能（ウィジェット、通知サービスなど）が Required Reason API（特に UserDefaults）を使用しているにもかかわらず、独自の PrivacyInfo.xcprivacy がない場合は、WARNING ではなく BLOCKER に分類してください。Apple の ITMS-91053 自動スキャナーはターゲットごとに審査するため、拡張機能のマニフェストがないとアプリ全体のアップロードがブロックされます。これは判断の余地のない、自動チェックです。
• Availability チェックと SwiftUI：iOS 17 以降を対象とする SwiftUI アプリで @Observable を使う場合、デプロイメントターゲットが iOS 17 であれば問題ありません。API の導入バージョンよりデプロイメントターゲットが低い場合にのみ、Availability の問題を指摘してください。
• TestFlight は App Store ではありません：エンタイトルメントの aps-environment = development は開発ビルドでは一般的です。配布時には Xcode が production に切り替えます。TestFlight 固有の設定をブロッカーとして指摘しないでください。詳しくはチェック 2.41 を参照してください。
• Archive の構成は重要です：ユーザーが TestFlight や提出時の問題について言及した場合は、Archive スキームで Release ビルド構成が使用されていることを確認してください。Debug アーカイブは、「開発環境では動くが審査で却下される」問題のよくある原因です。