Adding localization is two jobs, and screenshots per language is not one of them.

What does Expo give you for reading the device language?

One function, and more information than most people expect from it. Install expo-localization, call getLocales(), and you get back a list of the user's locales in the order they have set in device settings. Expo guarantees the list has at least one entry, so there is no empty case to guard. Each entry holds the language tag, the bare language code, the text direction, the decimal separator, the digit grouping separator, the region code, the currency code and symbol and the measurement system. There is a useLocales() hook as well, which rerenders when the operating system settings change.

Expo's guide pairs it with i18n-js for the translations themselves and shows the whole setup in about ten lines: a key value object per language, then one assignment that sets the locale from the first entry of getLocales(). Turning on enableFallback lets you define a string once in your default language and reuse it everywhere it is missing, which is how you avoid translating proper nouns forty times. The guide also names Lingui, fbtee, React i18next and Intlayer as alternatives, and tells you not to hand roll date and number formatting at all. If your app runs Hermes, theIntl API is available on every platform, and passing default as the locale string makes it use the device locale without askingexpo-localization first.

The platform difference is the thing to design around. On Android somebody can change their locale preferences in Settings without your app restarting, so Expo tells you to rerun getLocales() each time the app comes back to the foreground, using the AppState API to notice. On iOS the app resets when the device language changes, so setting the locale once at startup is enough. Build for the Android behaviour and the iOS case is covered for free. One caution from reading both Expo pages on 22 October 2026: the guide says there is still no way to read temperature units from user preferences, while the expo-localization API reference lists a temperatureUnit field on the locale object. Those two pages disagree, so test it on a real device before you rely on it.

Two more config plugin options matter and both change the binary.supportedLocales declares the languages your app supports so that iOS and Android show it in their per-app language picker, which means you usually do not have to build a language switcher of your own. Right to left support is on by default from SDK 58 and follows React Native's I18nManager, with supportsRTL to opt out andforcesRTL to force it for testing. On iOS the device language also has to be one of the locales you declared for right to left to kick in. The pass over your layouts that gets right to left correct is the same pass that fixes add accessibility, so it is worth doing them together.

Expo, Localization guide, last modified 7 September 2026, read 22 October 2026

How do you translate the app name and the permission prompts?

Not in your JavaScript, because the system reads both before your code runs. The name under the icon and the sentence inside a permission sheet are native resources. Expo handles them with thelocales field in the app config. Setios.infoPlist.CFBundleAllowMixedLocalizations to true, then map each language identifier to a JSON file. The identifier is a two letter language code with an optional region, like en-US oren-GB. Inside each file the keys sit under ios and android, soCFBundleDisplayName and app_name carry the translated name and the usage description keys carry the translated prompts.

Expo's app config reference describes locales as providing per-locale values for system dialog prompts such as permission boxes, and as creating a Localizable.strings file for things like push notifications. During prebuild Expo writes the values from each locale file into InfoPlist.strings for the matching locale. If a config plugin has already set a default usage description for you, adding the matching key to the ios object in a locale file is what replaces it with a translated one. From SDK 55 there is also an iOS only Localizable.strings object inside the locale file, whose entries become native localization files you can reference from localized remote notification alerts.

Keep the two names straight, because they are set in different systems and nobody tells you when they drift. The name inCFBundleDisplayName is what sits under the icon on the home screen. The name on the App Store product page is a separate field in App Store Connect, localized separately. An app can ship with a Japanese home screen name and an English product page, and the only person who notices is a Japanese customer deciding whether to tap install.

One habit saves rework here. Route every string through the lookup from the first screen, including the ones that do not feel like copy: empty states, error messages, the label on a sheet, the title on a add pull to refresh control. Retrofitting those later is slower than writing them that way, and they are the strings a reviewer in another language will find first.

Expo, Localization guide, translating app metadata, read 22 October 2026

What does App Store Connect require to list an app in another language?

