Fastlane Snapshot alternatives: options for capturing and managing App Store screenshots
Fastlane Snapshot is excellent at capturing screenshots on simulators. It is not a resizer, a store-asset organizer or a release tracker. Here is what to pair with it.
5 min read
Fastlane Snapshot has a well-earned reputation: give it a UI test that screenshots each screen, and it will fire the simulator across the devices and languages you configure, dropping organized frames into a directory. What people discover six months in is that capturing is only half the job. Snapshot does not resize a single frame, does not know a Play device class from a store slot, and has no idea which screenshot shipped with version 2.4.0. For that half, you need something alongside it.
What Fastlane Snapshot is actually good at
Before replacing anything, give it credit where it earns its keep:
- Deterministic captures. The same UI test on the same simulator produces the same frames, so a release is never at the mercy of a human screenshot.
- Localization for free. One config, every launch language you ship, all in the same run.
- CI-friendly. It plugs into Fastlane, which already handles signing, building and distribution.
Where Snapshot stops
The frames it produces are raw captures at whatever resolution the simulator rendered. From there the manual part of screenthot work begins:
- Resizing is still your job. A 1179 × 2556 sim frame is not a 1290 × 2796 store upload, and Snapshot will not crop black bars or produce the exact sizes App Store Connect and Play Console want.
- No slot logic. Play screenshots live in separate lists per device class, and Apple screenshots have no class split at all. Snapshot outputs folders; it does not know a phone set from a 10-inch tablet set.
- No version or release tracking. Nothing ties a captured frame to the app version it goes out with, so “which screenshot did we actually ship?” becomes archaeology.
- No other store asset. Feature graphics, store headers, the single icon master that feeds seven sizes — none of that is a Snapshot concern.
The alternatives, honestly ranked
There are broadly three ways teams answer the question:
- Keep Snapshot for capture, add asset management around it. This is the setup most teams should land on. Snapshot keeps doing the thing it is best at — cranking out fresh frames — and the frames get uploaded, resized, labeled, validated and versioned downstream. You keep your UI tests and your pipeline; you hand the final 20% to something built for it.
- A fully managed capture service. Services that run your UI tests in the cloud (or route your CI captures through a managed pipeline) remove simulator setup and snapshot configmaintenance too. The trade-off is price, a new dependency, and handing over capture — a step you already own comfortably.
- Doing it by hand. It works for one device, one language, one release. It does not scale to a product with two storefronts and four languages, which is the exact situation that produces a Friday evening of re-exporting.
For most teams the honest answer is the first one: Fastlane Snapshot stays, and the management layer is the part worth replacing.
Fastlane Snapshot vs. a release asset platform, side by side
| Capability | Fastlane Snapshot | Releaseyour.App |
|---|---|---|
| Runs UI tests to capture frames on simulators | Yes | No |
| Captures per language in one pass | Yes | No |
| Resizes frames to the sizes stores demand | No | Yes |
| Labels Play device classes and store slots | No | Yes |
| Generates every icon size from one master | No | Yes |
| Tracks which screenshots shipped with each version | No | Yes |
| Holds Apple and Play assets in one place | No | Yes |
The two are not rivals. The line that matters is capture vs. everything after capture: UI-test-driven frames belong to Snapshot, and the resizing, slotting, versioning and store review belong to the platform. Choose each side for what it does well.
The pipeline we would run
In practice, the strongest setup is boring:
- CI runs Snapshot across devices and languages as part of the release build.
- Artifacts upload to Releaseyour.App — one upload per language, labeled with the slot it fills.
- The platform resizes to the store-accepted sizes, checks every rule, and generates the icons from the master.
- Reviewers see the diff against the previous release, not a pile of files.
Snapshot keeps your capture automated. The platform keeps the rest of the release honest. If you want to try it, our screenshot resizer is the part that takes the hand work out — and it works just as well if you upload screenshots you already captured.
Short answers
- Do I still need Fastlane Snapshot if I use this? No, but you may want to keep it. The platform sizes, slots and versions; Snapshot captures. Either can stand alone.
- Will it stretch my iPhone frames to iPad? No — and you should not want it to. A stretched phone layout is not a tablet screenshot. Capture per device family; resize only within it.
- Does it replace my UI tests? Never. Capture correctness stays exactly where it is now.
Previous: how to resize App Store screenshots — or start free to see the management half in action.
Stop resizing screenshots by hand
Releaseyour.App turns one master capture into the sizes every device needs, generates every icon from a single 1024px square, and keeps the whole set versioned per release.