Storeboard/Blog/fastlane frameit alternatives

fastlane screenshots without the Ruby stack

Tools 26 July 2026 · 7 min read

Framed screenshots without the Ruby stack, beside three exported App Store screenshots

fastlane is one of the best things that ever happened to iOS shipping. It is also, for screenshot design, a workflow where you edit a config file, run a build, wait, look at a PNG, and go back to the config file. If that loop is your least favourite part of release week, this post is for you.

What fastlane gets right

Credit first. snapshot drives your UI tests to capture raw screens on every simulator and language you configure. frameit wraps them in device frames with captions from .strings files. deliver uploads everything. Wire it into CI and your screenshots regenerate themselves on every release — free, open source, and fully repeatable. For a large team shipping ten devices × thirty languages, nothing else touches it.

Where the model hurts

Design by config file. Caption text lives in keyword.strings and title.strings, colors and fonts in a Framefile.json. Every visual decision is a text edit followed by a full re-run. There is no canvas, no drag, no live preview.
The Ruby stack. A working ruby/bundler environment, gem conflicts after macOS updates, and a dependency your designers will never install. Plenty of teams keep a "fastlane machine" alive purely out of fear.
Layout is one template. frameit gives you the device + caption above or below. Backgrounds with gradients, angled hero devices, per-word caption styling, second devices — that's outside its vocabulary.
Localized captions are yours to write. frameit renders whatever translations you put in the .strings files. Producing thirty languages of marketing copy is still your problem.

A plain app screen with no caption or frame, an arrow, then the same screen as two finished App Store screenshots with a caption, device frame and background, one cream and one yellow — What frameit does, and what the rest of this post is about: a plain screen in, a captioned and framed App Store screenshot out. Here in two looks from the same set.

What a native alternative looks like

Storeboard replaces the config loop with a canvas: drop your raw screens into device frames, drag captions, style individual words, tilt devices in 3D, and watch a live App Store preview — then export every enabled language and device at Apple's exact pixel sizes in one pass. Captions and full listing metadata are written and translated on your Mac (Apple Intelligence on-device, or your own API key), so the thirty-languages problem is one click, not a translation project.

The philosophical difference: fastlane treats screenshots as build artifacts; Storeboard treats them as marketing design. Both are correct — for different teams at different times.

One click restyles every screenshot, instead of editing a config file and re-running frameit.

Storeboard showing five screenshots of a set side by side, each tagged with the languages it is translated into — The whole set side by side, each screenshot tagged with its languages, so you check the design once rather than folder by folder.

Honest guidance: when to keep fastlane

You regenerate screenshots automatically in CI on every release — keep fastlane.
Your captions almost never change and are already translated — keep fastlane.
You iterate on screenshot design, localize marketing copy, or want keyword-informed captions — a design tool beats a config file.
Many teams do both: snapshot for raw captures, Storeboard for design and localization. The two compose cleanly, since Storeboard accepts any image you drop in.

Migration in practice

Keep your snapshot setup — its raw, unframed output is exactly what you want.
Drop those captures into Storeboard's device frames (it detects already-designed images too).
Bring your existing captions across once; from then on they translate per-language in-app.
Export all sizes and upload with your usual process.