掲載キット: あなたのコードから書かれたストアページ

まず数字で見てみましょう。平均的なストア掲載には次が必要です：

• ストアごとに4〜5種類の異なるピクセルサイズのスクリーンショット
• 8種類以上のサイズでレンダリングされた1つのアイコン
• 連絡先や位置情報に関わるものなら10項目を超えることもある権限リスト
• 審査担当者が初日にアプリを却下するかどうかを左右する、数十の分岐がある1つのプライバシー質問票

これを3つのストア——Play、App Store、拡張機能を配布するならFirefoxのアドオン掲載——分掛け合わせると、すでに完成させたアプリのために、スクリーンショットの切り抜きとフォーム入力で丸3日分の午後を費やすことになります。それだけでも十分うんざりする数字です。

ストア向けのすべてのビルドには自動生成されたリスティングキットが付属し、開発者がアプリに意図した動作と、実際にコンパイルされたバイナリの動作との間にある特定のギャップを埋めるために作られています。

キットの残りの部分は簡単です

• スクリーンショットはモックアップではなく実際に動作しているアプリから生成され、各ストアの仕様に合わせて構成・サイズ調整され、形式に応じてパネルにキャプションが付きます。
• アイコンは各ストアが求めるサイズのフルセットに加え、そのストアが別途要求するプロモーション画像や機能グラフィックにも書き出されます。
• 掲載文——タイトル、簡単な説明、詳細な説明——はアプリが実際に行うことに基づいて書かれます。当たり前に思えるかもしれませんが、形容詞を積み重ねただけのApp Store掲載文をたくさん見てきた人なら、その難しさが分かるはずです。
• 権限の説明理由は各ストアが求める形式で、権限ごとに生成されます。

これらはどれも特別難しいわけではありません。ただ、面倒くさすぎて省略されたり、急いで雑にやられたりするだけです。

厳格さが求められる部分：プライバシー質問票

ここが、善意があっても間違いやすい部分です。アプリを作り、データを収集していないだろうと確信して質問票の「データ収集なし」にチェックを入れ、そのまま進めてしまう。ところが3週間前にクラッシュレポート用のSDKを組み込んだのを忘れていたり、依存関係の更新で分析用の呼び出しがこっそり入り込んでいたりします。すると掲載情報とバイナリの動作が食い違ってしまい、ユーザーへの意図しない虚偽になるか、審査で即座にフラグを立てられるかのどちらかになり、どちらも望ましい結果ではありません。

そのため、このキットはあなたの言葉を鵜呑みにしません。回答する前にアプリの実際のソースコードをスキャンします。「データを収集しない」という主張は、コードにネットワーク通信がなく、分析ツールも組み込まれていない場合にのみ行われます。アプリが実際に外部と通信している場合は、それが好ましくない内容であっても、正確にそう申告します。都合よく見せるよりも、正直な掲載情報のほうが良いという考え方です。そしてこれは偶然ではなく、審査担当者が確認するのと同じ内容をスキャンが確認しているため、審査を通過しやすいバージョンでもあります。

提出するだけでなく、実際に入力まで

ストアがAPIを公開している場合、キットは人の手を介さず掲載情報を直接プッシュします。ストアが独自のコンソールを使うことにこだわる場合は、キットがフォーム入力を自動化し、そのストアが人間の操作を必須としているわずかなクリックだけを残します。

ストアごとの詳細な内訳はプロンプトからアプリストアへをご覧ください。