App Store審査のリジェクトへ返信するときは、すぐに新しいbuildを作るのではなく、Appleがどのitemで、どのガイドラインに対し、何を確認できなかったのかを分けます。metadataの修正だけで済む指摘と、アプリの動作を直す指摘では、再提出までの手順が異なります。
反論の文章を長くするより、次の審査担当者が同じ箇所へ到達し、変更後の状態を確認できる情報をそろえることが先です。
リジェクトメッセージを五項目へ分解する
App Store Connectのメッセージから、次を作業メモへ転記します。
| 項目 | 確認する内容 |
|---|---|
| 対象item | アプリbuild、metadata、In-App Purchase、In-App Eventなど |
| ガイドライン | 番号とAppleが示した該当箇所 |
| 審査時の状態 | 画面、操作、エラー、アクセスできなかった機能 |
| 不足している情報 | ログイン方法、設定、添付、説明、再現手順 |
| 次の操作 | 質問、metadata修正、binary修正、item削除、Appeal |
スクリーンショットだけを見て理由を推測せず、メッセージ本文とガイドラインの現行文を照合します。App Review Guidelinesは更新されるため、以前の審査で通った説明だけを根拠にしないでください。
複数の指摘がある場合は、一通の返信へ混ぜる前に行を分けます。一つ目はmetadata、二つ目はログイン不可、三つ目はアプリ内動作というように、指摘ごとに対応と確認方法を対応付けます。
質問、修正、Appealを選ぶ
返信前に、次のどれで進めるか決めます。
追加情報を送る
アプリは要件を満たしているが、審査担当者が機能へ到達できなかった場合に使います。
- 操作入口が分かりにくかった
- 特定の権限、地域、アカウント状態が必要だった
- 審査用アカウントやsample dataが不足していた
- non-obviousな機能をReview Notesで説明していなかった
アプリを変更していないなら、「修正しました」と書かず、審査時に確認できなかった理由と正しい手順を示します。
修正して再提出する
指摘された動作やmetadataが実際にガイドラインと一致していなかった場合に選びます。何を変更したかだけでなく、変更後を確認する手順も返信へ含めます。
AppleのApp Reviewメッセージ返信手順では、metadata issueを解消した場合は同じbuildを再提出できると案内しています。アプリ内の動作やbinaryを変更した場合は、修正版のbuildをアップロードし、返信にbuild番号を記載します。
Appealを提出する
事実関係を説明しても審査結果が変わらず、アプリの概念や機能が誤解されている、または不公平な扱いだと考える場合はAppealを検討します。
AppleのApp Review案内では、ガイドラインへ適合すると考える具体的理由を示し、追加情報の依頼にはAppeal前に回答するよう求めています。不合格になったsubmissionに対するAppealは一件だけなので、最初の質問を省略して感情的な反論を送る用途には向きません。
返信を確認可能な順番で書く
返信は次の五ブロックに分けると、指摘と対応の関係が崩れにくくなります。
- 対象のガイドラインとitem
- 指摘をどう理解したか
- 修正または追加した情報
- 確認できる操作手順
- build番号と添付資料
修正後の返信は、次の型から不要な行を削って使えます。
Hello App Review Team,
Thank you for the message regarding Guideline [number].
We understood that App Review could not verify [specific feature or information].
We have [updated the metadata / uploaded a corrected build / provided additional access information].
Steps to review:
1. [starting screen]
2. [operation]
3. [expected result]
Build: [build number]
Supporting screenshots or documents are attached where applicable.
Thank you for reviewing the updated submission.
アプリを変更していない場合はuploaded a corrected buildを残しません。複数の指摘がある場合はGuideline [number]ごとに段落を分け、同じ修正で解決したように見せないでください。
添付は「何を示すか」を決めてから付ける
App Reviewの返信画面では、スクリーンショットや補足資料を添付できます。添付数を増やすのではなく、各資料がどの確認を助けるかを返信内で示します。
| 添付 | 示す内容 |
|---|---|
| 画面のスクリーンショット | 修正後の表示、機能への入口 |
| 短い操作動画 | 複数画面を通る手順、端末機能との連携 |
| 設定の画像 | Review Notesだけでは伝わりにくい前提 |
| 公開資料 | ライセンス、仕様、権利関係など指摘された根拠 |
個人情報、実ユーザーのアカウント、秘密鍵、productionの認証情報を証拠として添えないでください。審査用に必要なアクセス情報は、実ユーザーの情報と分けます。
Unresolved Issuesでitemを整理する
submissionに含めた複数itemの一部がrejectedになると、状態はUnresolved Issuesになります。AppleのUnresolved Issues管理手順では、すべてのitemが承認される必要があり、accepted itemだけを進めるにはrejected itemを編集して再提出するか、submissionから削除します。
判断はitemごとに行います。
- 今回のリリースに必要：修正して
Add for Reviewへ戻す - 今回は含めない：submissionから削除する
- accepted itemだけで公開可能：rejected itemを外して進める
Unresolved Issuesのsubmissionへ新しいitemは追加できません。また、一度削除したitemを同じsubmissionへ戻すこともできません。削除は「後で簡単に戻せる保留」ではないため、今回のリリースに必要か確認してから実行します。
編集または削除が終わったら、submission詳細のResubmit to App Reviewまで進めます。メッセージへ返信しただけで再提出操作も完了したと考えないでください。
再提出前に審査環境を自分で再現する
Appleは提出前の確認として、クラッシュと不具合、metadata、連絡先、審査用アクセス、backend、Review Notesを挙げています。返信を送る前に、審査担当者と同じ条件を想定して確認します。
- 対象buildを新規インストールする
- 審査用アカウントでログインする
- backendと必要な外部サービスへ接続できる
- 指摘された操作を最初から最後まで行う
- App Store Connectのmetadataと実際の画面が一致している
- Review Notesだけで特殊な前提を理解できる
- 添付したURLをログアウト状態で開ける
同じガイドライン違反を繰り返すと審査が長引く可能性があります。返信文の送信を完了条件にせず、指摘された状態が再現しないことと、担当者が変更点へ到達できることを確認します。
Support URLの指摘だけIndieFormへ接続する
IndieFormはApp Review Teamへの返信を送信せず、リジェクト理由を自動でAppealするサービスでもありません。審査メッセージへの対応はApp Store Connectで行います。
指摘がSupport URLのリンク切れ、問い合わせ手段の不足、対象アプリが分からないページに関する場合は、アプリ専用の公開フォームを用意する選択肢があります。IndieFormはアプリごとの問い合わせURLを発行できるため、ページを公開し、ログアウト状態で開いて送信できるところまで確認してからApp Store Connectへ設定できます。
Support URLに必要な内容と役割は、App StoreのサポートURLを用意する方法で整理しています。プライバシーポリシーや審査用ログイン情報の代わりにはならないため、指摘されたitemが別ならIndieFormへ結び付けず、その要件を直接修正してください。
リジェクトへの返信は、説明の量ではなく、指摘、変更、確認手順が一対一で対応しているかで見直します。次の担当者が同じ場所を迷わず確認できる状態になってから、返信と再提出を完了させます。