fastlaneでiOSのリリースを自動化しているなら、frameit — 生のスクリーンショットをデバイスフレームで包み、マーケティングテキストを追加するfastlaneアクション — を試したことがあるでしょう。よくできたツールで、長年、デザインアプリを開けずにフレーム付きApp Storeスクリーンショットを作りたい開発者の定番でした。
しかしfastlane frameitの代替を探しているなら、その痛みはすでにご存知のはず。新しいデバイスのフレームがない、ImageMagickのセットアップ問題、そして試行錯誤が必要なJSONベースのテキストレイアウト。この記事では、frameitが苦手とする部分と、モダンな代替ワークフローがどのようなものかを見ていきます。
frameitの優れている点 #
まずは公平に。frameitはfastlaneパイプラインに自然に組み込めます：
fastlane snapshotが生成したスクリーンショットを自動的に取り込む。- CIでヘッドレスに動作するため、リリースごとにフレーム付きスクリーンショットを再生成できる。
- 無料かつオープンソース。
スクリーンショットがシンプル — デバイスフレーム1つ、キャプション1つ、単色背景 — でデバイスが十分にサポートされていれば、frameitはまだ役目を果たせます。
frameitの弱点 #
1. デバイスフレームがAppleのハードウェアに追いつかない #
frameitはメンテナンスされたデバイスフレーム画像のカタログに依存しています。毎年秋にAppleが新しいiPhoneを発売しますが、対応するフレームがカタログに反映されるまで通常ラグがあります — そもそも反映されないことも。アップデートを出すその週に最新のフラッグシップ機でスクリーンショットを見せたいなら、フレームの更新待ちは実際のコストです。
Appleの要件も待ってくれません。現在のサイズマトリクスはiPhone、iPad、Mac、Apple Watch、Apple TV、Apple Vision Proに及びます。App Store Connectが現在何を求めているかは、App Storeスクリーンショットサイズ完全ガイドをご覧ください。
2. ImageMagickへの依存 #
frameitはテキストをImageMagickでレンダリングします。つまりシステムレベルの依存関係をインストールして維持する必要があるということ — フォント設定、レンダリングを壊すhomebrewのアップグレード、追加セットアップが必要なCIイメージ。frameitのデバッグセッションの多くは、スクリーンショットではなくImageMagickの修復で終わります。
3. JSONでレイアウト、再実行で確認 #
frameitのデザイン設定はFramefile.jsonにあります：パディング、フォントサイズ、色、テキスト位置。ライブプレビューはなく、数値を編集し、コマンドを再実行し、出力を開いて、繰り返す。キャプション1つなら我慢できますが、10言語×6枚のセットでは遅く、異なるアスペクト比でテキストをきれいに配置するには多くの反復が必要です。
4. フレーム加工は工程の一部にすぎない #
frameitは画像をフレームに収めるだけです。キャプションの翻訳は管理してくれず、ローカライズ済みテキストがはみ出しても警告せず、結果をApp Store Connectに届けてもくれません — deliverを正しく設定するか、手動アップロードが必要です。デザイン、ローカライズ、全サイズの書き出し、正しい順序でのアップロードという仕事全体は、フレーム加工よりずっと大きいのです。
frameit代替に求めるべきもの #
スクリーンショットパイプラインで実際に時間を奪うものを踏まえると、代替ツールは：
- 最新のデバイスフレームを提供 — 最新のiPhone、iPad、Mac、Apple Watch、Apple TV、Vision Proを含む。
- 視覚的なフィードバック — JSON編集と再実行ではなく、直接操作。
- ローカライゼーション対応 — ロケールごとのキャプション管理と、Appleの審査前にはみ出しを確認。
- Appleのスクリーンショット仕様に合わせて、1つのデザインから必要な全サイズを書き出し。
- App Store Connectへのアップロード — 全プラットフォーム・全ロケールを正しい順序で。
ネイティブな代替：Screenshot Studio #
Screenshot Studioはまさにこのワークフローのために作られたネイティブMacアプリで、すでに使っているfastlaneツールと相性良く連携します：
fastlane snapshotはそのまま — 生のスクリーンショットの取得には自動キャプチャが今も最適です。- キャプチャをScreenshot Studioにドロップして、フレーム付きセットを視覚的にデザイン：最新のデバイスフレーム、背景、キャプション。JSONの往復ではなく即座にプレビュー。
- アプリ内でキャプションをローカライズ — AI翻訳支援付き。書き出す前にすべてのロケールの表示を確認できます。ワークフローの詳細はローカライズされたApp Storeスクリーンショットの作り方で。
- 1つのマスターデザインからすべてのデバイスサイズを自動書き出し — デバイスごとの書き出しプリセットは不要。
- App Store Connectに直接アップロード —
deliverの設定なしで、全プラットフォーム・全ロケールを正しい順序で。
ImageMagickも、フレームカタログ待ちも、面倒を見るべきシステム依存関係もありません。無料で試せて、サブスクリプションではなく買い切りオプションがあります。
frameit vs Screenshot Studio 早見表 #
| fastlane frameit | Screenshot Studio | |
|---|---|---|
| インターフェース | CLI + Framefile.json |
ネイティブMacアプリ、ビジュアルエディタ |
| プレビュー | 再実行して確認 | ライブ |
| デバイスフレーム | コミュニティのカタログ、新デバイスに遅れがち | 最新のAppleデバイス、リリースに合わせて更新 |
| 依存関係 | Ruby、fastlane、ImageMagick | なし |
| ローカライゼーション | .stringsを自前で用意、はみ出しチェックなし |
内蔵ロケール管理 + AI翻訳 |
| マルチサイズ書き出し | キャプチャしたサイズごと | 1つのデザインから必要な全サイズ |
| App Store Connectアップロード | 別途deliverの設定 |
内蔵 |
| CI自動化 | 可能 | 不可 — 対話型デザインツール |
| 価格 | 無料、オープンソース | 無料で試用可、買い切り |
正直なトレードオフ：frameitはCIで無人実行できますが、Screenshot Studioは対話型ツールです。自動ビルドごとのフレーム付きスクリーンショット再生成が必須要件なら、（メンテナンスコストと引き換えに）frameitにまだ居場所があります。しかし多くのチームのように、スクリーンショットのデザイン変更は年に数回で、ローカライズは頻繁というなら、ビジュアルワークフローの方が圧倒的に速い。App Storeスクリーンショットの隠れたコストの分析で、その数字を確認できます。
frameitからの移行 #
移行にかかる時間は、frameitの典型的なデバッグセッション1回分より短いくらいです：
- 生のキャプチャはそのまま。
snapshot（または手動キャプチャ）の出力がどちらにせよ入力になります。 - テンプレートを使ってレイアウトを一度だけ再現 — 背景、フレーム、キャプション。
- ロケールごとのキャプションをインポートまたは入力し、小さいサイズではみ出すテキストをアプリに検出させます。
- 書き出すかアップロード。 全サイズをディスクに書き出すか、App Store Connectに直接プッシュ。
以降、新リリースでのスクリーンショット更新は、キャプチャを差し替えて書き出しをクリックするだけ — JSONに触れる必要はありません。
まとめ #
frameitはスクリプト化可能なCIファーストの世界でフレーム加工を解決したツールで、シンプルで安定したセットアップには今も十分です。しかしフレームカタログの遅れに遭遇し、ImageMagickと格闘し、Framefile.jsonの数値調整に午後を溶かしたことがあるなら、専用のビジュアルツールがアップグレードです：最新フレーム、ライブプレビュー、内蔵ローカライゼーション、直接アップロード。
Screenshot Studioを無料で試して、次のスクリーンショット更新にかかる時間を確かめてください — このカテゴリーが初めてなら、App Storeスクリーンショットジェネレーターとはから始めましょう。