· 公開 · 5分で読めます

新しいバージョンを出さずにApp Storeのスクリーンショットを変更する方法

新しいバージョンを出さずにApp Storeのスクリーンショットを変更する方法
TL;DR. スクリーンショットはバージョンのメタデータの一部なので、公開中のリスティングの編集項目はロックされています。これを変更するルートは2つあります。デフォルトのルートでは新しいバージョンレコードを作成し、ビルドを紐づけ(コード変更は不要)、App Reviewを通します。より速いルートはProduct Page Optimizationテストで、新バージョンも新ビルドも不要でスクリーンショットとプレビュー動画を反映できますが、それでもクリエイティブはレビューを通過する必要があります。プロモーションテキストだけは、バージョンもレビューも一切なく、いつでも変更できます。

今すぐ公開中のアプリのスクリーンショットを差し替えたいと思ってApp Store Connectを開くと、現行バージョンのスクリーンショット項目は読み取り専用になっています。これはバグではなく、Appleの仕様どおりの挙動です。スクリーンショットはバージョンのメタデータの一部であり、バージョンが承認・リリースされると、そのメタデータは固定されます。ここでは、実際に購入検討者に見える内容を変更できるルートと、それぞれがビルドのアップロードとレビュー時間の面でどれくらいのコストになるかを紹介します。

なぜ項目がロックされているのか

App Store Connectはスクリーンショットを特定のアプリバージョンに紐づけて保存します。アプリが公開中の場合、そのバージョンはリリース済みの状態にあり、スクリーンショット・説明文・キーワードはすべてロックされます。それらを編集するには、「提出準備中(Prepare for Submission)」状態にある別の編集可能なバージョンレコードで作業する必要があります。新しいバージョンが承認・リリースされて上書きされるまで、公開中のリスティングは古いスクリーンショットを表示し続けます。

Apple自身のドキュメントもこの点をはっきり述べています。アプリが提出・承認された後にスクリーンショットを更新するには、新しいバージョンを作成する必要がある、と。つまり問われるべきは「公開中のバージョンを編集できるか」(できません)ではなく、「どの方法が最も小さく、最速の変更を生むか」です。

ルート1: 新しいバージョンレコード(デフォルト)

多くの開発者がすでに知っている方法です。App Store Connectで新しいバージョンを作成し、編集可能な「提出準備中」レコードを開いてスクリーンショットを差し替え、レビューに提出します。重要な点として、新機能やバグ修正を出荷する必要はありませんが、バージョンにビルドを紐づける必要はあります。

App Store Connectは、現在公開中のビルドを新バージョンのビルド選択画面には表示しません。そのため実務上は、すでにアップロード済みの別のビルドを選ぶ(過去のTestFlightアップロードの残りでも構いません)か、同じソースコードでビルド番号だけを上げた新しいバイナリをプッシュする、のどちらかを行います。どちらも機能追加にはなりません。しかしビルドは必ず必要で、スクリーンショットを含むバージョン全体がApp Reviewを通過します。新しいスクリーンショットは、そのバージョンが承認・リリースされた後にのみ反映されます。

どのみちスクリーンショット以外も変更する場合、たとえばビジュアルと合わせて新しい説明文やキーワードセットも変える場合は、このルートを使いましょう。すべてが同じ提出に乗せられます。

ルート2: Product Page Optimization(新バージョン・新ビルド不要)

Product Page Optimization(PPO)はAppleが用意するA/Bテスト機能で、新バージョンも新ビルドも一切なしにスクリーンショットとプレビュー動画を変更できる唯一の方法でもあります。テストを作成し、新しいスクリーンショットを含むトリートメントを追加して提出します。このメタデータはアプリの新バージョンを提出せずに提出できる、とAppleは明言しています。

