How to Automatically Generate Multilingual Screenshots with fastlane snapshot? 2026 Tutorial

fastlane’s documented screenshot workflow uses UI tests to capture app screens across languages and devices. Apple documents localization testing and App Store screenshot requirements separately.

Symptom: screenshots are missing, inconsistent, or saved without a reliable way to check which language they show.
Fastest fix: pin the language, simulator target, test data, and output directory; run a small test matrix first, then inspect each image before treating it as a store asset.

Use fastlane snapshot with Xcode UI tests to generate multilingual screenshots. But treat generation, image review, specification checks, and App Store Connect upload as separate gates. A successful capture does not confirm that an image meets current submission requirements or has been uploaded.

This guide is for:

• Solo developers who want to replace repetitive screenshots after each update.
• Localization owners who need to regenerate and review images for different markets.
• Small teams running screenshot jobs on a remote Mac and needing logs and output they can check later.

SECTION 01How do you automate multilingual screenshots with fastlane snapshot?

Start by making the test reach the intended screen reliably in one language and on one simulator. Then add languages and device targets deliberately. The fastlane snapshot guide describes a workflow built around UI tests, configured languages, devices, and screenshot output. It does not guarantee that every project or simulator target will work without adjustment.

Keep these concerns separate:

• UI test screenshots are evidence captured while your test runs through the app.
• Store screenshots are selected, reviewed images prepared for submission.
• Screenshot naming helps you identify the intended language and device, but does not prove that the image contains the correct localized UI.
• Upload status is a separate check in App Store Connect.

That distinction prevents a common handoff error: a test can finish and create image files while the wrong screen, language, or app state appears in them.

How does fastlane snapshot generate screenshots for different languages?

Configure the languages you intend to test, and make the UI test launch into the localized interface for each run. Apple’s guide to testing localizations when running your app explains how to run an app with localization settings. Use that guidance to verify what the test actually launches, rather than assuming a language label in a filename means the app displayed that language.

A simplified Snapfile might look like this:

languages(["en-US", "fr-FR"])
devices(ENV.fetch("SNAPSHOT_DEVICES").split(","))
scheme("AppUITests")
output_directory("./artifacts/app-store-screenshots")

Treat this as a starting point, not a drop-in file for every project. Use device identifiers and scheme names that are valid in your environment, and check the installed fastlane action documentation for supported options. Keep the output directory explicit so your local scripts or CI job can collect the same path each run.

Before expanding the language list, confirm that the test can reach the screen you want and that the app’s state is predictable. Then add a language and inspect the resulting image. Look for untranslated labels, clipped buttons, wrong currency or date presentation, and content that depends on a previous run.

A localized run can pass while showing the wrong content. Validate the visible screen itself; don’t use a language-specific filename as proof.

How do you know the screenshots are complete and where they are saved?

Set output_directory explicitly, then make the test job preserve that directory as an artifact. If the run happens on a remote Mac, make sure the output remains accessible after the session ends. A path that exists only inside a temporary workspace is not a dependable delivery location.

Check completeness against the matrix you intended to run:

• Did every configured language produce the expected image set?
• Did the test reach the capture point, or did it stop earlier?
• Are there duplicate, blank, or unexpectedly small files?
• Does each image show the expected language, screen, and app state?
• Do the test results and logs explain any missing capture?

Keep test status, image presence, and image quality as separate checks. A failed test may still leave partial output. A passing test may create images that need editing or rejection. A missing image needs a different investigation from an image that exists but shows the wrong screen.

For reliable handoff, store the test result bundle or logs beside the image artifacts. Record the commit or build being tested, the configured languages, and the simulator targets. That information helps you compare a later run with the intended configuration instead of guessing from a folder of files.

SECTION 02Choose a screenshot matrix that matches your role

A larger matrix is not automatically better. Add targets when they cover a real platform, layout difference, or store requirement. Otherwise, every extra run creates more output to inspect and more opportunities for environment-specific failures.

For a solo developer maintaining a single-language app

Keep the first run small. Select one UI test, one language, and a simulator that represents the screen you need to capture. Confirm that the test reaches the correct view and that the screenshot is readable before adding more targets.

This catches setup problems early: the scheme might not include the UI test target, the app may require a login state, or a permission dialog may interrupt the flow. If you build out a broad matrix before fixing those issues, you’ll have more failed runs and more output to sort through without learning whether the basic capture path works.

When the core flow is stable, add only the device coverage your app and store delivery actually need. Retest after changes to navigation, onboarding, or test data; these are frequent sources of screenshots that still generate but no longer tell the right product story.

For developers responsible for localization

List the languages and regions that your app truly supports, then test each configured localization under controlled conditions. The language shown in a screenshot may affect more than translated labels: date formats, numbers, currency, right-to-left layout, and the amount of space text occupies can change the screen.

Use the app’s normal localization mechanism, and ensure the UI test launches into the expected language and region. Apple’s localization screenshot guidance describes using screenshots to review localized interfaces. Apply the same discipline to automated output: inspect the image, not just the run configuration.

