App Store Screenshot Localization: Plan, Produce and Ship Every Locale

Screenshots are often the first thing a shopper reads. On the App Store, Apple says (opens in a new tab) the first one to three screenshots can appear in search results when there is no app preview, and it tells developers to localize screenshots for each market they serve.

Buyers respond to their own language. In a CSA Research survey (opens in a new tab) of 8,709 consumers in 29 countries, 76% of online shoppers said they prefer to buy products with information in their native language.

Google Play works the same way in reverse. Play Console Help (opens in a new tab) explains that if you do not add localized graphic assets, your listing shows the ones from your default language.

You do not need every language on day one. Google reports (opens in a new tab) that about 80% of internet users worldwide can be reached with only 10 languages, and the App Store (opens in a new tab) is available in 175 regions and 50 languages.

1. Follow your own data. Rank countries by store impressions and installs, then localize for the languages spoken there.
2. Cover the languages your app already supports. If the app ships in Japanese, a Japanese listing with English screenshots is a mismatch shoppers will notice.
3. Consider large single-language markets next. Japanese, German, French, Korean or Portuguese (review wording for pt-BR) each serve one clear audience.
4. Plan RTL and CJK locales on purpose. Arabic, Hebrew and Chinese need extra review time, so schedule them rather than adding them at the end.

For store-specific codes such as pt-BR, es-419 or zh-TW, see App Store vs Google Play locale codes.

Caption localization translates the marketing headline around the device. In-app UI localization also translates the text inside the screenshot, such as buttons, tabs and content. Google's preview asset guidance (opens in a new tab) says in-game UI does not need to be localized for each market, but taglines and text overlays should be.

StoreLocale handles the first two in one pass, because detection finds caption and UI strings together. The caption vs in-app UI guide goes deeper on this choice.

There are 32 target languages, plus English as the source. The picker searches by English or native name.

Portuguese is one generic variant, so adjust vocabulary if you publish separate Brazil and Portugal listings. Arabic and Hebrew text is repainted where the source text sits and the UI layout is not mirrored, so read the RTL screenshot guide before shipping those locales.

One export produces a ZIP of PNGs for every selected locale and size, optionally limited to chosen slides. Folders follow the pattern platform / locale / size, with numbered files so the upload order is kept.

• App Store (iOS)/ja/iphone-6-9/01-onboarding.png
• App Store (iOS)/zh-TW/iphone-6-9/02-dashboard.png
• Google Play/de/modern-phone-android/01-onboarding.png

Folder names use StoreLocale language codes (for example pt or zh), so map them to the store code you publish under, such as pt-BR. A generate-and-export mode creates any missing localized screenshots first, and strict export skips or blocks slides that still have untranslated text.

1. Generate a Standard (1K, 1 credit) draft for every locale to check wording and fit cheaply.
2. Have a native reader check each locale in the side-by-side compare view (or on the exported PNGs) and fix strings per locale.
3. Regenerate only what changed. Screenshots with unchanged inputs are reused and not billed again.
4. Produce final assets at Pro (2K, 2 credits) or Ultra (4K, 4 credits) and export.

Once a locale is live, test it. Apple's product page optimization (opens in a new tab) lets each treatment be localized in all of your languages or just the ones you choose, and Google Play store listing experiments (opens in a new tab) can test localized screenshots in up to five languages.