ログイン必須のiOSアプリをApp Storeへ提出するときは、審査担当者が主要機能を最後まで確認できるデモアカウントを用意します。ユーザー名とパスワードが正しくても、初回設定で止まる、データが空、権限が足りない、backendへ接続できない状態では、審査用アクセスとして十分ではありません。
デモアカウントは「ログインできる資格情報」ではなく、「審査対象の機能へ再現可能に到達するテスト経路」として準備します。
App Review Informationの三つの欄を分ける
App Store ConnectのApp Review Informationでは、情報の役割を分けて入力します。
| 欄 | 入れる内容 |
|---|---|
| Contact | App Reviewから追加確認を受け取れる担当者の氏名、メール、電話番号 |
| Sign-in required | 基本となるデモアカウントのusernameとpassword |
| Notes | 操作手順、追加アカウント、特殊な設定、確認してほしい機能 |
AppleのPlatform version informationでは、ログイン必須アプリにデモアカウントのusernameとpasswordを求めています。この情報は顧客には表示されず、いつでも編集できます。
追加のroleを持つアカウント、test registrationの詳細、アプリ固有の設定が必要な場合はNotesへ記載します。最初のアカウント情報へすべての説明を詰め込まず、認証情報と操作説明を分けると更新漏れを見つけやすくなります。
審査用アカウントの成立条件を確認する
提出前に、審査用アカウントが次の条件を満たすか確認します。
- 審査期間中に期限切れしない
- 初回ログイン後のメール確認や管理者承認を必要としない
- 審査対象の主要機能へ必要なroleとplanを持つ
- 年齢、地域、組織所属などの条件で機能が隠れない
- サンプルデータがあり、空画面だけにならない
- 実ユーザーの個人情報や本番データを含まない
- password resetや自動削除の対象にならない
公式リファレンスは、デモアカウントがApp Review中に期限切れしてはいけないと明記しています。審査開始日時を予測して短い有効期限を設定するのではなく、submissionが完了するまで利用できる状態を維持します。
一方で、実ユーザーのアカウントを渡したり、普段使っている管理者の認証情報を流用したりする必要はありません。審査専用のデータと権限を用意し、対象機能の確認に不要な本番情報へアクセスさせない構成にします。
MFAやSSOで担当者を待たせない
認証に追加操作があるアプリは、「誰が、いつ、どの画面で承認するか」を提出前に解消します。
Single Sign-On
Appleは、FacebookやXなどのsingle sign-on serviceを使う場合も、審査用のlogin informationを含めるよう案内しています。SSOのボタンだけを示すのではなく、その先で使用できるデモ資格情報を用意します。
MFAとワンタイムコード
開発者が都度コードを転送しないとログインできない状態は、時差や連絡待ちで審査を止めます。審査用アカウントで利用できる別の確認方法や、App Reviewが単独で完了できるテスト経路を検討し、具体的な手順をNotesへ書きます。
セキュリティ要件を無効化できない場合は、推測で迂回方法を作らず、App Reviewへ事前に相談してください。App Review Guidelines 2.1では、法的またはsecurity上の理由でデモアカウントを提供できない場合、Appleの事前承認を得たfully-featured demo modeを代替として認めています。
QRコードや外部リソース
ログイン後にQRコード、専用ハードウェア、特定の設定が必要なら、それも審査アクセスの一部です。Appleはfull accessに必要なresourceの例としてlogin credentialsやsample QR codeを挙げています。QRコードを添付するだけでなく、どの画面で読み取り、何が表示されれば成功かをNotesへ記載します。
複数roleと課金機能を見せる
管理者と一般メンバーで画面が異なるアプリは、基本アカウント一つで全体を確認できないことがあります。その場合は追加アカウントをNotesへ分けて記載します。
| 確認対象 | 準備例 |
|---|---|
| 管理者だけの設定 | admin roleの審査用アカウント |
| 招待や承認フロー | 送信側と受信側の二アカウント |
| 有料planの機能 | 審査対象機能が有効なテスト状態 |
| 初回体験 | 未設定アカウントと設定済みアカウント |
| コンテンツ閲覧 | 権利処理済みのサンプルデータ |
In-App Purchaseが審査対象に含まれる場合は、購入項目がcompleteかつ最新で、審査担当者から見えて動作する状態にします。場所が分かりにくい機能や、今回追加した機能はReview Notesで入口から説明します。
すべてを一つの強い管理者アカウントで見せると、一般ユーザーの実際の体験と異なることがあります。審査対象のroleごとに、確認する機能とアカウントを対応付けてください。
Review Notesは再現手順として書く
Notesには、機能の宣伝文ではなく、審査担当者が同じ結果へ到達する手順を書きます。AppleのApp Review Guidelinesは、non-obviousな機能とIn-App Purchaseを詳しく説明し、新機能や変更点を具体的に記載するよう求めています。
次のテンプレートから、該当しない行を削って使えます。
App Review access
Primary account
Username: [demo username]
Password: [demo password]
Role / plan: [role or plan]
Steps to review [feature name]
1. Launch the app and sign in with the account above.
2. Tap [tab or menu].
3. Select [sample item].
4. Tap [action].
Expected result: [what should appear or happen].
Additional account
Purpose: [feature that requires another role]
Username: [second demo username]
Password: [second demo password]
Special setup
- [sample QR code or setting]
- [permission or device requirement]
- [location of the in-app purchase]
The backend services and sample data will remain available during review.
Please review the appのような一般的な説明だけでは、非自明な機能の入口が分かりません。画面名、操作、期待結果まで書き、buildで実際に表示される名称と一致させます。
backendと外部サービスを審査中も稼働させる
Appleは提出前の確認事項として、backend serviceを稼働させ、審査中にアクセス可能にすることを挙げています。アプリ本体だけでなく、ログイン、API、画像配信、メール、決済のtest environmentなど、審査手順に含まれる依存先を確認します。
- 審査用アカウントでproduction buildへログインできる
- APIのallowlistがAppleの接続元を拒否しない
- メンテナンスや自動停止の予定がない
- サンプルデータが定期処理で消えない
- 外部サービスのtest credentialが有効である
- 審査対象のURLをログアウト状態でも必要に応じて開ける
App versionを含むsubmissionは、そのversionのApp Review Informationと一緒に審査されます。Appleのsubmission概要によると、app versionを含まないitemを提出する場合は、指定platformの最新承認versionにあるApp Review Informationが参照されることがあります。以前のNotesを放置せず、今回の審査対象と一致しているか確認します。
提出前に新規端末のつもりで通す
デモアカウントを作成した本人の端末では、既存sessionや保存済み設定によって問題を見逃します。提出buildを新規インストールした状態で、Notesだけを見て次を通します。
- usernameとpasswordをコピーしてログインする
- 初回同意、権限、プロフィール設定を完了する
- Notesに書いた順番で主要機能へ移動する
- role、plan、sample dataが期待どおり表示される
- 追加アカウントやQRコードを使うフローを完了する
- logout後にもう一度ログインできる
この確認は、開発に参加していない人へNotesだけを渡して行うと、暗黙の前提を見つけやすくなります。AppleのApp Review案内でも、必要なaccount informationやspecial instructionsがないと審査が遅れたり、通過しなかったりする可能性が示されています。
公開Support URLとは分けて管理する
審査用username、password、追加アカウントはApp Store ConnectのApp Review Informationへ入力します。IndieFormの公開フォームやSupport URLへ認証情報を書かないでください。
IndieFormが担当するのは、App Storeを見た一般ユーザーが問い合わせできる公開導線です。審査用アクセスとは別に、Support URLが対象アプリを明示し、ログアウト状態で開け、問い合わせを送れることを確認します。準備方法はApp StoreのサポートURLを用意する方法で確認できます。
デモアカウントの準備は、資格情報を埋めて終わりではありません。審査担当者が追加連絡を待たずにログインし、対象機能へ進み、期待結果を確認できるところまでを一つの提出物として整えます。