App Store の審査時間とリジェクト理由 — 個人開発で実際に食らった3つと、その直し方

個人でiOSアプリを出していると、コードを書き終えてからが本番だと痛感します。App Store の審査です。私はこれまでに複数のアプリをリリースしてきましたが、一発で通ることもあれば、何度か往復することもありました。

この記事では、審査にどれくらい時間がかかるのかという実感と、実際にリジェクトされた3つの理由、そしてそれぞれをどう直したかをまとめます。これから初めて申請する方が、同じところでつまずかずに済めば嬉しいです。

審査にかかる時間の実感

まず時間の話から。体感では、提出から1日前後で結果が返ってくることがほとんどです。朝出して夜に通知が来ることもあれば、丸一日以上「審査待ち（Waiting for Review）」のまま動かないこともあります。

気をつけたいのは、待ち時間が読めないことです。年末年始やWWDC前後など、申請が集中する時期は明らかに長くなります。「この日にリリースしたい」という予定があるなら、最低でも1週間の余裕を見て提出するのが安全です。リジェクトされて往復する可能性も込みで考えると、それくらいは欲しいところです。

そして地味に効くのが、リジェクト後の再提出は比較的早く結果が返ってくるという点です。一度審査担当者の手元に載った案件は、修正版も続けて見てもらえる感覚があります。だから「リジェクト＝振り出しに戻る」と落ち込む必要はありません。

実際に食らったリジェクト3つ

ここからが本題です。私が実際に受けたのは、次の3種類でした。どれもiOS個人開発では定番のもので、裏を返せば事前に潰せるものばかりです。

1. Guideline 2.1 — 情報不足・動作不備

もっともよく見るのがこれです。名前は「App Completeness（アプリの完全性）」で、要するに審査担当者がアプリの機能をひととおり確認できなかったという指摘です。

よくあるパターンはこの3つです。

• ログインが必要なのに、確認用のデモアカウントを渡していない
• 特定の操作でクラッシュする、または画面が真っ白になる
• 実装途中の機能が画面に残っている（「準備中」のボタンなど）

対処はシンプルで、App Store Connect の「App Review Information」欄を丁寧に埋めることです。ログインが要るならテスト用のIDとパスワードを必ず書く。特殊な操作で使う機能があるなら、再現手順を日本語でも英語でも構わないので具体的に書く。「サンプルデータを入れた状態で確認してほしい」といった補足も、Notes 欄に書いておくと親切です。

審査担当者はあなたのアプリの仕様を知りません。初見の人が5分で全機能に触れるかを基準に、案内を用意するのがコツです。

2. Guideline 5.1.1 — プライバシー、データの取り扱い

次に多かったのがプライバシー関連です。5.1.1 は「Data Collection and Storage」で、アプリが集めるデータの説明が実態と合っていないときに指摘されます。

つまずきやすいのはこのあたりです。

• プライバシーポリシーのURLが未設定、またはリンク切れ
• App Store Connect のプライバシー質問票（App Privacy）の申告内容と、実際の実装が食い違っている
• 機能に必要のない情報まで、登録時に必須項目として求めている

私が特に気をつけるようになったのは、「端末内に保存しているだけ」もきちんと申告・明記することです。外部サーバーに送っていないなら、それをプライバシーポリシーにも書いておく。むしろ個人開発のアプリでは「データは端末とあなたのiCloudにだけ保存されます」と言い切れることが強みになるので、隠さず前面に出したほうが審査もユーザーへの説明もスムーズです。

3. Guideline 3.1.1 — アプリ内課金（IAP）

課金を入れると一気に難易度が上がります。3.1.1 は「In-App Purchase」で、課金まわりの実装や表示に不備があるときの指摘です。

個人開発でよく踏むのは次のあたりです。

• 購入の復元（Restore Purchases）ボタンがない。買い切りProを実装したときの定番の見落としです
• 課金の対象や条件の説明が画面上で不足している
• サブスクリプションの場合、期間・金額・自動更新の扱いといった必須の記載が足りない

対策としては、課金画面に「何が得られるか」「いくらか」「復元はここから」を一画面で収めること。それから、テスト時に Sandbox アカウントで購入と復元の両方を必ず通すことです。復元は自分では使わない機能なので、実装したつもりで動いていないことがあります。

提出前チェックリスト

私が毎回確認している項目をまとめます。これを埋めておくと、少なくとも上の3種類は避けられます。

• デモアカウント（ID／パスワード）を App Review Information に記入した
• 特殊な操作が必要な機能は、再現手順を Notes に書いた
• 全画面を一度ずつ触って、クラッシュと未完成の表示がないか確認した
• プライバシーポリシーのURLが生きていて、内容が実装と一致している
• App Privacy の申告内容を、実装を見ながら1項目ずつ確認した
• 課金がある場合、購入と復元を Sandbox で両方通した
• 課金画面に、内容・価格・復元導線がそろっている
• スクリーンショットが最新のUIと一致している

リジェクトされたときの心構え

最後に気持ちの話を少しだけ。リジェクトの通知は最初こそ心臓に悪いのですが、届く文面はたいてい具体的です。ガイドライン番号が書かれ、多くの場合はスクリーンショットや再現手順まで添えられています。つまり、直すべき場所が明示された無料のレビューをもらっているのと同じです。

そして、こちらの認識と食い違っていると感じたら、Resolution Center で返信して構いません。「この機能は端末内で完結しており、外部送信はしていません」といった説明で解決することもあります。黙って作り直す前に、まず対話するのが近道です。

個人開発は、作るところまでは自分のペースで進められますが、審査だけは相手のある工程です。余裕を持ったスケジュールと、初見の人への丁寧な案内。この2つがあれば、審査は思ったほど怖くありません。