Change the iOS Simulator and Android Language for Screenshots, Then Translate with AI

1. Which screens need a new capture in every language?

Not every screen changes. Capture again in each language when the screen shows any of these:

If you skip a language, the store falls back. In App Store Connect, a language you add starts with the primary language's screenshots, and a shopper whose language you don't offer at all sees the next most relevant localization. On Google Play, "If you add text translations without localized graphic assets, your app's graphic assets show from the default language."

A listing can still be published with the fallback set. The cost is conversion: SplitMetrics reports that ZiMAD redesigned one game's screenshots in a Japanese style, tested them first, and saw its conversion rate in Japan rise 36% in App Store analytics afterward. That came from adapting the design, not only the words, and it is one app in one market, so if a market has the traffic, test the localized set against the fallback; our screenshot localization results include others.

Which languages should you localize first?

• Start with two or three markets that already bring impressions, installs or revenue. App Store Connect and Play Console both break their statistics down by country.
• Promote only languages the app itself supports. Apple keeps listing languages separate from the languages in your binary, so a German listing for an English-only app sets the wrong expectation.
• For listing text, Play Console has free machine translation; screenshots and the feature graphic still need localized files. To target countries rather than languages, Google recommends custom store listings.
• Measure conversion per market before adding more. The languages guide goes deeper.

2. Change the iOS Simulator language from the command line

One app: simctl launch with -AppleLanguages

Launch arguments do the same job as the App Language and App Region options in an Xcode scheme, and fastlane snapshot passes the same two before each run. They change only your app, so you can loop through languages without rebooting. Pass both: without -AppleLocale, dates and prices keep the old region.

for pair in "en en_US" "de de_DE" "ja ja_JP" "ar ar_SA"; do
  set -- $pair
  xcrun simctl launch --terminate-running-process "$UDID" com.example.app -AppleLanguages "($1)" -AppleLocale "$2"
  sleep 3
  xcrun simctl io "$UDID" screenshot --type=png "home-$1.png"
done

Your app only switches to languages it is localized for. In an Expo app, list them in the expo-localization plugin's supportedLocales; Expo's docs note that on iOS the device language "must also be one of your app's supported locales". The same capture in four languages from our test app:

The whole simulator

Launch arguments change only your app. Apple's localization testing page notes that changing the device's Language & Region changes "the entire operating system". If system screens such as the keyboard or a share sheet appear in your screenshots, switch the simulator, then shut it down and boot it again:

xcrun simctl spawn "$UDID" defaults write "Apple Global Domain" AppleLanguages -array de
xcrun simctl spawn "$UDID" defaults write "Apple Global Domain" AppleLocale -string de_DE
xcrun simctl shutdown "$UDID"
xcrun simctl boot "$UDID"

In our test the app showed German, with German dates and prices, as soon as it was relaunched, but the status bar kept the English time format (9:41) until the reboot (09:41). Apple doesn't document these defaults keys for the simulator, so check the result in a screenshot.

Check layouts before you translate

Apple's pseudolanguages show where text will break before any translation exists. Pass -NSDoubleLocalizedStrings YES to double every string, or -AppleTextDirection YES to preview a right-to-left layout. In UI tests, xcodebuild test -testLanguage de -testRegion DE runs the whole suite in one language. Android has the same idea in its pseudolocales: enable them for your debug build, then pick en-XA for longer, accented text or ar-XB for a right-to-left layout.

3. Change an app's language with adb

One app, Android 13 and later

Android 13 added per-app languages, and the locale shell command sets them. Restart the app after each change:

adb shell cmd locale set-app-locales com.example.app --locales de-DE
adb shell cmd locale get-app-locales com.example.app
adb shell am force-stop com.example.app
adb shell monkey -p com.example.app -c android.intent.category.LAUNCHER 1
adb exec-out screencap -p > home-de.png

What our emulator reported:

$ adb shell getprop ro.build.version.release
15
$ adb shell cmd locale set-app-locales com.appscreens.exposhotsdemo --locales de-DE
$ adb shell cmd locale get-app-locales com.appscreens.exposhotsdemo
Locales for com.appscreens.exposhotsdemo for user 0 are [de-DE]

# the same command before the app was installed on this emulator
$ adb shell cmd locale set-app-locales com.appscreens.exposhotsdemo --locales de-DE
Unknown package com.appscreens.exposhotsdemo for userId 0

The command doesn't require android:localeConfig in your manifest, which only controls whether people can pick your app's language in system settings. Our test app switched on its next launch in every language, and Arabic mirrored the layout. An "Unknown package" reply means the app isn't installed on that emulator; the command still exits with status 0, so check its output in scripts.

The whole emulator

Open the language settings with adb shell am start -a android.settings.LOCALE_SETTINGS and change it there. Android's docs also show setprop persist.sys.locale de-DE; stop; sleep 5; start, but that needs a root shell, and system images with the Play Store can't run adb root. Android's emulator docs point to AOSP images for that.

4. How do you automate every language?

Past three or four languages, a script per language gets slow. fastlane's snapshot runs your UI tests once per device and language and passes the same launch arguments as the loop above. After fastlane snapshot init, list the languages in the Snapfile and call snapshot() in a UI test:

