App Store審査でリジェクトされやすいポイントと、個人開発者の対処法
初めてのアプリ申請で、英語のリジェクト通知が届くと焦ります。ただ、指摘される内容にはある程度パターンがあり、事前に潰せるものがほとんどです。個人開発で特に指摘されやすい項目を中心に整理しました。
リジェクトは「やり直しの案内」
App Storeの審査で不合格になることを、リジェクト（Rejected）と呼びます。初めて受け取ると落ち込みますが、リジェクトはアカウントへの罰ではなく、「ここを直せば公開できます」という案内です。指摘された点を直して再提出すれば、多くの場合は通ります。
リジェクトの通知には、「Guideline 2.1 - Performance - App Completeness」のように、根拠となるガイドラインの番号が書かれています。番号はAppleの「App Reviewガイドライン」の項目に対応しているので、まずは番号から何を指摘されているのかをつかみます。ガイドラインは日本語版も公開されています。
個人開発でよく指摘される項目
| 番号 | 内容 | よくある原因 |
|---|---|---|
| 2.1 | アプリの完成度 | 起動直後のクラッシュ、押しても反応しないボタン、「準備中」の画面、ログインできない |
| 2.3 | 正確なメタデータ | スクリーンショットがアプリの実際の画面と違う、説明文に存在しない機能を書いている |
| 4.2 | 最低限の機能 | Webサイトを表示するだけ、機能が少なすぎてアプリである意味が薄い |
| 4.3 | スパム | ほぼ同じ内容のアプリを、名前や色だけ変えて複数出している |
| 5.1.1 | データの収集と保存 | プライバシーポリシーがない、許可の説明文があいまい、アカウント削除ができない |
| 5.1.2 | データの使用と共有 | トラッキングするのにATTの確認を出していない |
項目ごとの対処法
2.1 アプリの完成度
審査担当者は、実際にアプリをインストールして操作します。自分の端末では動くのに審査でクラッシュする場合、次のような環境の違いが原因になっていることが多いです。
- iPadでの表示：iPhone向けに作ったつもりでも、iPadに対応する設定のままだと、審査ではiPadでも確認されます。レイアウトが崩れていればリジェクトの対象です。iPadで確認するか、対応しないならXcodeの設定でiPhoneだけにします。
- 通信できない状態：オフラインやサーバーの停止時に、何も表示されないまま固まらないか確認します。
- ログインが必要なアプリ：審査担当者が使えるデモ用のアカウントを、App Store Connectの「App Review に関する情報」に必ず記入します。
- 最新のOS：審査は新しいOSで行われることが多いので、最新のiOSでも動作確認しておきます。
審査担当者から質問が届くこともあります（「Information Needed」）。これはリジェクトとは少し違い、返信して説明すれば審査が進みます。
2.3 正確なメタデータ
ストアのスクリーンショットは、アプリの実際の画面を使う必要があります。画面を飾り付けることや説明の文字を入れることは問題ありませんが、存在しない機能を見せたり、写真素材だけの画像を使ったりするのは避けましょう。
見落としやすいのが、説明文に「Android版もあります」のように他のプラットフォームの名前を書くことです。メタデータで他のモバイルプラットフォームに触れることは認められていません。また、アプリ名にキーワードを詰め込みすぎるのも指摘の対象です。
4.2 最低限の機能
自分のWebサイトを画面いっぱいに表示するだけのアプリは、ここで指摘されやすいです。「Webサイトではなく、アプリだからこそできること」が求められます。たとえば、オフラインでも使える、通知で知らせる、カメラやセンサーを使う、端末内にデータを保存して使いやすくする、といった要素です。
シンプルなツールアプリ自体が禁止されているわけではありません。機能が少なくても、目的がはっきりしていて、きちんと作り込まれていれば公開できます。
4.3 スパム
同じ仕組みのアプリを、テーマや色だけ変えて何本も申請すると、スパムと判断されることがあります。似たアプリを複数作りたい場合は、1つのアプリの中でテーマを選べるようにする、アプリ内課金でコンテンツを追加する、といった形にまとめることを求められます。
5.1.1 データの収集と保存
個人開発でいちばん多く見かける指摘の一つです。
- プライバシーポリシー：すべてのアプリで、App Store Connectにプライバシーポリシーのリンクを設定する必要があります。アプリ内からも見られるようにしておくと確実です。
- 許可の説明文：カメラや写真の許可を求めるときの説明文（Info.plistの
NSCameraUsageDescriptionなど）は、「何のために使うか」が具体的に分かる文章にします。「カメラを使用します」だけでは不十分とされることがあります。 - アカウント削除：アプリ内でアカウントを作れる場合は、アプリ内からアカウントを削除する手段も用意する必要があります。
<!-- 説明文の例（Info.plist） -->
<key>NSCameraUsageDescription</key>
<string>写真を撮影して、加工する画像として使うためにカメラを使用します。</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>加工する写真を選ぶために、写真ライブラリにアクセスします。</string>日本語で使われるアプリなら、説明文も日本語で用意しましょう。英語のままだと、利用者にも審査担当者にも意図が伝わりにくくなります。
5.1.2 データの使用と共有（ATT）
広告SDKなどで、他社のアプリやWebサイトをまたいで利用者を追跡（トラッキング）する場合は、App Tracking Transparency（ATT）の確認画面を出して許可を得る必要があります。また、App Store Connectのプライバシー情報（App Privacy）にも、収集するデータを正しく申告します。ATTの確認画面を出す順番や実装方法は、FlutterでATT・同意フォーム・AdMobを組み込む順番にまとめています。
返信と再提出のしかた
リジェクトされたら、App Store Connectのアプリのページから審査担当者とのやりとり（メッセージ）を開けます。対応の流れは次のとおりです。
- 指摘されたガイドラインの番号と本文を読み、添付されたスクリーンショットがあれば確認します。
- アプリの修正が必要なら、修正してビルド番号を上げ、新しいビルドをアップロードします。
- ストアの説明文やスクリーンショットだけの問題なら、メタデータを直すだけで再審査を依頼できます（新しいビルドは不要）。
- メッセージで「何をどう直したか」を簡潔に伝え、再提出します。
返信は英語が基本ですが、短く具体的に書けば十分です。たとえば次のような形です。
Hello,
Thank you for your review.
We have updated the purpose string for camera access to explain
that the camera is used to take photos for editing in the app.
The new build (1.0.0 (3)) has been submitted.
Best regards指摘が誤解に基づいていると思う場合は、その理由を丁寧に説明して返信できます。それでも納得できない場合は、App Review Boardに異議を申し立てる仕組みもあります。ただ、感情的な文面は逆効果です。事実と、該当するガイドラインの解釈を落ち着いて伝えましょう。
申請前のチェックリスト
- iPhoneの最新OSで、インストールから主要な機能まで一通り操作した（iPad対応ならiPadでも）。
- 機内モードでも固まったりクラッシュしたりしない。
- 「準備中」「Coming soon」の画面や、反応しないボタンが残っていない。
- ログインが必要なら、審査用のデモアカウントを記入した。
- プライバシーポリシーのURLが開ける。App Privacyの申告内容がアプリの実際の動きと合っている。
- 許可の説明文が、具体的な目的を日本語で説明している。
- スクリーンショットと説明文が、実際のアプリの内容と一致している。他のプラットフォームの名前を書いていない。
- 広告は本番用のIDになっている（テスト用IDのまま申請していない）。
- サポート用のURL（問い合わせ先）が開ける。
Appleのガイドラインは定期的に更新されます。申請前には、公式のガイドラインの最新版にも目を通しておくと安心です。