· Publishing · 6分で読めます

fastlaneなしでApp Storeの掲載情報を公開する方法

fastlaneなしでApp Storeの掲載情報を公開する方法
TL;DR.fastlaneのdeliverとsupplyは、コマンドラインからメタデータ、スクリーンショット、バイナリを両方のストアにプッシュしてくれます。無料でオープンソースなので、CIに組み込めば常に最新の状態を保てます。ただしそのコストとして、Ruby、Xcode(またはGradle)、Fastfile、UIテストの保守を含むパイプラインを誰かが構築・維持する必要があります。パイプラインを運用したくないなら、ノーコードの選択肢はストアのWebコンソール、ストアAPIを直接叩く方法、または掲載情報を自動で作成してくれるツールです。Mokbiはノーコードでありながら実際に公開まで行う方法です。スクリーンショットとフィーチャーグラフィックをデザインし、掲載情報全体を作成して50言語に翻訳し、Play Developer APIを通じてGoogle Playへそのままプッシュ。App Store版はApp Store Connectに下書きとして準備され、あとは提出するだけです。Rubyも、Xcodeも、UIテストも不要です。

fastlaneが定番の答えになっているのには理由があります。無料でMITライセンスのツールキットであり、deliverアクション(エイリアスupload_to_app_store)は、スクリーンショット、App Previewの動画、メタデータ、バイナリを1コマンドでApp Store Connectにアップロードします。Android側ではsupply(エイリアスupload_to_play_store)が同じことをGoogle Playに対して行います。メタデータ、スクリーンショット、APKまたはApp Bundleです。どちらもCIから実行すれば、リリースのたびに掲載情報が再生成され、アプリの内容とずれることがありません。

つまり本当に問うべきなのは「fastlaneは良いツールか」ではありません。良いツールなのは確かです。問題は、それを良くしているパイプラインを自分で持ちたいか、それともパイプラインなしで掲載情報を更新したいか、ということです。

deliverとsupplyが実際にやっていること

どちらも公式のストアAPIのラッパーです。裏側では、fastlaneは自分で呼び出すのと同じAPIを呼んでいます。

  • deliver(iOS)。アプリ名、説明文、キーワード、リリースノート、URL、カテゴリ、審査情報に加えて、ローカライズされたスクリーンショットとプレビュー動画をアップロードします。バイナリはAppleのiTMSTransporter経由で、メタデータはApp Store Connect API経由でアップロードされます。アップロード後に審査提出まで行うこともできます。
  • supply(Android)。メタデータ、スクリーンショット、APKまたはAABをGoogle Playにアップロードし、トラックを選んでビルドを昇格させます。注意点として、アップロードしたスクリーンショットは既存のものに追加されるのではなく、そのロケールの既存分を置き換えます。

どちらもAPIキーで認証します。AppleはApp Store Connect APIキー、Googleはサービスアカウントの JSON です。一度設定すればCI上で無人稼働できます。それこそがこの仕組みの魅力で、メタデータとスクリーンショットをコードとしてリポジトリでバージョン管理し、ビルドのたびに出荷できます。

fastlaneの本当のコスト

fastlaneのインストールと実行自体は無料です。コストがかかるのはセットアップと保守であり、そのコストはエンジニアの時間で支払われます。

  • 維持すべきランタイム。fastlaneはRuby(3.0以上)のツールチェーンで、通常Bundlerで管理します。iOSの作業にはMac上のXcodeが必要で、Androidの作業にはGradleの側が必要です。これらはインストールしてパッチを当て続ける実物のインフラです。
  • 書くべき設定ファイル。Fastfileでレーンを定義し、DeliverfileやAndroidのメタデータフォルダに掲載情報の詳細を保持します。最初に動くバージョンを正しく作るまでには、たいてい1〜2日かかります。
  • 立ち上げるべきCI。この自動化はパイプラインの中でこそ元が取れます。つまりAPIキー、署名用のシークレット、ビルドランナーを設定し、常にグリーンな状態を保つ必要があります。
  • 使う場合のスクリーンショット取得の保守。fastlaneのsnapshotは、シミュレータでUIテストを走らせてロケールごとにスクリーンショットを取得します。このテストは壊れやすく、数か月は順調に動いても、UIの変更でフローが壊れ、新しい画面状態に合わせてテストコードを書き直す羽目になるという報告がよくあります。snapshotはデフォルトで不安定な実行をリトライしますが、それはネットワークやデータ起因の非決定性を覆い隠しているだけで、根本解決にはなりません。しかも出力される生のスクリーンショットにはキャプションも背景もないため、結局別のツールでデザインを仕上げるチームも多いです。

