新バージョンなしで変更できること: Apple vs Google
ストアの掲載情報に手を加える前に、答えておく価値のある問いが1つあります。この編集は完全な申請の手間がかかるのか、それとも静かに公開できるのか。判断を誤ると、想定していなかった審査待ちに巻き込まれるか、まだ承認待ちなのに変更が反映済みだと思い込むことになります。両ストアはこの問いに正反対の答えを出しており、その違いこそが、両方の掲載情報を同期させ続ける作業が面倒な理由です。
ここからはフィールドごとの正直な内容です。まずマトリクスから始め、その後にそれぞれのストアのルールの理由を説明することで、この表に書かれていないケースも予測できるようにします。
マトリクス
よくある掲載フィールドと、変更したときに各ストアが求めることをまとめました。「新バージョン/リリース」は、そのストアが編集を送信必須の申請の一部として扱うことを意味し、「審査あり」は公開前に人またはシステムによるチェックが行われることを意味します。
| アプリアイコン | メインアイコンはバイナリに含まれるため、変更には新しいビルドが必要です。そのビルドとともに審査されます。 | ストアアイコンは掲載情報アセットです。新しいリリースは不要。審査あり。 |
2つのことが際立ちます。Appleはほぼすべてをバージョンレコードに集約します。Googleは掲載情報全体を単独で動かせます。どちらのストアも重要なアセットの審査は省略しません——「審査あり」という言葉がほぼすべてのセルに出てきます。つまり本当の問いは「審査されるかどうか」ではなく「この編集が申請を伴うかどうか」なのです。
Apple: 新バージョンレコードは新ビルドとは違う
これが人を混乱させるポイントです。App Storeでは、スクリーンショット・名前・サブタイトル・キーワードフィールド・説明文を編集すると、掲載情報の新バージョンが作成されます。これだけ聞くとXcodeに戻らなければいけないように思えます。実際は違います。Appleは現在のメタデータを自動的に新バージョンに引き継ぐため、メタデータのみの変更に新しいアプリコードは不要です(App Store Connectはバージョンにビルドを求めますが、アプリの動作は何も変えません)。編集対象のフィールドを編集し、送信すれば、1回の審査サイクルですべてがカバーされます。
つまり「新しいコードは不要だが審査はある」というのが正確な捉え方です。コンパイル作業も新機能もありませんが、編集はApp Reviewに入り、公開されるまで順番待ちになります。変更はまとめて行いましょう。1つのバージョンレコードには、新しいスクリーンショット・書き直した説明文・新しいサブタイトル・更新したキーワードを同時に含められるため、1つずつ別々の審査サイクルを使う理由はありません。
アプリアイコンは、ビルドが必要になる例外です。メインアイコンはバイナリに焼き込まれてそこから描画されるため、本当に新しいアイコンにするには新しいビルドが必要です。代替アイコンも同様で、使用するにはアプリにバンドルされている必要があるため、追加は掲載情報の編集ではなくビルドになります。
Appleの2つの抜け道
プロモーションテキスト。バージョンも審査も不要な唯一のフィールドです。170文字で、説明文の上に表示され、いつでも更新できます——セールや発売のお知らせ、時期限定のコピーに便利です。検索順位に影響せず、どんな申請の一部にもなりません。だからこそストア上で最も速く変更できるフィールドなのです。今日中に反映したいことがあれば、このフィールドが対応できます。
Product Page Optimization(PPO)。PPOでは、スクリーンショット・App Preview・アイコンについて最大3パターンを公開中のプロダクトページに対してテストできます——新しいアプリバージョンを配布せずにです。これがAppleにおいて通常の申請なしにビジュアルを変更できる最も近い方法です。ただし2つ注意点があります。テストパターンのメタデータはテスト開始前に承認される必要があり(つまり審査あり、即時ではない)、テストしたいアイコンは現在のアプリバイナリにすでに含まれている必要があります。PPOは訪問者が見るものを変えますが、審査を省略するわけではありません。
Google Play: リリースなしで掲載情報を公開する
Playは逆の仕組みです。タイトル・簡単な説明・詳しい説明・スクリーンショット・フィーチャーグラフィック・アイコン・プロモーション動画など、ストア掲載情報は新しいアプリのリリースを伴わずに単独で編集・公開できます。編集すると、Publishing overviewの「送信待ちの変更」に表示されます。送信するとGoogleの審査を通過し、どのビルドとも独立して公開されます。
過大評価しないために正確にしておきたい点がいくつかあります。変更は依然として審査されます——Playの審査は掲載情報の編集にも及び、アプリ名やアイコンなどの要素はチェックされるため、無審査で即座に切り替わるわけではありません。また掲載情報はリリース済みのアプリから切り離されては存在できません。Playでは、公開できる掲載情報が存在するために、アプリの事前リリースが必要です。一度もリリースされていないものに対して単独のストアページを公開することはできません。もう1つ知っておくべき要素がManaged publishingです——これがオンの場合、承認済みの変更は自分が実際に公開操作をするまで待機します。これは遅延ではなく、想定していれば便利な機能です。
非対称性と、それが時間を奪う理由
2つのモデルを並べると、その違いは明確です。Appleはほぼすべてのテキストと画像の編集をバージョンレコードと審査に結びつけており、プロモーションテキストとPPOだけがその例外です。Googleは掲載情報をリリースから完全に切り離し、編集を審査した上で、アプリがすでに存在する限り独自のスケジュールで公開します。
この非対称性は、両方のストアを運用しているとひそかにコストがかかります。同じスクリーンショット刷新でも、一方のストアではバージョンレコードの申請になり、もう一方では単独の掲載情報の更新になります。説明文の書き直しも、Appleでは審査対象のバージョンになり、Googleでは審査対象の掲載情報の変更になります。内容は同じでも仕組みが違うため、Playでは1アクションで済む変更がApp Storeでは別のアクションになります——そして片方だけを反映して他方を忘れたり、まだ審査中なのにAppleでも反映済みだと思い込んだりしがちです。
Mokbiが役立つところ
このストア間の非対称性こそ、公開ツールが価値を発揮する理由そのものです。Mokbiはスクリーンショットエディタとして始まりましたが、掲載情報はテキストと画像が一体のものです——だからスクリーンショットセットをデザインすると同時に、両ストア向けの掲載情報コピーも1か所で作成します。App Storeの名前・サブタイトル・キーワードフィールド・説明文、Playのタイトル・簡単な説明・詳しい説明。1つの文章ブロックを2回貼り付けるのではなく、各ストアが実際にインデックスするフィールドを、そのストア向けの形で得られます。
そして掲載情報全体——スクリーンショットとコピー——を50言語に翻訳するので、1回行った変更が、他の市場ではすでにローカライズ済みなのに1か所だけ英語のまま取り残されることなく、それぞれの正しいフィールドに反映されます。さらに公開も行います。MokbiはPlay Developer APIを通じて完成した掲載情報をGoogle Playに直接プッシュし、App Store Connectには送信準備済みの状態でステージングします——Apple側では最終的なSubmitと審査は依然として必要で、これはAppleのルールであり、まさにこの記事全体のテーマであるストア間の非対称性そのものです。この最後の審査こそが、この記事で語ってきた時計が動き始める瞬間でもあります。