# fastlane/Snapfile
devices(["iPhone 18 Pro", "iPad Pro 13-inch (M5)"])
languages(["en-US", "de-DE", "ja", "ar-SA"])
scheme("MyAppUITests")
override_status_bar(true)
clear_previous_screenshots(true)

// In your UI test's setUp()
let app = XCUIApplication()
setupSnapshot(app)
app.launch()

// Then, on each screen
snapshot("01Home")

Run fastlane snapshot from the terminal; running the test in Xcode doesn't save them. On Android, screengrab does the same with a locales([...]) list in the Screengrabfile, a LocaleTestRule class rule in your instrumented test and Screengrab.screenshot("01_home") on each screen. Check the device names against xcrun simctl list devices and do a test run with one language first.

Xcode test plans

Without fastlane, Xcode can run the same UI tests in every language from one test plan:

1. Choose Product > Test Plan > New Test Plan.
2. Under Configurations, add one configuration per language and set its Application Language and Application Region.
3. Under UI Testing, switch Localization Screenshots on.
4. Run Product > Test. Xcode saves the screenshots for each language with the test results.

Apple built this to give translators context, so treat the output as captures: they still need captions and store sizes before they're App Store screenshots. Flutter teams can do the same with golden tests, as our Flutter guide shows; that's how the Steady set near the top was made.

5. React Native, Expo, Flutter and Capacitor notes

• React Native:I18nManager.forceRTL takes effect on the next app start and is meant for development and testing. Relaunch after switching to Arabic or Hebrew.
• Expo:getLocales() from expo-localization returns the user's languages. Its config plugin takes supportedLocales and supportsRTL, which is on by default. Since SDK 58, the layout follows the device language, Expo Go included, but RTL overrides you set from code don't stick in Expo Go, which resets them. Capture store screenshots from a development or release build, the same app you ship. The Expo screenshot guide has the Release build steps.
• Flutter: set tester.platformDispatcher.localesTestValue = [Locale('de')] in an integration or widget test, or pass a locale to MaterialApp. On iOS, the supported languages also have to be added to the Xcode project. The Flutter screenshot guide covers integration_test captures.
• Capacitor and web views: the page reads the language from navigator.language. Check in a capture that it follows the launch arguments or per-app setting before you rely on it. The Capacitor screenshot guide covers the rest of the capture.

Whichever capture route you use, the captions, layout and store sizes still come after. The fastlane comparison covers when a fastlane setup pays off.

6. How do you translate App Store screenshots with AI?

CSA Research's 2020 survey of 8,709 consumers in 29 countries found that 76% prefer to buy with information in their own language and 40% never buy from websites in other languages. The localization download study collects app-specific results. Translated captions run longer, Arabic and Hebrew need a mirrored layout, and feature names should match what the localized app shows. The localization guide shows the fit checks.

Short text grows the most. The W3C's summary of IBM's guidance gives these average expansions from English into European languages, and a caption is usually short:

In the Steady set, "Keep Every Streak Going" (23 characters) became "Bleib jeden Tag dran" in German, shorter rather than longer, because the German caption was written for meaning, not word for word. Either way, check every language in a render.

With AppScreens connected to your coding agent, ask once you have the captures:

Translate the screenshots into German, Japanese and Arabic, use my localized captures for each language, and check that every caption fits on every size.

The agent confirms the languages and sizes, applies your translations or drafts them with your app's context, keeps brand and product names, places each language's captures, and renders every language so you can see the fit and the right-to-left layout. By hand, this is where the work multiplies: five screens in four languages on iPhone and Android is 40 designed screenshots, each with its own capture and caption, and a later caption change touches all of them. AppScreens keeps them in one editable project and fits each caption to every size. The free plan covers the source-language set (one project of up to five screenshots, exported and uploaded by hand); translation into 80+ languages and direct upload need a paid plan. The localization guide shows the same steps in the editor, and the screenshot prompts guide has the other prompts for the same project.

We ran that prompt on the captures from this guide. Two things needed a fix, and both only showed up in the render. The Japanese draft broke the line just before the particle を, so the second line started with it; we moved を to the end of the first line. And the template's headline font has no Japanese or Arabic letters, so those two languages fell back to a plainer system font. If the look matters, pick a font that covers every script you ship. A render shows fit, not meaning, so have a fluent speaker read the captions for your top markets before you upload.

7. Upload each language

App Store Connect has supported 50 localizations since March 2026. Add the language to the app version, then upload its screenshots in each device section: up to 10 per device size, and if the layout is the same across sizes, the highest required size is enough because App Store Connect scales it down. On Google Play, add the translation in the store listing and upload localized graphics for it, up to 8 screenshots per device type, including the feature graphic if it has text. Translations follow the shopper's language; to show a different listing by country, Google recommends custom store listings. Done by hand, that is a separate upload for every language and device size in each store. On a paid plan, AppScreens uploads the languages you choose to App Store Connect and the Google Play main listing after you approve the upload preview. To change a live version's localized screenshots without a new build, use a product page test treatment for those localizations.

Common mistakes