ローカライズしたスクリーンショットを両ストアに一括アップロードする方法
deliver/supply）だけです。Mokbiはすべてのロケール×デバイスをレンダリングし、そのセットを両ストアに公開します — Google PlayへはPlay Developer API経由で直接プッシュし、App Store Connectでは最終提出の準備が整った状態でステージングします。リリース作業の真っ最中だとします。スクリーンショットは完成しました。あとは対応するすべての言語、各ストアが求めるすべてのデバイスサイズで、両ストアにアップロードするだけです。ここが誰も教えてくれない部分であり、多くの人が「bulk upload localized screenshots app store connect / google play all languages」のような検索に静かに手を伸ばす場面です。
先に率直な答えを言っておきます。どちらのストアにも、ロケールをまたぐネイティブな一括アップロードはありません。ロケールごと、デバイスサイズのファミリーごとに、Web UI上でひとつずつバケットをアップロードすることになります。
「一括アップロードがない」の本当の意味
App Store Connectでは、アプリを開いてバージョンを選び、スクリーンショットのセクションまでスクロールして、特定の表示タイプのスロット — 6.9インチ、6.5インチ、13インチiPadなど — にPNGをドラッグします。それから言語ドロップダウンを次の言語に切り替えて、また同じことを繰り返します。Appleではデバイスタイプ・ローカライゼーションごとに最大10枚のスクリーンショットを追加できますが、画像に対する「全言語に適用」ボタンはありません。
Google Play Consoleも同じ仕組みです。「メインのストア掲載情報」でロケールを選び、電話、7インチタブレット、10インチタブレット、さらに任意でChromebook、Wear OS、Android TVなど新しい種類のデバイスセクションごとにスクリーンショットをアップロードします。デバイスタイプごとに最大8枚。言語を切り替えて、また繰り返します。
つまり作業単位は「ひとつのスクリーンショットセット」ではありません。1バケット = 1言語 × 1デバイスサイズファミリーであり、それぞれのバケットを手作業で埋めていくことになります。
ドラッグ作業の量を数値化する
バケットの数を正直に数えてみましょう。Appleでは、通常の提出でも少なくともiPhoneディスプレイファミリーとiPadディスプレイファミリーを埋める必要があります — 6.9インチとは別に6.5インチのiPhoneセットも維持するならさらに増えて、大まかに2つとします。Playでは、通常の提出で電話とタブレット2サイズを埋めるので、大まかに3つ — Chromebookや Wear OS を加えればさらに増えます。
- 1言語、両ストア: Apple約2バケット + Play約3バケット = 手作業アップロード5回。
- 10言語: 約20 + 30 = 埋めるべきバケットは50個、それぞれに最大8〜10枚の画像。
- 50言語: 約100 + 150 = ドラッグ&ドロップのアップロードは合計250回。しかも正しい画像が正しいスロットに入ったかを確認する前の話です。
「1ロケールあたり30分のドラッグ作業」とよく言われるのには理由があります。本当の言語数になると、これはもはや作業ではなく半日仕事になり、しかも次のリリースでまた繰り返すことになります。
唯一の2つの自動化ルート
Web UIを完全にスキップしたい場合、サポートされているドアはストアごとに1つずつ、計2つだけです。
- App Store Connect API。スクリーンショットのリソースを使えば、特定のローカライゼーションとデバイス表示タイプについて、セットを作成しプログラムで画像をアップロードできます。APIキーで認証し、ロケール・表示ファミリーごとに画像をプッシュします。
- Google Play Developer API。
edits.images.uploadメソッドは、指定した言語と画像タイプ（phoneScreenshots、sevenInchScreenshots、tenInchScreenshotsなど）の画像1枚を保留中の編集にアップロードし、それをコミットします。
ほとんどのチームはこれらを直接呼び出しません。上にfastlaneを乗せて使います。deliver（upload_to_app_storeとしても公開）はApp Store Connect APIを動かし、supply（upload_to_play_store）はPlay Developer APIを動かします。supplyは複数のアップロードスレッドを起動して、ローカライズ画像を並行してプッシュすることさえあります。これこそが本当の「一括アップロード」— ダッシュボードのボタンではなく、APIのループなのです。
コスト面もはっきりさせておく価値があります。fastlaneを使うということは、Rubyツールチェーン、fastfile、ストアAPIの認証情報、そして（Apple側では）お馴染みのコード署名とシミュレーター周りの整備が必要になるということです。頻繁にリリースするなら十分に元が取れますが、年に数回しか提出しないアプリでは、画像アップロードのためだけに環境を整えるのが、置き換えたかったドラッグ作業より手間になることもあります。すでにビルド用に運用しているなら、スクリーンショット工程を追加するのはほぼ無料です。
本当のボトルネックはスクリーンショットの出どころ
上記のどのルートも、ファイルがすでに存在していること — 正しいサイズで、デバイスファミリーごとに1セット、言語ごとに翻訳済みであること — を前提にしていることに注目してください。それこそが本当に大変な部分です。App Store Connect APIとPlay Developer APIは完成した画像を移動させるだけで、デザインもリサイズもキャプションの翻訳もしてくれません。50言語×5デバイスサイズをデザインツールで手作業で作っているなら、アップロードはそもそもボトルネックではなかったのです。
Mokbiが埋めるのはまさにこの隙間です。1つのデザインを作れば、そこからすべてのデバイスサイズと50言語すべてをレンダリングします — キャプションは翻訳され、レイアウトは再構成され、各フレームはストアのスロットが求める正確なピクセル寸法で書き出されます。出力はバッチです。ロケール×デバイスのクリーンなファイル一式が、名前も整理も済んだ状態で、正しいバケットに投入できるように用意されます。
両ストアへのワンクリック公開
Mokbiはまさにこの問題を解決します。1つのセットを作れば、すべてのロケール×すべてのデバイスサイズをレンダリングし、両ストアに公開します — Google PlayへはPlay Developer API経由で直接プッシュし、App Store Connectでは提出できる状態でセットをステージングします。Appleでは最終的な提出とレビューが必須なので、その最後のタップはあなたの手に残りますが、それ以外はすべて自動化されます。ロケールごと・デバイスごとの手作業アップロードは不要です。
すでに自前のCIでfastlaneやストアAPIを運用しているなら、同じ書き出しファイルをそのままdeliverとsupplyに渡せます。いずれにせよ、デザイン、リサイズ、50言語分の翻訳はすでに済んでいます — そして今では公開まで済んでいます。
本当に半日分の作業を節約するワークフロー
- 一度だけデザインする。エディタでカルーセルを一度だけ作成します。
- マトリクスを一括書き出しする。すべてのデバイスサイズ×すべての言語を、ストアが求める正確な寸法で、一度の書き出しで生成します。
- 両ストアに公開する。MokbiがセットをGoogle Playにプッシュし、App Store Connectでは最終提出のためにステージングします — 自前のCIを運用しているなら、fastlaneの
deliver/supplyにファイルを渡すこともできます。 - 次のリリースでは再書き出しして繰り返すだけ。デザインを一度変更すれば、マトリクス全体を再生成し、再度アップロードするだけです。
重要な計算はこうです。バケットの数自体は変わりませんが、デザインとリサイズを先にすませた完成ファイルを投入するだけになるため、1バケットあたりの所要時間が激減します。半日仕事とコーヒーブレイク一杯ほどの違いです。