A language, a description and a set of keywords. That is the honest short answer, and it is shorter than most people expect. You add languages on the App Information page once the app record exists. Apple's help says you can manage languages only while the app status is editable, and names the required role as Account Holder, Admin, App Manager or Marketing. The click path is the primary language control at the top right, then the Not Localized section of that menu, then the add button that appears beside a language when you hold the pointer over it.

The fields sit at two levels and the split confuses people. App Information holds what is shared across every platform you have added, and that is where you enter the app name and the privacy policy URL for each language. The platform version page holds the per version fields, which is where the description, the keywords, the promotional text, what is new in this version, the screenshots and the previews live. Apple's reference page on platform version information marks the description, the keywords and the support URL as required and localizable, and the marketing URL as localizable without being required. The description is capped at 4000 characters of plain text with no HTML. Keywords are capped at 100 bytes of content in total, each keyword has to be longer than two characters, and names of other apps or companies are not allowed. Promotional text runs to 170 characters and changes without a new submission, which makes it the one piece of store copy you can fix on a Friday.

Picking the languages is worth ten minutes with Apple's App Store localizations reference, which lists fifty languages and locales for metadata and then maps every country and region to a default language plus any additional ones the store supports there. Counted on 22 October 2026, the United States defaults to English (US) and additionally supports Arabic, Chinese (Simplified), Chinese (Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico) and Vietnamese. India defaults to English (U.K.) and supports eleven more on top. A language you add reaches further than the country you had in mind: Apple says a French localization shows to anyone whose language setting is French, and also in countries where the store supports French but not your primary language, and your French keywords become searchable in every country where the store supports French. Where nothing matches, the next most relevant localization is used, and failing that your primary language. Delete a language later and those countries quietly revert to the primary language text.

Apple, App Store Connect Help, Localize app information, read 22 October 2026

Are localized screenshots required or optional?

Optional. Screenshots themselves are required, a localized set is not, and conflating those two is the single most expensive mistake on this page. Apple's screenshot specifications reference says you must include at least one screenshot and may upload up to ten per device size, as .jpeg, .jpg or .png. To submit at all you need at least one screenshot for iPhone with Dynamic Island at the medium display size, plus at least one for the iPad 13 inch display if your app supports iPadOS. Read on 22 October 2026.

The same page then answers the language question directly, under Display scaling. If your interface is consistent across multiple device sizes and localizations, you only need to provide screenshots for the highest required resolution and App Store Connect scales them down for the smaller sizes. If you would rather not use scaled screenshots, you can upload specific screenshots and previews tailored to each device size and localization. The help page on adding a language puts it more plainly still: when you add a language, the screenshots and the properties for the new language default to those of the primary language, except for the description and the keywords.

So the instruction is narrow. Write a description and keywords for every language you add. Produce a localized screenshot set only when the screenshots carry text, because a German customer reading English captions over German UI is the case worth spending money on. App previews follow the same logic and are optional: up to three per localization per device size, and Apple says a language with no preview falls back to the preview in the next best available language. Media Manager is where you manage preview and screenshot placements for each supported device size and localization once you do decide to split them.

There is exactly one case where a localized screenshot set stops being optional, and it catches people a year later. Changing your primary language. Apple's help says a language can become the new primary language only if you have already added it to a previous version, App Review has approved it, and you have uploaded and had App Review approve screenshots in that language for all supported platforms at sizes matching your current primary language. If that localization's screenshots were derived from another one, you have to upload new matching screenshots, get a version approved, and change the primary language on a later update. A custom product page needs screenshots in the language too. If you think a market might become your main market, give it real screenshots early.

Newly is an AI app builder for the first half of this job. You describe the app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, soexpo-localization, the translation library and the locales block in the app config are all yours to edit. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month, with no free tier. It does not press submit on the App Store for you, because Apple requires the content owner to submit, so the language, the description and the submission stay in your hands. The mechanics of that step are in publish to app store.

Apple, App Store Connect Help, add a language and change the primary language, read 22 October 2026