「登録しないと地図が見られない」で審査落ち — ビルドを1本も焼かずに再提出した — 制作日誌 #15

複数の目的地を回る順番を決める経路アプリを、はじめて審査に出した。結果は却下だった。

理由はガイドラインの一項目で、要約すると**「アカウントが無くても成立する機能に、登録を強制してはいけない」**というものだ。私のアプリは、起動するとログイン画面が出て、そこを抜けないと地図も経路も見られなかった。

押し返すか、直すか

却下されたとき、選択肢は2つある。ガイドラインの解釈を主張して押し返すか、指摘どおり直すか。

この項目には例外もある。「サービスの中核がアカウント前提である場合」などだ。しかし地図と経路は、アカウント無しでも成立する。主張しても通りにくいうえに、審査側が示している解決策そのものが「ゲスト利用を用意すること」だった。

押し返せば数日から1週間を失って、しかも覆りにくい。直したほうが速いと判断した。

実装：匿名のログインを使う

ここで一番効いた判断を書いておく。ゲスト利用を「ログインしていない状態」として作らず、匿名のログインとして作った。

多くの認証サービスには、アカウント情報を一切持たないまま正規の利用者として扱う仕組みがある。これを使うと、

• ゲストも本物の認証情報を持つ
• したがってアプリ側の認証の関門も、サーバー側の本人確認もそのまま通る
• サーバーの認可を作り直さなくていい

もし「未ログインでも通す例外」をサーバーに足していたら、認可の穴を自分で開けることになっていた。ここは設計として、かなり救われた部分だった。

開放したのは経路検索だけ。保存・表示名の変更・アカウント削除・端末間の同期・有料プランは、引き続きログインを求める。これらは指摘の対象外なので、広げすぎない。

踏んだ罠

罠1：「ログインする」ボタンが全部反応しなかった。 ゲストも利用者IDを持っているので、ログイン画面へ移動しようとした瞬間に「もうログイン済みです」と判定されて引き戻されていた。正解は画面遷移ではなく、匿名の状態を一度畳むことだった。ゲストを「ログイン済みの一種」として作った副作用で、ここは想定していなかった。

罠2：ゲストに広告が1本も出なかった。 広告の表示は「無料プランの人」に限定していた。ゲストはプランが未確定の扱いだったので、条件に当てはまらず1本も出ない。ゲストを明示的に無料プラン扱いにして解決した。

罠3：初めて使う人が、本物の経路を1本も見られなかった。 無料の人は「広告を見て貯めた残高」で経路を引く作りにしていた。新規は残高ゼロなので、初回は必ず失敗する。審査員も当然この状態を見る。実際に叩くと、残高不足のエラーが返っていた。ここは無料の枠を最初から配る形に変えた。

3つとも、ゲストという新しい状態を足したことで、既存の条件分岐がすり抜けたという同じ構造をしている。状態を1つ増やすと、その状態を見ていない分岐が全部あらわになる。

原価の歯止め

経路検索は1回あたり外部サービスに5〜15円かかる。誰でも無制限に使えると原価が青天井になるので、歯止めを二重に置いた。

数え方は「検索回数」ではなく呼び出し本数にした。1回の検索が複数の窓口を叩くためだ。ただし入力の補完だけは、打鍵ごとに飛ぶので数から除外した。

回線の情報は生のまま保存せず、日付と混ぜて元に戻せない形にしてある。

焼かずに再提出できた理由

一番大きかったのはここだ。修正はすべてアプリの中身（JS）側で、ネイティブの部分には一切触れなかった。

このアプリは、審査に出したファイルを焼き直さなくても、起動時に最新の中身を取りに行く仕組みを持っている。起動時に最大4秒だけ更新を待つ設定にしてあったので、初回起動から直った画面が出ることを実機で確認したうえで、同じファイルをそのまま再提出した。

• 有料ビルド 0回
• 待ち時間 0
• 審査に出すファイルは前回とまったく同じもの

審査メモには、未ログインで何ができるか、どこでログインを求めるか、回数制限は登録の誘導ではなく原価が理由であることを英語で明記した。これで通り、その後そのまま公開された。

学んだこと

• 却下は「主張するか直すか」の二択。 相手が解決策を提示している場合、直すほうがほぼ速い
• 新しい状態を足したら、既存の分岐を総点検する。 「ログイン済み／未ログイン」の2値だった世界に3つめを足すと、条件の書き方が全部あぶり出される
• ネイティブに触らない修正は、焼かずに出せる。 どこまでが中身の差し替えで直せるかを知っておくと、審査対応の速度がまったく変わる
• 審査員は「初めての人」そのもの。 初回起動で何も見えない状態は、そのまま却下理由になる