これはツールへの批判ではありません。fastlaneは繰り返し発生する手作業をコードに変換する、正直なトレードオフです。その代わりにコードを保守する必要があります。毎週リリースし、リリース自動化を担当するエンジニアがいるチームにとっては良い取引です。年に数回しか掲載情報を更新しない一人開発者やPMにとっては、パイプラインを維持するコストが、節約できる分を上回ることもあります。

fastlaneなしで掲載情報を更新する

fastlaneを使わない場合でも、メタデータとスクリーンショットをストアに反映する方法は3つあります。

1. ストアのWebコンソール

もっともシンプルな方法です。App Store Connectでは各ローカライズを手で編集し、表示サイズごとのスロットにスクリーンショットを入れます。Google Play Consoleでは言語ごとにストア掲載情報を編集し、スクリーンショットをアップロードします。コードもキーも不要で、維持すべきものもありません。クリックしていくだけです。難点は完全に手作業であることで、多くのロケールを画面1枚ずつ処理していくのは遅く、ミスも起きやすいです。1〜2言語なら問題ありませんが、20言語となると苦痛です。

2. ストアAPIを直接叩く

両ストアともfastlaneが呼んでいるのと同じAPIを公開しているので、fastlaneのRubyスタックを採用せずにスクリプトを組むこともできます。AppleのApp Store Connect APIは、短命なJWT(ES256、自分の鍵で署名)で認証するREST APIで、スクリーンショットセットの作成、画像バイトの予約とアップロード、メタデータのパッチ用エンドポイントを持ちます。GoogleのPlay Developer APIは「edits」モデルを使います。editを開き、掲載情報や画像を変更してから、それをコミットします。これにより完全なコントロールが得られ、独自の社内ダッシュボードにも組み込めますが、その統合を自分で書いて保守する必要があります。fastlaneのフルパイプラインよりは小さな負担ですが、ゼロではありません。

3. 掲載情報を作成してくれるマネージドツール

もう一つのノーコードの道は、掲載情報そのものをツールが作ってくれる方法です。残るのはそれをストアに反映するだけです。ここでトレードオフが逆転します。エンジニアがパイプラインを持つのではなく、PMやデザイナーがブラウザ上で掲載情報を直接管理します。CIの自動化と引き換えに、エンジニア自体が不要になるのです。

Mokbiが実際に当てはまる場面(正直に言うと)

Mokbiはfastlaneが持つCIのストーリーを置き換えようとはしていません。ビルドのたびに人の手を介さずスクリーンショットを再生成したいなら、fastlaneパイプラインが正しい選択肢であり、しかも無料です。私たちが向いているのはその逆のケースです。Ruby、Xcode、Fastfile、UIテストに触れずに洗練された掲載情報を出したい人向けです。

ブラウザ上でスクリーンショットをデザインし、ストアテキストを作成し、掲載情報全体を50言語に翻訳できます。シミュレータもCIもコードも不要です。デザイナーやPMがマーケティング周りをエンドツーエンドで管理できます。

最後の一手も、Mokbiがカバーします。スクリーンショットとフィーチャーグラフィックをデザインし、掲載情報全体を作成して50言語に翻訳し、その結果をPlay Developer API経由でGoogle Playへそのままプッシュ、App Store版はApp Store Connectに下書きとして準備され、あとはSubmitを押すだけです。最終的なSubmitと審査自体はAppleが要求するルールであり、こちら側の不足ではありません。fastlaneが呼ぶのと同じエンドポイントを使い、パイプラインだけを省いています。

どちらを選ぶべきか

  • 毎週リリースし、エンジニアがいて、ずれをゼロにしたい?fastlaneです。無料で自動化されており、スクリーンショットとメタデータをアプリと完全に同期させます。この点では他に勝るものはありません。
  • 年に数回しか掲載情報を更新せず、CIに割く余裕がない?Webコンソール、または掲載情報を作成してくれるツールです。このペースではパイプラインの維持コストが見合いません。
  • プログラムによる制御は欲しいが、fastlaneのスタックは要らない?App Store ConnectとPlay Developer APIを直接呼び出してください。
  • デザイナーやPMに多言語で掲載情報を管理させたい?ブラウザから作成・翻訳・公開しましょう。MokbiがGoogle Playへプッシュし、App Store版は提出可能な状態で準備します。

fastlaneは無料で自動化された定番として、その地位に値します。ノーコードの道は「より優れている」わけではなく、異なるトレードオフです。CIの自動化を手放す代わりに、掲載情報を更新するためのパイプラインを誰も構築・面倒見しなくてよくなります。

次に読むべき記事

エディタを開く →