ただし公正さを保つ落とし穴があります。新しいクリエイティブは、テストが開始する前にApp Reviewを通過する必要があります。唯一の例外はストア上ですでに承認済みのスクリーンショットの並べ替えで、これには新規レビューが不要です。真に新しいものはすべて、まずレビューされます。

PPOは実験として設計されているため、結果はコンバージョン率の推定リフト、つまり現在のページに対するパーセンテージと、データの信頼度として返ってきます。測定テストではなく、単に新しいスクリーンショットを全員に公開したいだけなら、テストを作成・実行し、勝ったトリートメントをデフォルトのプロダクトページに適用すればよいのです。トリートメントを適用するとテストは終了し、そのクリエイティブがすべての購入検討者に配信されます。ここでもバイナリのアップロードは不要です。

明確にしておくべき境界が一つあります。スクリーンショットとプレビュー動画はPPOを通じてビルド不要ですが、代替アプリアイコンはそうではありません。アイコンは、すでにストアにあるバイナリにコンパイルされている必要があるため、本当に新しいアイコンには依然としてビルドが必要です。アイコンはビルド不要のスクリーンショット差し替えの対象外だと考えてください。

ルート3: カスタムプロダクトページ(ターゲット向けバリエーション)

メインのリスティングを変更するのではなく、特定のオーディエンスや広告キャンペーン向けに別のスクリーンショットセットを用意したい場合、カスタムプロダクトページを使えば、独自のURLで代替バージョンを公開できます。各バリアントは個別にレビューされ、リンク経由でアクセスされるため、デフォルトのページには影響しません。これは「公開中のリスティングを変更する」ためのツールというより、ターゲティングのためのツールですが、アプリを丸ごとリリースせずにスクリーンショットを動かす方法を検討するうえでは押さえておくべき選択肢です。

唯一いつでも変更できる項目: プロモーションテキスト

プロモーションテキストは、新バージョンもApp Reviewも不要で編集できる唯一のApp Store項目です。説明文の先頭に置かれる170文字のブロックで、編集は数時間以内(Appleは最大48時間としています)に自動的に反映されます。キーワードランキングのインデックス対象にはならないため検索順位は変わりませんが、スクリーンショット変更がまだレビュー中の間、時期に応じた一文を差し込むには最適な場所です。

ルート別: ビルドとレビューの一覧

どのルートを選ぶべきか

  • スクリーンショットだけを差し替えたい、最速のルート。 Product Page Optimization。ビルド不要、新しいクリエイティブへのレビューは1回のみ。あとはトリートメントを適用すれば全員に公開されます。
  • スクリーンショットに加えてテキストやキーワードも変更する。 新しいバージョンレコード。更新全体が1回の提出にまとまります。
  • メインページではなく特定のキャンペーン向けの別ビジュアル。 カスタムプロダクトページ。
  • 1時間以内に反映したい一文がある。 プロモーションテキスト。本来のスクリーンショット変更がレビュー中の間の対応として。

Mokbiの役割

Mokbiは、スクリーンショット更新の一連の流れをすべてこなします。新しいスクリーンショットとGoogle Playのフィーチャーグラフィックをデザインし、タイトル・サブタイトル・説明文・プロモーションテキストを含むリスティング全体を作成し、それらすべてを一度に50言語へ翻訳します。ここが通常スクリーンショット更新をつまずかせる工程ですが、Mokbiは1つの流れの中でこれをこなします。

そして公開まで行います。Mokbiは、Play Developer APIを通じてリスティングと完成した素材をGoogle Playへ直接プッシュし、そこで即座に公開され、App Store Connectでも提出できる状態まで準備を整えます。最終的な提出とApp Reviewの通過はご自身のアカウントで行う必要があるため、そのワンクリックだけは手元に残りますが、クリエイティブと文章はすべての言語ですでに用意されており、コンソールを開いた瞬間には新バージョンまたはProduct Page Optimizationテストの中にセットされています。

次に読む記事

新しいスクリーンショットをデザインして公開する →