DEV Community: Manuel

Why your fastlane snapshot screenshots are all in English (and how to check every language)

Manuel — Thu, 08 Oct 2026 08:17:47 +0000

Originally published on shotfleet.com.

You set languages(["en-US", "de-DE", "ja"]) in your Snapfile, ran fastlane snapshot, and opened the folders. German and Japanese are there, and every image is in English.

I build a tool in this area (shotfleet, which comes up at the end), so read this with that in mind. The five causes below need nothing from me.

How snapshot is supposed to set the language

fastlane's docs say the language reaches your UI tests "via a temporary file which is written by snapshot before running the tests". Your test target includes SnapshotHelper.swift, and the docs tell you to call setupSnapshot(app) before app.launch(). That helper reads the file and passes the language to your app as launch arguments. There is also an option, localize_simulator, that sets the Simulator's own system language.

So there are several places where the chain can break. The GitHub issues are old but show the pattern. In #8895 the Simulator language "stays en-US" after an Xcode update. In #12917 the reporter got English from fastlane snapshot while a manual Xcode run with the generated language file switched correctly. In #11457 the reporter found that localize_simulator true worked but changed the status bar because the simulator was erased. I did not reproduce any of these; they are the documented symptom, from 2017 and 2018. All three are closed.

Five things to rule out, in order

1. setupSnapshot(app) runs after app.launch(), or never. The docs say to call it before launch, in setUp(). If your test launches the app first, the language never reaches it.

2. You ran the test from Xcode. The docs say running tests in Xcode does not produce snapshots; only the fastlane snapshot command creates the language file and the folders.

3. The Simulator system language. Try localize_simulator(true) in your Snapfile. Per issue #11457 the cost is a status bar that looks different, because the simulator gets erased.

4. The app is not translated into that language. If de is in your Snapfile but your build has no German strings, iOS shows your base language and no setting will help. List what your build really ships:

ls path/to/MyApp.app | grep lproj

Compare that list with your Snapfile. The app's base language may not be listed: with a String Catalog that has no explicit English entries, my test build had de.lproj and ja.lproj and no en.lproj. A language that is in the Snapfile but not in the app can only ever produce your base language. I checked this on a small test app: with de.lproj deleted from the build, launching with German arguments showed English, and Japanese on the same build still showed Japanese.

