アプリ公開前チェックリスト。全部通したのに問題が出た六つ

最初に見るのは、うまくいく道ではありません。外れた道です。うまくいく道は作っている間に何度も通っているので、そこで落ちることはまずありません。

落ちるのは、データが空のとき、通信が切れたとき、権限を断られたとき、途中でアプリを閉じたとき。どれも作っているときには通らない道です。

外れた道を見るときの基準は一つです。画面に次の行動が出ているか。止まっているのか、待っているのか、失敗したのかが分からない状態がいちばん困ります。読み込み中の表示を出しておくだけで、失敗の半分は問い合わせにならなくなりました。

下の一覧の順番にも意味があります。初回起動を最初に置いているのは、自分がいちばん通らない道だからです。作っている間は途中の画面から始めるので、最初の画面を何週間も見ていないことがあります。

• 初回起動から中心の機能が終わるところまで、一度通す。
• データが空のとき、次に何をすればよいか画面に出ている。
• 通信が失敗したとき、やり直せる。黙って止まらない。
• 権限を断られたとき、断ったままでも使える範囲が残る。
• 許可を求める前に、何に使うかを説明している。
• 小さい画面、大きい文字、暗い配色で崩れない。

ここは、書いた文書と実際の動きがずれる場所です。文書は早い時期に書いて、実装はあとから変わります。ずれても画面には出ません。

私は一度、公開の手前で法務の文書と実装を一条ずつ照らしました。守れていない約束が見つかりました。悪意ではなく、書いたときの想定と、作り終えた実装が違っていただけです。照らす作業をしなければ、そのまま出していました。

照らす作業は、文書を読みながら実装を開くのではなく、文書の側を一条ずつ進めるほうが漏れませんでした。実装から見ると、書いてあるはずの条文を探しにいく形になり、探し当てられなかったものが消えます。

サポートの窓口については、実際に自分で送ってみるところまでを確認に含めています。フォームが動いていても、届いた先を見ていなければ確かめたことになりません。ストアには連絡先のURLを登録する欄があり、審査でも見られます。

• 本番の商品が正しく取得できる。テスト用の値が残っていない。
• 購入の復元が動く。解約したあとの状態を決めてある。
• プライバシーポリシーと利用規約が、公開されたURLで開ける。
• 集めているデータと、ストアへの申告が一致している。
• 入れた部品が既定で外へ送るものも、申告に含めた。
• 問い合わせ先が実際に届く。サポートのページが開ける。

提出用のビルドは、手元で動いていたものとは別物になります。設定が本番へ切り替わり、署名が付き、最適化がかかります。手元で通った確認は、提出物の確認ではありません。

この段階で急ぐと、ほぼ確実に何かが残ります。私が残したのは、テスト用のIDと、転送を挟んだままのURLでした。どちらも手元では正しく動いていたので、見落としたことに気づく手がかりがありませんでした。

ストアの表示で気をつけているのは、画像の中の文字です。規格どおりのサイズで書き出しても、一覧に並んだときは縮みます。端末の画面で小さく並べたところを見て、読めない文字が入っていないかを確かめます。説明文も同じで、最初の数行しか展開せずに読まれる前提で先頭を書きます。

1. 01　提出するビルドそのものを動かす

   本番の設定、版番号、署名。そしてテスト用のIDや仮のURLが残っていないか。手元の設定で動かしたものは、確認したことになりません。

2. 02　ストアの表示を実物の画面で見る

   名前、説明文、対応言語、画像、リンク、料金の表示。プレビューではなく、実際に表示される場所で見ます。画像は規格が合っていても、文字が切れていることがあります。

3. 03　外から開けるURLを全部叩く

   サポート、プライバシーポリシー、利用規約。手元で開けることと、外から開けることは別です。転送の設定を挟んでいる場合はとくに。

4. 04　公開後に何を確認するかを先に決める

   インストール、購入、リンク、分析。公開してから考えると、確認の順番を決めるうちに時間が経ちます。

一覧で確認するやり方には、はっきりした弱点があります。提出が近いときに飛ばされることです。私は飛ばしました。急いでいたからではなく、前回通っているので通ると思ったからです。

