「frameit fastlane」と検索してこのページにたどり着いたなら、おそらく App Store のスクリーンショット生成を自動化しようとしているのではないでしょうか。すでに導入してみたものの壁にぶつかっているか、あるいは本格的にセットアップに踏み込む前に、もっと手早い方法がないかを見極めようとしているところかもしれません。
この記事では、Fastlane frameit が実際に何をしてくれるのか、インディー開発者にとってどこが負担になりやすいのか、そして Marteso が同じスクリーンショット自動化の課題にどう違ったアプローチで取り組んでいるのかを解説します。読み終える頃には、自分の状況にどちらのツールが合うかを判断できるはずです。
Fastlane frameit がしてくれること
Fastlane は、iOS と Android のデプロイを自動化するためのオープンソースのツールキットです。スクリーンショットのパイプラインは、主に 2 つのアクションで構成されています。
snapshotは、Xcode の UI テストを使って複数のシミュレーターからスクリーンショットを撮影しますframeitは、撮影したスクリーンショットを App Store 申請用にデバイスフレームで囲みます
Fastlane を使った典型的な iOS スクリーンショット自動化のワークフローは、次のようになります。
- キャプチャしたいすべての画面に遷移する UI テストを書く
- snapshot と frameit のレーンを
Fastfileに設定する - ローカルで
fastlane snapshotを実行する（ロケール数に応じて 1 回あたり 20〜40 分） fastlane frameitを実行してデバイスのベゼルを適用する- 各ロケール・各デバイスサイズの出力を手作業で確認する
- 完成したスクリーンショットを App Store Connect にアップロードする
ターミナルが日常的な作業場であり、すでに CI/CD パイプラインを持っている開発者にとっては、このワークフローは十分に機能します。専任の DevOps 体制があり、すべてを自分でコントロールしたいというチームにとっては、事実上の標準でもあります。
Fastlane frameit がインディー開発者にとって負担になりやすいポイント
セットアップのコストは、見た目以上に高くつきます。Fastlane を動かすには、Ruby、Xcode シミュレーターの構成、プロビジョニングプロファイル、そして正しく動く Fastfile が必要です。より良い App Store のスクリーンショットを作りたいだけの個人開発者にとって、これは 1 枚のスクリーンショットが生まれる前に数時間の環境構築を強いられることを意味します。
運用にかかるコストはさらに大きくなります。デバイスフレームは iOS のリリースごとに変わります。Apple が新しいハードウェアを出すたびに、既存の frameit のフレーム素材は古くなったり、位置がずれたりします。gem を更新し、素材のパスをデバッグし、出力が正しく見えるかを確かめるためにパイプライン全体を再実行する。これが Apple のスケジュールに合わせて、あなたの都合とは関係なく発生するのです。
ローカライズは、その作業量を何倍にも膨らませます。5 言語・3 デバイスサイズに対応するアプリなら、スクリーンショット 1 枚につき 15 通りの出力セットが生まれます。60 個以上のファイルを手作業で管理し、各ロケールでテキストが正しく表示されているかを確認し、自分が読めない日本語やドイツ語の出力に目を通す。こうした作業こそ、申請前夜まで先延ばしにされがちなものです。
スクリーンショットのコピーは、完全に手作業です。Fastlane がキャプチャするのは、UI テストが表示する内容だけ。スクリーンショット自体に載るオーバーレイのテキスト、見出し、ローカライズされた宣伝文の作成は、ツールの外側で行うことになります。言語ごとに異なるコピーを使いたいなら、それを UI テストに組み込むか、別の素材パイプラインを用意して管理するしかありません。
これらは Fastlane の不具合ではありません。Fastlane は、すべてのステップを自分の手中に置きたい開発者向けに作られた、ローレベルなツールなのです。そのトレードオフとして、あらゆるステップにあなたの時間とメンテナンスが必要になります。
Marteso が違うところ
Marteso は、App Store 申請のために特化して設計された、ノーコードのスクリーンショット自動化プラットフォームです。Fastlane frameit と同じステップをカバーしますが、そのアプローチはほぼすべての場面で異なります。
セットアップ: GitHub リポジトリと App Store Connect アカウントを、Marteso の UI から接続するだけ。Ruby も Fastfile も、ローカルのシミュレーター構成も不要です。ほとんどの開発者が 30 分以内にセットアップを終えています。
トリガー: GitHub にプッシュするだけ。Marteso が webhook を受け取り、マネージドなクラウド環境で UI テストを実行します。ローカルでは何も動きません。
ローカライズ出力: 1 回のテスト実行で、対応するすべての App Store 言語向けにデバイスフレーム付きのスクリーンショットを生成します。アプリの文字列がすでにローカライズされていれば、追加のテスト設定は必要ありません。Marteso は既存の文字列ファイルを使って、ロケールごとの出力を自動的に生成します。
AI によるスクリーンショットコピー生成: Marteso は AI を使って、各スクリーンショットのオーバーレイテキストと宣伝コピーを生成します。提案された内容を確認・編集してから、最終的な素材に反映できます。白紙の状態から書き始める必要はありません。
デバイスフレーム: Marteso 側で保守します。Apple が新しいベゼルを備えたハードウェアをリリースすれば、プラットフォーム上のフレームが自動的に更新されます。gem のバージョンや素材ファイルを自分で管理する必要はありません。
リリースを 1 人で回しているインディー開発者にとって、その違いはスピードだけではありません。リリースのたびに発生する意思決定とメンテナンス作業の「数」そのものが変わるのです。Fastlane では、すべての設定の詳細を自分で抱え込まなければなりません。Marteso は妥当なデフォルトを用意したうえで、重要な部分だけを上書きできるようにしています。
一覧で比較
| Fastlane frameit | Marteso | |
|---|---|---|
| セットアップ時間 | 2〜4 時間（Ruby、Fastfile、シミュレーター構成） | 30 分以内（GitHub と ASC を接続） |
| 実行環境 | ローカルマシン、または手動構成した CI | フルマネージドなクラウドパイプライン |
| デバイスフレームの保守 | 手作業（iOS リリースごとに gem を更新） | 自動 |
| ローカライズ | ロケールごとに手作業でテストとファイルを構成 | 既存のアプリ文字列ファイルから自動生成 |
| AI によるコピー生成 | なし | 標準搭載、書き出し前に確認可能 |
| 価格 | 無料（オープンソース） | 無料プランあり、規模の大きいアプリ向けに有料プラン |
| 求められるスキル | ターミナルと Ruby に慣れていること | CLI 不要 |
| カスタマイズ性 | すべてのステップをプログラムで完全にコントロール | ダッシュボード UI から設定 |
Fastlane が向いている人
Fastlane frameit が正しい選択になるのは、すでに CI に Fastlane の基盤があるチームに所属している場合、パイプラインを保守する DevOps エンジニアがいる場合、あるいはスクリーンショット生成をプログラムで完全にコントロールする必要がある場合です。動作する Fastfile があり、その保守を担当する人がいるのなら、わざわざ乗り換える理由はありません。
特殊なスクリーンショット要件がある場合も、Fastlane のほうが適しています。標準的でないシミュレーターのフロー、独自のフレーム素材、あるいはテスト実行時に注入したデータに依存するスクリーンショットのワークフローなど、マネージドなプラットフォームでは対応しきれないケースです。
Marteso が向いている人
Marteso は、独自のパイプラインを構築・保守することなく、正確でローカライズされたスクリーンショットを手に入れたいインディー iOS 開発者のために作られています。個人開発者や小規模チームで、セットアップの負担が高すぎてスクリーンショット作業がいつも後回しになってしまうなら、Marteso がその負担を取り除きます。
マネージドなパイプラインは、設定を完全にコントロールできる代わりに、リリースのたびに時間を取り戻せることを意味します。1〜2 人でリリースするほとんどのインディーアプリにとって、これは分かりやすいトレードオフです。スクリーンショット作業が後回しにされることなく、予定どおりに片付くようになります。
試してみる
Marteso には app.marteso.com（[email protected] / demo1234）にデモ環境があり、スクリーンショット生成、メタデータ編集、App Store Connect への申請までを含むリリースワークフロー全体を一通り体験できます。デモには実際のアプリが使われているため、そこで確認できるスクリーンショット自動化の出力は、本番実行で得られるものと同等の内容です。