iOS Multi-locale Screenshot Automation on a Cloud Mac mini

Teams shipping apps overseas almost always hit the same wall the first time they upload assets to App Store Connect: fourteen locales × six screenshots × three device sizes, nearly three hundred images. Have an ops person tap through this by hand and you burn an entire day — and still risk leaving the status bar clock unedited on half the shots. This kind of repetitive, GUI-bound work is exactly what a dedicated macOS box should be doing in the background, instead of tying up the one MacBook the team actually has.

Why run it on a cloud Mac mini

Running screenshot automation on a local laptop has two structural problems. First, spinning up four or five simulators at once spins the fans up and locks the screen — you can't do anything else on that machine while it runs. Second, the local environment tends to drift from the release branch, so the build you're screenshotting isn't always the exact build going to review. Moving this whole pipeline onto a dedicated physical Mac mini node fixes both cleanly:

• Launch as many simulators as you need without touching your own dev machine;
• Pin a specific branch and Xcode version just for asset generation, fully decoupled from your build environment;
• Sync the output directory back over SSH once the job finishes — no need to babysit the machine.

Screenshot automation is fundamentally "run a UI test and grab a screenshot along the way," so the app has to be drivable by UI tests all the way to the target screen. Forced logins, verification codes, and other gated flows need a test-environment toggle set up ahead of time.

Building the pipeline with fastlane snapshot

Start by initializing snapshot in your project, which generates SnapshotHelper.swift and a Snapfile:

cd MyApp
fastlane snapshot init

The Snapfile is the config hub for the whole pipeline — locales, device list, and output directory all live here so you're not passing arguments by hand every run:

devices([
  "iPhone 16",
  "iPhone 16 Pro Max",
  "iPad Pro (12.9-inch)"
])

languages([
  "zh-Hans", "zh-Hant", "en-US", "ja",
  "ko", "de-DE", "fr-FR", "es-ES",
  "pt-BR", "ru", "it", "id",
  "th", "vi"
])

scheme("MyAppUITests")
output_directory("./screenshots")
clear_previous_screenshots(true)
override_status_bar(true)
concurrent_simulators(true)

In the UI test itself you only need one call to the screenshot function on the target screen — no locale-switching logic required, since fastlane iterates the languages array automatically:

func testHomeScreenshot() {
    let app = XCUIApplication()
    app.launch()
    snapshot("01Home")
}

Simulator concurrency and resource limits

With concurrent_simulators(true) enabled, fastlane spins up one simulator instance per device automatically. But "able to launch" isn't the same as "should run this many at once" — memory is the real constraint. Here's what that looks like on two common cloud Mac mini tiers:

Push past the recommended count and memory pressure forces the OS to swap simulator processes to disk — screenshot jobs start queuing instead of running in parallel, and you'll see the occasional locale fail and need a rerun. The safe move is to check how many simulators are already booted with xcrun simctl list devices, and batch the run if you're over the threshold:

xcrun simctl list devices booted
fastlane snapshot --devices "iPhone 16" --languages "zh-Hans,ja,ko"
fastlane snapshot --devices "iPhone 16" --languages "en-US,de-DE,fr-FR"

Naming convention and framing with frameit

A full run leaves you with hundreds of images, and inconsistent naming is where most mistakes happen when uploading to App Store Connect later. Keep the output directory in the three-level structure locale-code/device-name/index-screen-name.png, matching Snapfile's default behavior — don't layer your own naming scheme on top of it.

If you need device-framed screenshots for marketing pages (as opposed to the App Store listing itself, which doesn't need frames), use frameit:

fastlane frameit

It reads the screenshot metadata, matches the right device frame automatically, and batch-outputs everything into screenshots/framed — no manual alignment in Photoshop required.

Common pitfalls and how to debug them

• Inconsistent status bar: Forgetting override_status_bar(true) leaves the time, battery, and signal bars different across screenshots — an easy tell for reviewers that these were casually captured on a real device.
• Missing system fonts breaking layout: Some locales (Thai, Arabic) render with abnormal line heights on older iOS simulator runtimes. Upgrading to the simulator runtime bundled with the latest Xcode usually fixes this.
• Leftover keyboard language: If your UI tests touch text fields, clear the simulator's keyboard settings before the run — otherwise some locale screenshots will show the previous session's leftover input panel.
• Simulator state not reset: Between runs, xcrun simctl erase all is worth running to wipe all simulator data, so login sessions or cached content don't bleed into the next locale's screenshots.

CI integration: scheduled incremental generation

You don't need a full re-shoot on every release — only screens with actual UI changes need updated screenshots. The approach: run a scheduled job on your cloud Mac mini that diffs the affected screens in Git and reruns only the corresponding UI test cases:

git diff --name-only HEAD~1 HEAD | grep "Screens/" > changed_screens.txt

Wire this into GitHub Actions with a self-hosted runner so it triggers incremental screenshotting automatically when a PR merges into the release branch, with a human sign-off before the final upload. Running the whole pipeline on a dedicated physical node means it never competes with the rest of the team's build jobs for resources, and you're not tying up a dev machine just to generate screenshots.

Frequently asked questions