Avoid brittle tests that depend on text in only one language. Where the UI test needs to find a control, use stable accessibility identifiers when appropriate, and keep assertions meaningful across localizations. A test that searches for a translated label can become fragile when copy changes, even if the screen layout remains correct.

For every market you intend to cover, review the screenshot for truncation and visual balance. Automated generation can produce a consistent file set; it cannot decide whether a translation is accurate or whether a localized screen communicates the feature clearly.

For teams covering multiple simulator devices

Choose simulator targets based on supported platforms, meaningful layout differences, and the asset requirements you need to satisfy. Apple’s documentation on running an app on simulated or physical devices explains the role of simulated devices. The important operational point is that a configured target must also be available in the environment where the test runs.

Do not treat device coverage and store specification checks as the same task. A screenshot captured on a simulator may show the right layout but still require a separate check against the current requirements for its intended destination. Apple organizes its App Store Connect screenshot specifications by device type. Check the current requirements for the asset you plan to submit rather than approving every image against one assumed size.

A practical selection rule:

• If a target represents a supported platform or a layout that materially changes, include it in the test matrix.
• If it adds no meaningful coverage, leave it out until a release requirement justifies the extra review.
• If the target is configured but unavailable on the build Mac, install or select an available target before treating the run as a valid matrix test.

SECTION 03Keep UI tests and remote runs diagnosable

For developers maintaining screenshot stability

A screenshot test is sensitive to timing and app state. Network-backed screens may load at different speeds; animations can capture an in-between frame; changing test data can alter text, images, and layout. Make the test wait for a stable, visible condition instead of relying on arbitrary pauses wherever possible.

Use predictable test data and control the steps that lead to the capture point. If the screen depends on an account, server response, or permission state, define how that state is prepared and reset. Otherwise, a rerun may reach a different screen even though the test code has not changed.

Apple’s test plan organization guidance can help you separate test configurations and improve feedback. Keep localization and screenshot-related runs understandable to whoever needs to investigate them. When a run fails, preserve its result bundle, logs, and any images created before failure.

Classify failures instead of recording only “snapshot failed”:

• Test did not complete: inspect the test result and logs for the interruption.
• Capture is missing: check whether the test reached the capture call and whether the output path was collected.
• Image exists but is wrong: review language, app state, timing, and the displayed screen.
• Image looks right but is not ready for delivery: run the separate asset and specification checks.

This classification shortens the next debugging step. It also prevents teams from fixing a file-export issue by changing UI test logic, or changing a test when the actual problem is an incorrect output collection path.

For small teams running on a remote Mac

A remote Mac can run Xcode UI tests, but that does not mean the required simulator target is already installed or that a job will succeed unattended. Pin the project revision and toolchain choice used by the job, verify the intended simulator targets on that machine, and make the output and logs retrievable after the session.

Before scheduling repeated runs, walk through these checks:

• Confirm the project and UI test scheme build in the intended environment.
• Confirm that each selected simulator target is available to that environment.
• Run the smallest useful language and device matrix first.
• Verify that tests reach the intended screen and produce readable images.
• Preserve test results, logs, and the configured screenshot output directory.
• Review the collected files after the session, not only the console’s final status.

Apple documents uploading screenshots and app previews as a separate App Store Connect task. That separation matters on a remote machine: a test job can capture images without uploading them, and an upload attempt still requires a check in the destination workflow.

If your main machine is short on disk space or cannot run Xcode, a hosted Mac may be useful for a repeatable screenshot job. Review the environment and access details before depending on it; you can compare MACNOX plan options against your test cadence and the simulator targets you need. A remote environment is not a substitute for reviewing generated assets or confirming upload status.

SECTION 04Deliver assets in separate acceptance steps

Treat screenshot delivery as a handoff, not a single command. First confirm the UI test completed and that the expected files exist. Then inspect each image for language, screen content, clipping, and stable app state. Next, check the current asset requirements for the intended device class. Finally, upload the approved files and verify their status in App Store Connect.

Apple provides a screenshot resource in the App Store Connect API, but the existence of an API does not change the acceptance sequence: generated files still need review, and an upload operation still needs confirmation. Keep upload automation separate from screenshot generation so a capture failure cannot be mistaken for a publishing result.

The trade-off is straightforward. Manual capture gives you direct control, but repeated setup, shared local resources, and inconsistent file handling can slow a small team down. Running tests on an existing Mac avoids adding a separate machine, but it may compete with local development and requires you to maintain the simulator environment yourself. If neither option suits occasional or unattended capture, a remote Mac gives you a dedicated environment to evaluate without buying hardware; it still needs pinned project inputs, available simulator targets, saved logs, and human asset review.

If you need to test that workflow on a hosted machine, review MACNOX remote Mac options and confirm that the access method and environment fit your project. Keep the decision tied to your actual screenshot matrix: rent for a temporary or scheduled test environment, use a local Mac when you need persistent hardware or direct physical-device access, and don’t treat either choice as proof that screenshots have passed review or been accepted by App Store Connect.

SECTION 05Further Reading

• Check whether a remote Mac can run iOS Simulator and UI automation reliably.
• Set up a GitLab CI pipeline for repeatable iOS builds on a remote Mac.