そこで、項目を二つに分けました。機械が判定できるものは検査へ移し、人は判断が必要なものだけ見る。本番のURLになっているか、版番号が上がっているか、テスト用の値が残っていないか。これらは人が見る必要がありません。

分けてみて分かったのは、飛ばしていた項目のほとんどが機械で判定できる側だったことです。判断が要る項目は、飛ばしていませんでした。文言の自然さやスクリーンショットの見え方は、気になるので自然と見ます。

振り分けたあとに残る問題もあります。検査が間違っていることがあるという問題です。私は一度、利用者が自分で決めたかどうかを調べるつもりの判定が、部品側が登録した既定値まで拾う書き方になっていて、切るべき場面で切らない結果を返していました。⚠️ 確認する側のコードも、確認の対象です。

実際に六つの問題を拾って一つのコマンドにまとめた経緯はテストは全部通った。それでもアプリの公開後に6つ問題が出たに記録しました。関連する落とし穴として、本体が404を返すのに画像だけ200を返していた件もあります。画面を開いても何も起きないので、目では気づけません。

全体の流れは個人でアプリを作るには？企画から公開までの七段階と止まる場所にまとめています。

アプリの公開前に確認すべきことは何ですか？

うまくいく道ではなく、外れた道です。データが空のとき、通信が切れたとき、権限を断られたとき。うまくいく道は作っている間に何度も通っているので、そこで落ちることはまずありません。

チェックリストを作ったのに、結局飛ばしてしまいます。

私も飛ばしました。対策は意識ではなく振り分けでした。機械が判定できる項目を検査へ移すと、残るのは判断が要るものだけになります。文言や画像の見え方は、気になるので自然と見ます。

他の人が公開しているチェックリストを使ってもいいですか？

出発点としては使えますが、そのまま写さないほうがよいです。自分に当てはまらない項目が残ります。会員情報を持たないアプリに「アカウント削除の導線」を入れると、削除する対象がないまま項目が残り続けます。

テストが全部通れば公開して大丈夫ですか？

別のことです。テストは書いた範囲しか見ません。私は全部通った状態で出して、公開後に六つの問題を拾いました。本番の設定に切り替わって初めて壊れるものが、テストの外にあります。

プライバシーの申告で見落としやすいのはどこですか？

自分が書いた行の外側です。追加した部品が既定で何を送るかは、部品側の申告を読むしかありません。地図の部品が既定で位置情報を分析目的へ送っていたことがありました。こちらのコードには一行も書いていません。

提出用のビルドは、手元のビルドと何が違いますか？

設定が本番へ切り替わり、署名が付き、最適化がかかります。手元の設定で動かしたものは、確認したことになりません。提出するビルドそのものを動かすところまでを確認に含めています。

公開したあとは何を見ればいいですか？

見る項目を公開する前に決めておくのが要点です。公開してから考えると、順番を決めるうちに時間が経ちます。私はインストール、購入、外から開けるURL、そして検索エンジンの管理画面を見ています。

一人で開発していると、自分のチェックを自分で通してしまいます。

判定を自分の意思から外すのが唯一効きました。人が読む一覧は「通ったつもり」になれますが、ビルドを落とす検査は通せません。意識を強く持つ方向で解決しようとしたときは、二度目も飛ばしました。

この記事では、審査に落ちない書き方を書いていません。私は一度、ストアの規約でアプリのコンセプトごと却下されました。そのときに分かったのは、事前のチェックリストで防げる種類ではなかったということです。落ちたのは実装の不備ではなく、アプリが何であるかの説明でした。

もう一つ書いていないのは、審査にかかる期間です。何度か出しただけなので、平均を語れる回数ではありません。数えられていないものを目安として書かないようにしています。

最後に、この一覧そのものについて。項目を増やすほど飛ばされやすくなります。私は増やす方向ではなく、判定できるものを外へ出す方向で減らしました。人が見る項目が少ないほうが、一つずつ丁寧に見られます。

書いていないことを一つ足します。この記事の項目は、位置情報と課金を使うアプリを前提にしています。オフラインで完結するアプリなら、権限と通信の項目はほとんど要りません。写す前に、自分のアプリに当てはまる行だけを残してください。