TestFlightで家族や友人に配布し、いくつかフィードバックをもらって修正も終えたので、いよいよApp Storeへの本申請に進みました。「ここまで来たら公開までもう一息」と思っていたのですが、結果はリジェクト（審査却下）。実際にどんな指摘を受けて、どう対応したのかを記録しておきます。
App Store申請の流れ自体は難しくなかった
TestFlightの経験があったおかげで、App Store Connectでの本申請の操作自体はスムーズでした。
- ビルドの選択（TestFlightで使っていたものをそのまま指定）
- スクリーンショットの登録（iPhone用のサイズごとに用意する必要があった）
- アプリの説明文、キーワード、プライバシーポリシーのURLなどを入力
- 年齢制限やカテゴリの設定
一通り入力を終え、「審査へ提出」ボタンを押した瞬間は、ちょっと感慨深いものがありました。
数日後、リジェクトの連絡が届いた
提出から数日後、App Store Connectに通知が届きました。ステータスが「却下」になっており、詳細を見ると「Guideline 2.1 – Performance」という項目で引っかかっていました。
指摘内容を要約すると、次のようなものでした。
- 審査担当者が実機でアプリを操作した際、特定の画面で正常に動作しなかった
- 具体的には「記録を削除する」操作をした直後に、アプリが強制終了してしまった
自分の手元の実機やシミュレータでは再現しなかった不具合だったため、最初は「なぜ？」と戸惑いました。
原因はテストデータとの差だった
改めて調べてみると、原因は自分の手元のテスト環境と、審査担当者側の操作パターンの違いにありました。
自分でテストするときは、いつも数件〜数十件のダミーデータが入った状態で操作していました。しかし審査担当者は、記録が1件もない「まっさらな状態」から操作していたようです。
SwiftUIのリスト画面を実装したときに書いた削除処理のコードで、「削除後に配列が空になるケース」を想定できておらず、空配列に対して無効なインデックスへアクセスしようとしてクラッシュしていました。
普段、自分でテストするときにデータを空にした状態で試すことは、正直ほとんどありませんでした。この経験から、「何もない状態」「1件だけの状態」「たくさんある状態」の3パターンは必ず自分でも確認するべきだ、と痛感しました。
対応した内容
具体的には、削除処理の中で配列が空になった場合の分岐を追加し、空の場合は「まだ記録がありません」という案内文を表示するように修正しました。
修正後は、意図的に全データを削除した状態からもう一度操作を試し、クラッシュしないことを確認してから再申請しました。
再申請から承認までの日数
再申請後、承認までにかかった日数は当初の審査よりも短く済みました。同じ指摘を受けないよう、リジェクトの詳細に書かれていた内容にピンポイントで返信欄（App Review内のメッセージ機能）で「どう修正したか」を一言添えたのも、スムーズに進んだ理由の一つかもしれません。
まとめ
- App Store審査は、Guideline番号付きで具体的な指摘が届く。まずは指摘内容を正確に読むことが第一歩
- 審査担当者は「まっさらな状態（データが0件）」から操作することが多い。自分のテストでも空の状態を必ず確認するべき
- リジェクトされても、原因を特定して再申請すれば通常はそれほど時間をかけずに再審査してもらえる
- リジェクトは「失敗」というより「実機テストでは気づけなかった不具合を教えてもらえた」というくらいの気持ちで受け止めるのがちょうどいいと感じた
一度落ちると心が折れそうになりますが、実際にやってみると「原因を特定して直せば通る」ことがほとんどでした。同じようにリジェクトを経験して不安になっている方の参考になれば幸いです。次は、通知機能（ローカル通知）を実装してつまずいた話をまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント