悩んだ表情の男性が、ノートパソコンとスマートフォンを見ながらApp Store審査の却下について考えているアイキャッチ画像。左側に「ログイン不要アプリが却下された話」「承認までにやったこと」という文字が大きく配置され、背景には海や「404」のモチーフが入っている。

App Store審査で「ログイン不要で誰でも投稿できるアプリ」を提出した際、Guideline 2.1(a) - Information Needed で却下された経験はありませんか？結論から言うと、この却下の本質は「ログインが必要」ということではなく、「審査員が投稿済みコンテンツと保存状態を客観的に確認できる手段がない」ことでした。これに対応するため、実データベースから最新の投稿内容を表示する「審査員専用の閲覧ページ」を用意したことで、無事に承認を得ることができました。

この記事では、Safari拡張アプリ「404の海」の開発において、どのような状態で却下され、技術的にどのような確認ページを用意し、Appleにどう説明したのかを詳しくまとめます。同じような指摘で悩んでいる個人開発者の参考になれば幸いです。

1. 却下されたときの提出状態

最初に「404の海」を提出したときは、以下のような「極めてシンプル」な構成で挑みました。

  • ユーザー登録・ログインなし（匿名性の維持のため）
  • デモアカウント・デモモードなし
  • iPhone/iPad向けSafari Web Extensionとして動作
  • Safariで存在しないページ（404）を開くと拡張機能が動く仕様
  • 匿名の手紙を投稿・受信できる機能がある
  • 受信箱や送信履歴、プロフィール画面は一切なし

アプリとして投稿機能や通報機能はしっかり実装していましたが、審査員が「実際にどんなデータが保存され、どのように表示されるのか」を客観的に確認する導線がアプリ外にも内にもなかったのがこの時の状態です。

2. Appleから届いた指摘内容

結果として、Guideline 2.1(a) - Information Needed によりリジェクトとなりました。Appleからのメッセージを要約すると、以下の通りです。

  • アプリの一部または全部に正常にアクセスできない。
  • 全機能を確認できる方法が必要。
  • 通常はデモアカウントを提供するが、それがない。
  • メッセージなどの機能がある場合は、事前入力済みコンテンツも必要。
  • デモ動画だけでは不十分。

この指摘を読んで痛感したのは、Appleが求めているのは「ユーザー名とパスワード」そのものではなく、「審査担当者がアプリの挙動と投稿済みデータを100%把握できる状態」であるということでした。

3. 最初の提出で足りなかったもの

振り返ってみると、最初の提出では以下の「審査のしづらさ」がありました。

  • 投稿の保存確認： 手紙を海に流しても、自分の画面の履歴に残る仕様ではないため、審査員が「本当に送信されたのか？」を判断しづらかった。
  • コンテンツの質： どんな手紙がやり取りされるのか、実例（事前入力済みコンテンツ）を見せる導線がなかった。
  • 仕様の誤解： 投稿後に一覧に出ないことが「不具合」なのか「仕様」なのか、説明が不足していた。

「404の海」は、匿名の手紙を誰かに届け、将来的に別の誰かの404ページに届くという「ゆるい繋がり」を大切にしています。この特殊な仕様を、審査員が納得できる形で提示する必要がありました。

4. 修正方針：審査員専用ページを用意する

アプリに無理やりログイン機能を追加するのは本末転倒です。そこで、「審査員だけが実データベースの中身を覗ける専用ページ」をWeb上に用意することにしました。

方針としては以下の通りです。

  • 実DBとの連動： ダミーではなく、実際に保存されている「手紙」を表示する。
  • 読み取り専用： 投稿や削除、更新などの操作は一切できない設計にする。
  • セキュアなアクセス： 推測困難なURLにtokenを付与し、tokenが一致しない場合は404を返す。
  • 検索避け： noindex, nofollowヘッダーを付与し、サイトマップにも掲載しない。
  • 時限式： 審査後はtoken変更やフラグOFFで簡単に閉鎖できるようにする。

5. 修正後の状態：投稿データを実DBから確認できるようにした

対応後、アプリ本体の仕様は変えず、App Review Notes（審査員へのメモ）を大幅に強化して再提出しました。

  • 審査員専用URLの提示： token付きの専用URLを記載し、そこで保存済みデータを確認できる旨を説明。
  • 投稿確認の手順： 「Safari拡張から投稿した後、この専用ページを更新すれば、今投稿した内容が保存されていることを確認できます」と明記。
  • 具体的な操作手順： Safari拡張の有効化手順と、テスト用の404確認用URL（実際に404を返すパス）を提示。

これにより、審査員は自分の手元で行った投稿が、即座にサーバー側に正しく届いていることを客観的に確認できるようになりました。

6. 却下時と修正後の違い

対応前後での違いを表にまとめると、以下のようになります。

項目 却下時 修正後
ログイン / デモ垢 なし なし（ログイン不要のまま）
投稿済みデータの確認 確認手段なし 審査員専用ページで確認可能
投稿後の保存確認 不可能 専用ページ更新でリアルタイム確認
審査員への説明 機能説明のみ 具体的なテスト手順とURLを提示

7. Appleへの返信で書いたこと

再提出時の返信メッセージでは、とにかく「迷わせない」ことを意識しました。

実際に伝えたポイント：

  • これはiPhone/iPad向けのSafari拡張であること。
  • ログイン機能はないが、匿名で手紙を投稿できること。
  • 「受信箱」がない仕様なので、投稿後の確認は専用Webページ（URL提示）で行ってほしいこと。
  • 審査用として、あらかじめいくつかのサンプル手紙を投稿済みであること。

8. 再提出前に確認したこと

技術的な不備で再リジェクトされないよう、最後に以下のポイントを徹底チェックしました。

  • 閲覧専用の徹底： 審査用ページにDB書き込み権限がないこと（PDOで PRAGMA query_only = ON を設定）。
  • セキュリティ： 正しいtokenなしでアクセスした際に、しっかり404エラーになること。
  • デザイン： 当初はテーブル形式でしたが、スマホで見ると本文が読みづらかったため、カード型レイアウトに変更して視認性を上げました。
  • インフラ： noindex設定が正しく効いているか、検索結果に出ないようになっているかを確認。

9. 同じ状況の人向けチェックリスト

ログイン不要の投稿・メッセージ型アプリを審査に出す際は、以下の項目を確認してみてください。

  • 審査員が「投稿済みコンテンツ」を一覧で確認できる手段があるか？
  • 審査員が「自分の投稿」が正しく保存されたことを確認できるか？
  • アプリの仕様上「できないこと（履歴画面がない等）」を明確に伝えているか？
  • Safari拡張など特殊なアプリの場合、有効化の手順を1から書いているか？
  • 審査用URLは「閲覧専用」で、かつ推測困難なものになっているか？

10. まとめ

今回の却下は、アプリの機能そのものが壊れていたわけではなく、「審査担当者がアプリを評価するための情報が不足していた」ことが原因でした。ログイン不要であることに安心してしまい、投稿データの確認導線が弱かったのが反省点です。

「404の海」のような匿名投稿アプリでも、審査員にしっかりと中身を見せる準備をすれば、ログイン機能なしで承認を得ることは可能です。もし似たような指摘を受けて困っている方がいたら、ぜひ「審査員のための閲覧窓口」を用意することを検討してみてください。

App Store審査の悩みや感想があれば、ぜひ X の DM で教えてね！