How Does fastlane snapshot Automatically Generate iOS Store Screenshots? 2026

The UI test passes, but your screenshot folder is empty, inconsistent, or filled with the wrong language.

Fastest fix: first run one representative UI test successfully in Xcode; then use fastlane snapshot to capture and manually review the images. You need a Mac environment that can run macOS, Xcode, and the iOS simulator.

This guide is for independent developers preparing store images in multiple languages, small teams maintaining several simulator targets, and iOS developers checking whether a remote Mac can handle screenshot automation. If you only need a one-off image and already have a suitable device, manual capture may be quicker.

Automate iOS App Store screenshots with fastlane snapshot

fastlane snapshot is useful when you can drive the app to the same screens through a repeatable UI test. The test opens the app and navigates its interface; snapshot coordinates capture across the languages and simulator targets you configure. The official screenshot guide describes the workflow and initialization. Treat it as a capture pipeline, not as a substitute for testing your app or approving store assets.

Keep these three jobs separate:

• Capture: run UI tests and save images for the selected targets.
• Review: confirm every image shows the intended language, screen, and app state.
• Upload: send the approved files to the intended App Store Connect app and localization.

A successful capture means the automation created files. It does not mean the assets meet your submission needs, have been uploaded to the correct place, or will pass review.

Single-device project: prove one screenshot path first

Start with one representative flow, not a large matrix of devices and locales. Your project needs a UI Test target, a scheme that is shared and available to the automation, and test code that reaches the screen you want to capture. The capture call belongs at the point where that screen is ready.

Run the UI test in Xcode first. Confirm that it launches the expected app, reaches the intended view, and finishes without relying on a manual tap or a developer-only local state. Then run the snapshot workflow using the official setup instructions. Check that the output exists and that the captured image contains the expected content.

If this single path is unstable, adding more targets only multiplies the debugging work. Fix the test, test data, or app state before broadening the run.

A passing UI test can still produce a bad store image. Inspect the actual file: test success reports automation status, not whether the screen is visually suitable.

Multilingual app: separate interface language from store metadata

A localized screenshot must show the language you intend to present. Configure snapshot for the languages you need, then verify that the app launches in each one during the UI test. A language option in the capture configuration does not replace localization work in the app. If the app falls back to its default language, the screenshot will faithfully capture the wrong interface.

Also distinguish two kinds of localization:

• App interface localization: the language displayed inside the app when the test runs.
• Store metadata localization: the language-specific listing and assets configured in App Store Connect.

Generating images in multiple languages does not configure the corresponding store listing. Check that your output folders or filenames let you identify which language each image represents. Open a sample from each language and compare visible text, including navigation labels, alerts, and any test data rendered on screen.

For the capture configuration, use the current capture_ios_screenshots action reference to check the supported options, including language and simulator-target settings. Avoid copying an old configuration from another project without checking it against the fastlane version and Xcode setup you are actually running.

Multiple simulators: expand coverage by supported targets

You can configure more than one simulator target, but a target is useful only if the selected Xcode environment can run it and your project behaves correctly on it. Choose targets based on the devices your app supports and the store assets you need. Do not treat one successful capture as evidence that all device sizes have been covered.

Keep the target list in your fastlane configuration rather than scattering device choices across scripts. The documented configuration includes fields such as devices, languages, scheme, and output_directory; check the fastlane screenshot guide for current syntax and behavior. Set an output location that your team can access and that will not silently mix new images with stale files.

Apple documents how to manage simulated and physical devices in Xcode Device Hub. Before adding a simulator target, confirm that it is available in the intended Xcode environment. Then run the screenshot workflow for that target and inspect the result independently.

Check the current App Store screenshot specifications for the product and submission context you are preparing. Requirements can differ by platform or asset context. Use the current Apple reference rather than relying on an old image-size list copied into a project document.

Unstable images: control app state before adding retries

An inconsistent image usually points to an inconsistent test path or app state. Check whether the test depends on a previously authenticated session, live network content, a loading indicator that appears for an unpredictable duration, or data that changes between runs.

Make the test state explicit. Use predictable test accounts and fixtures where appropriate. Reset the app to a known state before navigating. Wait for the specific content the test needs rather than assuming a screen is ready immediately after a tap. If a request can fail or return different content, decide whether the test should use controlled data or report a failure instead of capturing a misleading image.

