App Store審査に通ったのに壊れていた事故10件。提出前と公開当日のチェックリスト

審査で落ちるのは、まだ良いほうです。落ちれば理由のメールが届き、直せば済みます。

本当に怖いのは、審査に通ったのに壊れているケースです。間違った値を自信満々に表示しているアプリ。購入画面が加入済みの人に「もっと使えます」と言うアプリ。審査の最中にサーバーが止まっていて、ログインが全滅していたアプリ。どれも私が実際に踏みました。

この記事は、実際に起きた事故10件を直し方つきでまとめたものです。一般論ではなく実例だけを並べます。この手順で通る保証はできません。無料部で3件、有料部で残り7件と実物を渡します。

事故1: 取れた値が「別の物」の値だった(本番配信中に発覚)

外部のサービスから値を取ってきて、画面に「答え」として出すアプリで起きました。

識別番号で対象が引けないとき、名前で検索し直す「カバー率(値を出せる品の割合)を上げる工夫」を入れていました。ところが、検索で返ってきた候補が本当に同じ物かを確かめる手段が無かったのです。その結果、本番配信中に、ある品の値として、まったく別ジャンルの品の値を表示していました。それも1件ではなく、複数です。

原因は、使っていた検索の仕組みが、共通の識別番号を返さなかったことです。返ってくるのは相手側の管理番号だけで、同じ物かどうかを突き合わせられません。

直し方は1つです。照合できない経路は、カバー率が上がっても採用しない。

外部のデータを「正解」として画面に出すアプリは、これで全部です。便利さより、間違った値を出さないことを優先します。数字を見せるアプリで間違った数字を出すと、取り返しがつきません。

事故2: 「通信エラー」を「0件」と読んだ

同じアプリの別の穴です。

値を取る先が2つあり、片方が「回数が多すぎる」(HTTP 429)と返してきたとき、私のコードはそれを「該当なし(0件)」として扱っていました。すると、片方の取得先のデータだけで答えを計算し、それを確定値として出してしまいます。実際に、並列で6本まとめて問い合わせたところ、全件が429になりました。

しかも、データを取る鍵がアプリ単位(全ユーザー共有)だと、利用者が増えるほど踏みやすくなります。

直し方の要点は3つです。

• 429・サーバーエラー・通信断は、少し待ってやり直す(350ミリ秒、900ミリ秒程度)

• それでも取れなかった取得先は、結果に「取れなかった」と残し、画面に「暫定」と出して再試行ボタンを置く

• 「0件だった」と「取得に失敗した」を、データの型の段階で別物にしておく

特に3つ目が盲点です。失敗を握りつぶす書き方だと、この2つは同じ形になり、片方だけ落ちたケースを見逃します。

事故3: 加入済みの人に、未加入向けの購入画面が出た

サブスクのアプリで起きました。

設定画面には「利用中」と出ているのに、購入画面を開くと「もっと使えます」と「続ける」ボタンが出る。画面が契約の状態を知らないまま、全員に同じ画面を使い回していたのです。

ここで注意したいのは、「加入済みなのに購入できてしまう」こと自体は問題ではない点です。同じサブスクのグループの中の別プランは、購入できるのが正しい動きです(プランの変更として扱われ、二重には課金されません)。問題は、画面の言葉が状態に合っていないことでした。

直し方は、契約の状態を購入画面に渡して、見出し・ボタンの文言・注意書きを分けることです。あわせて、プラン変更がいつ反映されるか(上位への変更は即時、下位への変更は次の更新日から)を、画面で説明します。

3件とも審査の指針違反ではなく、審査官が指摘する前に自分で見つけるしかない穴でした。

有料部で渡す物(500円)

残り7件の事故と、実行にそのまま使える物です。

• 事故4〜10の中身と直し方(審査中の無料サーバー停止、取り下げと再提出の落とし穴、キーがあるのに課金が死ぬ配線、検査が空振りする理由、公開当日の放置5か所、レビュー依頼の出し方、公開後の更新)

• 提出前チェックリスト(14項目、チェックボックス付き)

• 公開当日チェックリスト(8項目、チェックボックス付き)

• 課金が生きているかを実際のファイルで確認するコマンド(事故6)

• 検査が壊れていないかを先に確かめてから、課金のキー・商品IDを数えるスクリプト(事故6・7をまとめた物。引っかかったら止まる)

• 公開中のアプリを更新する手順(5ステップ)

• 困ったときの判断フロー

チェックリストは、事故のたびに足していった物です。