5. The app remembers something. If your app stores its own language choice or onboarding state, a reused install can show the old language. snapshot has reinstall_app and erase_simulator for this. On a small test app that saves its own language, launching with German arguments still gave English, and uninstalling and installing the app again gave German (I did that by hand, not with snapshot's option). This and the previous cause are not documented cases from the issue threads, so test them on your app.

Then: look at every image

With 18 languages and 4 screens that is 72 images. Opening them by hand works until the day you skip one. A faster way is to compare each screenshot with the text your app really contains.

Then: check the folder you already have

shotfleet's check command does that, and it is free: no licence, no account. It does not capture anything and does not touch your fastlane folders. It runs on a Mac and reads each image with the text recognition built into macOS. Give it a simulator build of your app, so it knows your real strings:

xcodebuild -scheme MyApp -sdk iphonesimulator -configuration Debug \
  -derivedDataPath build build

shotfleet check fastlane/ \
  --app build/Build/Products/Debug-iphonesimulator/MyApp.app

For an Android folder, pass the APK instead: --app path/to/app-release.apk.

It reads each image and tells you:

Wrong language: the de-DE folder shows English strings.
Copies: the same image in two languages.
Missing: a language that did not produce every screenshot.
Store rules: sizes, counts and transparency that App Store Connect or Play would reject.
A listing in a language the app does not have: for example Traditional Chinese screenshots when the app has no Traditional Chinese.

The report (check.json and an index.html grid with a row per language and a column per screen, problems outlined in red) goes to ./shotfleet-check.

On the committed fastlane screenshots of my own workout app (252 iOS images) it found one real problem: Traditional Chinese listings with Chinese captions over an app that was still in English. When I planted mistakes in a copy of a clean set (a German screen in English, a Korean screen in Japanese, two copied images), each one was reported. On 220 screenshots of another of my apps (20 languages) a check took 57 to 86 seconds once macOS text recognition was warm. The first check after a restart or a macOS update is slower, because macOS compiles its text-recognition model; that can take minutes, and once took about 40 minutes.

Pass --app. Without it check falls back to language detection, which cannot judge short screens.

What this does not tell you

If check says "macOS text recognition didn't answer in time" (or "isn't answering"), macOS is usually still compiling its text-reading model, which can take minutes on a busy Mac the first time (once about 40 minutes on a quiet one). check doesn't fail over it: it finishes and marks the screens it couldn't read as "not verified". Run it again later, or install Tesseract (brew install tesseract tesseract-lang) and check uses it automatically. No restart needed.
It says the language is wrong. It does not say why. Go back to the five causes.
macOS text recognition reads 33 languages on macOS 27 (older versions read fewer). For other scripts (Greek, Hebrew, most Indic scripts) check still catches other-language screens, copies and missing screens, and says which screens it could not read. With Tesseract installed, check uses it for those scripts by itself: in my test, 84 of 85 languages could then be read, against 66 without it.
Copies are only reported on screens with enough text. Two near-empty screens that are identical can pass.
It is only as good as your simulator build matching the build that made the screenshots.

When not to use shotfleet

If your screenshots are already right in every language, you do not need it. If you have only two or three languages, looking at the images yourself is fine. If you already have a maintained UI-test suite and snapshot works for you, keep snapshot; it is free and check can sit next to it. If you would rather capture with Maestro, one Maestro flow in every language shows how, without shotfleet. The tool only runs on an Apple silicon Mac (the installer refuses Intel), and capturing with shotfleet run is a separate step with its own requirements (Xcode, the Android SDK for Android, Maestro 2.x, Java 17+, and a Maestro flow you write). It does not make frames or captions and does not upload to the stores. I also have no data yet on how often modern fastlane versions hit the problem in this article; the issue threads are old.

Where to go from here

If check finds wrong-language images and you would rather not maintain per-language UI tests at all, shotfleet also captures: one English Maestro flow, every language your app ships, on iOS and Android. run needs Maestro, Java and a flow; on iOS, your own XCUITest or SnapshotHelper tests work instead (new in 0.1.6). run is free for up to 2 languages. A licence unlocks every language and export: $29 for the first 100 buyers, then $49 once, with a year of updates and a 14-day refund. Details at shotfleet.com/#price.

The free part is the check command above. Install it, point it at your fastlane/ folder and read the grid.

Disclosure: I made shotfleet and it is paid software. The check command and 2 languages per run are free; the full version is $29 for the first 100 buyers, then $49 once. The five causes above need nothing from me.

Run one Maestro flow in every language: iOS launch arguments, Android per-app locales, and the traps

Manuel — Wed, 07 Oct 2026 12:54:42 +0000

Originally published on shotfleet.com.

You wrote a Maestro flow for your app and now want the same screens in German, Japanese and Arabic, for screenshots or for a smoke test. The docs are short on this, and the failure mode is quiet: every run goes green and the images are in English.

I build a tool around this problem (shotfleet, which comes up in the last three sections). Everything before that is plain Maestro and adb.

What the docs say

Maestro's locale page says there is "no place within a Flow itself" (a launchApp or config.yaml) to define the locale. The documented route is the --device-locale flag on maestro start-device (and maestro cloud), not on maestro test, combined with tags:

maestro start-device --platform android --device-locale fr_FR
maestro test --include-tags french .maestro/

That works, and it changes the whole device. For N languages you start N devices in turn, or restart one. It also means the language lives in your shell script and tags, not in the flow.

A per-app alternative: no device change

You can also set the language for your app only, and keep the device as it is.

iOS: launch arguments

launchApp takes an arguments map of key-value pairs that are passed to the app as launch arguments. iOS reads AppleLanguages and AppleLocale from them, so one flow can take the language as a variable:

# flow.yaml  (no env: default in the header, see trap 1)
appId: com.example.myapp
---
- launchApp:
    clearState: true
    arguments:
      AppleLanguages: "(${APP_LANG})"
      AppleLocale: "${APP_LOCALE}"
- tapOn:
    id: onboarding_next
- takeScreenshot: shots/${APP_LANG}/02_onboarding

I ran this on Maestro 2.0.10 against an iOS 26.4 simulator. The tapOn before the screenshot matters: when I put a takeScreenshot straight after launchApp, the image showed the iOS home screen, not the app, in 4 of 4 runs (with and without clearState; the Mac was under heavy load at the time). Putting extendedWaitUntil with visible: id: next first gave the app. Wait for something on screen before the first screenshot.

Everything here was run on Maestro 2.0.10 only. Newer versions can differ: where takeScreenshot writes is one thing to check on yours.

Run it once per language, with the variables after test:

for pair in en:en_US de:de_DE ja:ja_JP; do
  maestro --device "$UDID" test \
    -e APP_LANG="${pair%%:*}" -e APP_LOCALE="${pair##*:}" flow.yaml
done

Android: per-app locales (Android 13, API 33 and up)

Android 13 added per-app language preferences. From the outside you set one with a shell command, before the flow starts:

adb -s emulator-5554 shell pm clear com.example.myapp
adb -s emulator-5554 shell cmd locale set-app-locales com.example.myapp --locales de

Then run the same flow without clearState, because of trap 3. To keep one file for both platforms, put the iOS launchApp in a runFlow with when: platform: iOS and the Android one in when: platform: Android.

The selectors

A flow that says tapOn: "Next" fails in German. Two ways out: tap by id: (accessibility identifier on iOS, resource id on Android), which does not change with the language, or write the translated text per language. If your app has ids on everything you tap, you are done and need nothing else in this article.

Four traps that give you English by mistake

1. A default in the flow header beats the command line. One developer documented this with Maestro 2.10, and I reproduced it on 2.0.10 on iOS: the flow had env: { LOCALE: en } as a default, and every "Portuguese" and "Spanish" run still came out in English. He fixed it by removing the default from the header, and he caught it only by looking at the images (PR #216). Maestro's parameters page says that constants defined in a subflow override same-name parameters from the parent. In my run the file even landed in the en folder although I passed -e APP_LANG=de. Do not put a default for the language in the header. Pass the language only with -e, and look at the first image of each run.

2. -e goes after test. In the same PR the iOS script put -e before test, and it failed while looking like it passed. On Maestro 2.0.10 I got Unknown options: '-e', 'APP_LANG=de', the usage text and exit code 2, so it only looks like a pass if your script ignores the exit code. The order is maestro --device X test -e KEY=VALUE flow.yaml.

3. On Android, clearing state clears the language. clearState wipes the app's data, and the per-app language goes with it. Clear first with pm clear, set the language, then launch without clearState. Otherwise you get the system language back.

4. Parallel runs on Android. Two separate maestro test processes on two devices on one Mac were unreliable for me on Maestro 2.0.10. With two emulators and two maestro test processes started together, one of the two failed in both attempts (a TimeoutException, or an exception on Maestro's own log folder), while each passed alone. A Maestro process listened on TCP 7001 while it ran, which is my guess for the shared resource; I did not prove it. Run one device at a time, or use one run that shards across devices (--shard-split, which I did not test), and check the images of both devices.

Two smaller ones. System permission dialogs are drawn by the OS in the device language, which stays English while your app is German (I measured this on iOS 26.4 with Maps launched in German; I did not test Android), so write those taps in English. launchApp also takes a permissions setting (see its docs page); I did not test it against a permission dialog. And long languages push buttons off the screen: use scrollUntilVisible before the tap, with direction: DOWN (it happened to me: a Next button nobody could reach in four languages).

Read the images, not the exit code

All four traps pass. The only way to catch them is to look at the output, or to have something look for you: shotfleet check shots/ --app path/to/MyApp.app reads each image back and reports wrong-language and duplicate images. It is free (no licence, no account) and works on any folder of screenshots, fastlane's too (how to check a fastlane snapshot folder).

Where shotfleet fits

Doing all of the above by hand for 18 languages on two platforms is a lot of scripting, and that is the work shotfleet does. It reads the translations compiled into your build and rewrites every text selector in your English flow for each language, so tapOn: "Next" becomes Weiter in German, or (Nächste|Weiter) if your app has two translations for it. It runs the languages in parallel on simulators and emulators and checks each image. On my own app, 18 languages by 4 screens (72 screenshots) took 9 minutes on iOS (four simulators in parallel) and 15 on Android, on one Mac. That is one app and Maestro 2.0.10, so treat it as a data point. run is free for 2 languages; a licence unlocks every language and export: $29 for the first 100 buyers, then $49 once, with a year of updates and a 14-day refund.

When not to use shotfleet

If your app has ids on everything you tap, three or four languages, and one platform, the loop above is enough. If you test on real devices or in a device cloud, shotfleet does not help; it runs simulators and emulators on your Mac. It needs an Apple silicon Mac, Maestro 2.x and Java 17+, and Android needs API 33+ emulators. It makes no frames or captions and does not upload to the stores. For Flutter and React Native it works from your translation files. I have run that end to end on one real Flutter app (wger) and one real Expo app (the obytes template), on iOS and Android, and not yet on any other.

Disclosure: I made shotfleet and it is paid software. The check command and 2 languages per run are free; the full version is $29 for the first 100 buyers, then $49 once. Everything in the guide above works without it.