fastlane documentation describes available behavior for screenshot capture and test execution, but retries cannot repair an unreliable test design or guarantee that every capture is correct. Check the current action documentation and verify any waiting or retry behavior in your own project. Do not make a retry setting the only safeguard against a network-dependent screen.

If the same test produces different visible content on repeat runs, stop expanding the screenshot matrix. Stabilize the state first; otherwise, you will have more files to sort and fewer reliable assets.

Remote Mac: validate the UI test before automating capture

A remote Mac can run this workflow only if the necessary macOS and Xcode environment is available and the selected simulator runtime, project scheme, and UI Test target work there. Apple’s documentation places simulator management and device operations within Xcode on Mac; see its guidance on capturing screenshots and videos from devices.

Treat remote execution as an environment check, not a shortcut around local test failures:

1. Open the project in the intended remote Mac environment.
2. Confirm that the required Xcode installation and simulator runtime are available.
3. Select the same shared scheme and test target you plan to use for capture.
4. Run the representative UI test and inspect its result before starting snapshot.
5. Run the capture and verify that the generated files are present in a location you can access after the session.

Also check how your automation handles login sessions and how long the process can remain active. A browser-based console, SSH session, or VNC connection does not by itself confirm that a test completed or that its output was saved. If you are evaluating a remote environment, review the MacUDP help resources for the available access and environment information, then verify the workflow with your own project.

Before upload: review the files and the destination

A capture folder is an intermediate result. Before uploading, confirm that each image belongs to the expected language and simulator target, depicts the current app interface, and contains intentional test data. Remove outdated images rather than trusting a folder just because a recent run completed.

Apple’s screenshot upload instructions explain the App Store Connect workflow. fastlane’s deliver documentation describes how deliver can upload screenshots. Before using an automated upload, verify the target app and localization, understand how the run interacts with existing metadata, and review the final files. Upload automation does not decide whether your screenshots accurately represent the app or meet review expectations. Apple’s guidance on screenshots in app review is a separate check from successful generation.

Use this review list before you widen coverage or submit assets:

• [ ] The shared scheme runs the intended UI Test target in Xcode.
• [ ] The test reaches the intended screen without manual intervention.
• [ ] Each configured language appears in the app interface as expected.
• [ ] Each configured simulator target has been tested in the current Xcode environment.
• [ ] The output location is accessible, and old images are not mixed with new results.
• [ ] You have opened and reviewed the final images, not just checked that files exist.
• [ ] The upload target and store localization match the reviewed assets.

FAQ: fastlane snapshot and iOS store screenshots

Can fastlane snapshot create screenshots from iOS UI tests?

Yes. fastlane snapshot runs UI tests to drive your app to the screens you want to capture. First make sure the project has a UI Test target and that its shared scheme runs successfully in Xcode. Then configure the screenshot run and inspect the output files. A passing test is a prerequisite, not proof that every image is correct.

How do I create App Store screenshots in multiple languages?

Configure the languages for the snapshot run, then verify that the app itself launches in each intended language during the UI test. This controls the language shown in the captured interface; it does not set the App Store Connect metadata language for you. Review the output by language before uploading so you do not submit duplicate or mismatched screens.

Can fastlane snapshot run against multiple iOS simulators?

Yes. You can configure simulator targets and languages for a run, but each target must be available in the Xcode environment and supported by your project. Start with a representative simulator, then expand the list. A successful capture on one target only confirms that target; it does not establish coverage for every device size or app configuration.

Can I generate iOS store screenshots with fastlane if I don't own a Mac?

You still need access to a Mac that can run the required macOS, Xcode version, simulator runtime, and project scheme. A remote Mac can provide that environment, but first validate that your UI tests run in the remote session and that the resulting files are saved somewhere you can retrieve. Do not assume a web console alone guarantees an uninterrupted test run.

If you already have a Mac that can run your project reliably, using it avoids remote-session and file-retrieval checks. If screenshot work is occasional, a temporary environment may be enough; if you need a continuously available build machine, compare the ongoing cost and maintenance of renting with buying and operating your own Mac. Renting still requires you to validate your Xcode setup, test state, and asset review process. If you need a suitable remote environment, compare the available MacUDP rental plans against how often you capture and build before deciding.

Frequently asked questions