Mobile app localization, from the listing to the last string.
Mobile app localization is the work of making an app read and behave as native in another language and market: the store listing people find, the strings inside the app, and the dates, numbers, currencies and layout direction that quietly break when they are assumed. It gets treated as a translation job. On the two stores it is really three jobs, and the first of them, the localized listing, is the part of app store optimization most apps never touch: every language gets its own keywords, description and screenshots, and Apple and Google each have rules for what happens in the languages you skip.
This guide sets out what Apple and Google actually require for a localized store listing, checked against their own documentation in September 2026, what has to change inside the app itself, and how to choose the languages that matter first. It ends with a planner built from Apple's storefront table and a checklist to run before you submit.
See the three layers of localizationThe short version
Three layers, and the stores only see one.
A localized listing on the App Store or Google Play, the strings and formats inside the app, and the market around it: pricing, payments, legal text and support. Apple lists 50 languages and locales for App Store metadata; Google Play lists 86 for your own listing translations. Skip the listing and the stores fall back for you: Apple shows your primary language, Google offers an automatic translation with a notice on top. Skip the app itself and the listing promises something the user cannot read once it opens.
What it covers
What mobile app localization actually covers.
Translation is the visible part. The three layers below are what a market actually experiences, and they are owned by different people: the listing by whoever runs the store account, the app by whoever builds it, the market by whoever is accountable for revenue there.
The store listing
Name, subtitle or short description, description, keywords, screenshots and previews, in each language you add. This is the layer that decides whether anyone in that market finds the app at all.
Editable metadata. No new build needed.
The app itself
Every string out of the code and into resource files, dates, numbers, currency and plurals formatted from the locale, permission dialogs in the user's language, and a layout that mirrors for Arabic and Hebrew.
Compiled into the binary. A new build, and a new review.
The market
Prices in the local currency, the payment methods people there actually use, terms and privacy text that hold up locally, and someone who can answer a support email in that language.
Decisions, not files. The stores never see this layer.
The engineering that makes the second layer possible has its own name, internationalization: strings kept in resource files instead of the code, formatting taken from the locale, layouts that can mirror, a build that can carry more than one language. Localization is what you produce on top of it, one language at a time. An app that was never internationalized has to be reworked before the first translation is worth paying for, which is why the checklist further down puts that step before any translator is hired.
The same discipline applies to the web pages that send people to the store. Newly's own APK builder page, for example, is published in nine languages including Arabic, German and Portuguese, each version carrying hreflang links to every other version and an x-default pointing at the English page, so search engines know which one to show for which language. A store listing needs the same shape: one version per language, and the store told which is which.
App Store
What Apple requires for a localized App Store listing.
Apple's rules live in App Store Connect Help, and three of them shape every localization plan: how the primary language falls back, what each localizable field may hold, and where localized keywords are actually searched.
One primary language, and a defined fallback everywhere else
The primary language is the metadata everyone sees where you have not localized. Apple's own example: if English is the primary language and the only one you provide, "your app metadata will appear in English in all App Store countries or regions." Add French, and the French localization shows to users whose language setting is French, and also in countries where the App Store supports French but not English. "If no localization matches a user's language setting, the next most relevant localization is used." Nothing goes blank; it goes to a language the user did not pick.
Two mechanics matter when you add a language. First, "screenshots and the properties for the new language default to those of the primary language, except for the description and keywords," so a half-finished localization ships English screenshots under a French description unless you replace them. Second, languages can only be managed while the app status is editable, and a new language gets its approval by going out with a version, so it lands with a release, not between releases. Delete a language later and the countries that showed it revert to the primary language. Read Apple's localization help page.
The localizable fields and their limits
| Field | Limit | Status |
|---|---|---|
| Name | 2 to 30 characters | Localizable, required |
| Subtitle | 30 characters | Localizable |
| Promotional text | 170 characters | Localizable, editable without a new version |
| Description | 4,000 characters, plain text | Localizable, required |
| Keywords | 100 bytes per localization | Localizable, required |
| What's New in this Version | 4,000 characters | Localizable, required from the second version |
| Support, marketing and privacy policy URLs | Full URL with protocol | Localizable; support and privacy policy URLs required |
| Screenshots | Per device size; must be approved at the current primary language's sizes before that language can become primary | Localizable, required |
| App previews | Up to three per localization, per device size | Localizable |
Limits from the platform version and app information references in App Store Connect Help, checked September 2026. Keywords are counted in bytes, not characters, which matters for scripts where a single character takes more than one byte.
Localized keywords are searchable wherever the language is supported
This is where localization and ASO meet. Apple, on the same page: "Users can search for your app using localized keywords in all countries or regions where the App Store supports French." Which countries support which languages is a published table. The United States storefront defaults to English (U.S.) and lists Arabic, Chinese (Simplified), Chinese (Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico) and Vietnamese as supported languages. A Spanish (Mexico) localization therefore reaches Spanish-speaking users in the United States with its own 100 bytes of keywords, without touching a second storefront. India lists eleven additional languages under an English (U.K.) default. See Apple's storefront and language table.
Screenshots follow the same per-language logic, with one constraint worth knowing early: a language can only become your primary language once its own screenshots are approved at the same sizes as the current primary language, and screenshots inherited from another localization do not count, so settle app store screenshot sizes before briefing a designer on ten languages.
Google Play
What Google Play requires for a localized store listing.
A default language, your translations, and Google's automatic ones
Play Console works from a default language you pick when you create the app, then lets you add "translations for your app's store listing page, app strings or in-app products." Its list of languages for your own listing translations runs to 86 entries, with regional codes where they matter: es-419 for Latin American Spanish next to es-ES and es-US, pt-BR next to pt-PT, fr-CA next to fr-FR. "If a user's language preference matches the translation languages you've added, they'll see the translated version."
Where you have not translated, Google does something Apple does not: it offers the user an automated translation of your listing, with a notice near the top explaining the translation was done automatically and an option to switch back to your default language. That is not available in Armenian, Raeto-romance, Tagalog or Zulu. Graphics are handled separately: "If you add text translations without localized graphic assets, your app's graphic assets show from the default language." Google also separates language from country: to show different listings by country rather than by language, it points you to custom store listings. Read Google's translate and localize page.
Limits, and the guidance around them
The listing fields are short. App name, 30 characters, one localized name per language. Short description, 80 characters. Full description, 4,000 characters. Google notes the limits apply to full-width and half-width characters alike, so a Japanese or Chinese listing gets the same count as an English one and says more with it. There is no keyword field; Google warns that repetitive or irrelevant keywords in the name or description make for an unpleasant user experience. Its asset guidance says outright to localize your description, your graphics and your branding text as appropriate for different markets and languages, and to provide a localized preview video for different markets. A listing needs a minimum of two screenshots, with up to eight per device type.
Google's own translation options, with the prices it publishes
Free machine translation
No cost
Ten languages: Arabic, French (France), German, Indonesian, Italian, Japanese, Portuguese (Brazil), Spanish (Latin America), Spanish (Spain) and Thai. Instant, for the store listing and in-app products.
Google's own caveat: these translations are not reviewed or approved by humans.
Paid human translation
From USD 0.07 per word
A third-party vendor ordered inside Play Console for the listing title, short and full description, and in-app product text. Delivered within seven days, with previously translated strings reused so you pay only for new text.
Not every source and target language pair is offered. Price as published in September 2026.
App strings with Gemini
No cost
Translates the strings in your app bundle, regenerated whenever a new bundle is uploaded to a draft release, with a preview and an edit step before you publish.
Google's own warning: if you select right-to-left languages, make sure the app is RTL-ready first.
Side by side
App Store and Google Play, rule by rule.
The same app, the same languages, two different sets of defaults. The rows that trip teams up are the fallback and the screenshots: Apple quietly reuses your primary language's images, Google quietly machine-translates your text.
| Rule | App Store | Google Play |
|---|---|---|
| Languages for listing metadata | 50 languages and locales | 86 languages for your own translations |
| Starting language | A primary language, changeable at any time in App Store Connect | A default language chosen when you create the app |
| Languages you have not localized | The next most relevant localization, otherwise the primary language | An automated translation offered with a notice, except in Armenian, Raeto-romance, Tagalog and Zulu |
| Name | 30 characters | 30 characters, one localized name per language |
| Short text | Subtitle 30 characters, promotional text 170 | Short description 80 characters |
| Long text | Description 4,000 characters | Full description 4,000 characters |
| Keyword field | 100 bytes per localization, searchable wherever the store supports that language | None; Google warns against stuffing keywords into the name or description |
| Screenshots | Required per localization; a new language inherits the primary language's screenshots until you replace them | Minimum two, up to eight per device type; without localized graphics the default language's graphics show |
| Translation inside the console | None | Free machine translation, paid human translation, Gemini app strings |
| Adding a language | Added while the app status is editable; approved when a version ships with it | Added from Manage translations on the store listing |
From App Store Connect Help and Play Console Help, checked September 2026.
Inside the app
Localizing the app itself: strings, formats and direction.
The listing is metadata you can edit any afternoon. The app is a build. What follows is what has to be true of the build before the first translation is worth paying for.
Strings live outside the code
Android's rule is blunt: default strings in res/values/strings.xml, each language in its own res/values folder with a language suffix, and a missing translation falls back to the default. But if an app is missing even one default resource, Android's documentation says it does not run on a device set to an unsupported locale: the user gets an error and a Force Close button. On iOS the equivalent home is a string catalog in Xcode. Apps built on React Native and Expo, which is what most AI app builders produce, read the device's languages with getLocales() from expo-localization and look strings up through a library such as i18n-js with fallback enabled, so an untranslated key shows the source language instead of a blank.
Dates, numbers, currency and plurals come from the locale
Formatting is not translation. 1,234.50 is 1.234,50 in Germany; dates swap day and month between the United States and almost everywhere else; some languages have more plural forms than English, so "3 items" is not one string with a number dropped in. Take all of it from the locale APIs rather than string concatenation. Apple's Human Interface Guidelines add a rule people get wrong in Arabic: never reverse the digits of a number, and be aware that Arabic text may use Eastern or Western Arabic numerals depending on the region, while Hebrew uses Western ones.
Right-to-left is a layout job, not a font job
Apple's guidelines say system-provided components flip automatically in a right-to-left context, so an app built from standard controls may need no changes at all. The judgement calls are the custom parts: a back button must point right so the flow of screens matches the reading order; a control that means an actual direction keeps its direction; photographs, illustrations and artwork are not flipped, because flipping changes their meaning; and Arabic or Hebrew text next to uppercase Latin often needs its font size raised by about two points to look balanced. In an Expo app, right-to-left support is on by default and the layout direction follows React Native's I18nManager, so the test is simple: set a device to Arabic and walk every screen before you write a Saudi or Emirati listing.
The app name, permission dialogs and per-app language
Two things users see before your first screen: the app name under the icon and the permission prompts. On iOS both come from the binary. In an Expo app config, a locales map points each language at a JSON file holding CFBundleDisplayName and the usage description strings for camera, contacts, location and the rest, with CFBundleAllowMixedLocalizations set to true in the Info.plist. Declare the languages the app supports through the expo-localization plugin's supportedLocales, and Android 13 or later lists the app under Settings, Apps, then Language so users can pick a language for that app alone; iOS offers the same per-app setting. All of it is compiled into the binary by an eas build, so adding a language to the app is a new build and a new review, not a metadata edit.
Android ships only the languages the device uses
An Android App Bundle splits language resources by default: Google Play decides which language resources to install from the language selection in the user's device settings, and downloads more if the user changes their system language later. An in-app language picker breaks that model. Google's instruction is to either turn the language split off or implement on-demand language downloads, otherwise the picker offers languages the device never received and the app crashes looking for them.
Choosing languages
Pick markets first, then languages.
Localization is priced per language, but revenue arrives per market, so start from storefronts. Apple publishes the default language and the additional supported languages for every storefront it operates. The planner below is built from that table. The case for doing it at all is not subtle: in CSA Research's survey of 8,709 consumers in 29 countries, 76% preferred to buy products with information in their own language, and 40% said they would never buy from websites in other languages.
Try it
Which App Store localizations do your target storefronts use?
Built from Apple's published storefront table. Pick the language you already have and the storefronts you want to sell in, and see which localizations to add first and which ones Apple lists as supported there.
Storefronts
The plan
3 localizations to add for 4 storefronts
Apple lists English (U.S.) as a default or supported language in 2 of these 4. In the other 2, users still see your English (U.S.) metadata; the store just does not treat it as one of that storefront's languages.
Add first: the default language of a storefront you picked
Worth adding next: also listed as supported in those storefronts
Storefront defaults and supported languages from Apple's App Store localizations reference, checked September 2026, for 26 common storefronts out of the 175 Apple lists. Google Play works from language codes rather than storefronts, so the same market thinking applies there with es-419 covering Latin America and pt-BR Brazil.
Before you submit
A mobile app localization checklist, in the order that avoids rework.
Ten steps. The order matters more than the steps: translating before internationalizing, or shooting screenshots before the strings are frozen, is how a two-language launch turns into four rounds of the same work.
- 1
Fix the primary language and the first storefronts.
Everything below is priced per language and paid back per market, so the list of storefronts comes first and the list of languages falls out of it.
- 2
Internationalize before you translate.
Strings out of the code, formats from the locale, layouts that can mirror. Set a test device to a language you do not support and make sure the app still opens; on Android a single missing default string is enough to stop it.
- 3
Freeze the source strings and give translators context.
Where each string appears, how much room it has on screen, and which placeholders must not change. A 30-character button label in English is a 40-character one in German.
- 4
Translate the strings users meet first at native-speaker quality.
Onboarding, permission prompts, paywall, errors, the empty states. Machine-translate the long tail if you must, then have a native speaker review it.
- 5
Run the formats and right-to-left pass.
Numbers, dates, currency and plurals from the locale APIs, navigation that mirrors in Arabic and Hebrew, photos and real-direction controls that stay put, and digits that keep their order.
- 6
Localize the app name and permission strings in the build.
Declare the languages the app supports so the per-app language setting shows up on iOS and Android 13 or later. This is a new build, so schedule it with a version.
- 7
Write each store localization inside the limits.
Name at 30 characters, the subtitle or short description, the description, and on the App Store a fresh 100-byte keyword set for every language rather than a translation of the English one.
- 8
Produce localized screenshots at the approved sizes.
On the App Store a new language inherits the primary language's screenshots until you replace them, and a language whose screenshots were inherited cannot be promoted to primary until it has its own at matching sizes. On Google Play, localized graphics are optional but the default language's images show without them.
- 9
Test each locale as a user in that storefront.
Read the listing from an account in that country, then run the app with the device set to that language, including the screens you did not translate.
- 10
Submit the language with a version and keep What's New localized.
A new App Store language goes through App Review with an editable version, and every update afterwards needs its release notes in each language or the primary language shows instead.
The upload itself, the review notes and what gets attached to the version are the same for every language, and they are covered step by step in publishing to the App Store.
Tools and services
App localization tools and services, and what each one actually does.
Searching for a localization app or an app localization tool turns up five different kinds of product, and they do not replace each other. Most teams that localize well use two: something to manage the strings, and people who read the language.
| Kind | What it gives you | Where it stops |
|---|---|---|
| Store-native options in Play Console | Free machine translation in ten languages, paid human translation from USD 0.07 per word, Gemini translations of the strings in each uploaded bundle. | Google Play only, and text only. Nothing for screenshots, and nothing for the App Store side of the same app. |
| Translation management platforms | String files go in, translators and machine engines work on them with context, translated files come back, often synced straight to the repository. | They organise the work. Deciding what to say, and reviewing it in each language, is still a person. |
| App localization services: agencies and freelancers | People who translate, review and sometimes test in-market, priced per word or per hour, with a glossary that keeps terms consistent across releases. | Quality tracks the brief. Without screenshots, context notes and a glossary from you, they translate strings they cannot see. |
| AI drafting with native review | Fast first drafts of strings and store copy from a large language model, with a native speaker fixing tone and the strings users see first. | Unreviewed output on a paywall, a permission prompt or a legal screen is a support ticket waiting to happen. |
| Screenshot and listing tooling | Templates that regenerate localized screenshots per device size and language from one design, with captions swapped per locale. | Still needs translated captions and a check that the longest language fits the frame. |
A tool earns its place when
it keeps every language in step with the source strings release after release, and shows a translator the screen the string sits on.
No tool fixes
a string that was never externalized, a layout that cannot mirror, or a paywall nobody in that language has read.
When to build your own
When the localized version needs a different app, not a different string file.
Most of this page assumes the app is the same everywhere and only the words change. Often it is not. A market needs a different payment method, a different sign-up flow because of a local identity rule, a feature that exists because a partner operates in one country and not another, or a right-to-left redesign of a screen that was never built to mirror. Off-the-shelf app builders and templates tend to fix that structure, and localization turns into a fight with the template.
Teams in that position end up building their own app, which is what Newly is for: describe the app you actually need, languages and market rules included, and it builds a real native app around that description rather than around a template, from $25 a month. Its iOS builds go to App Store Connect, which is where the localized listing lives, and v2 does not produce Android release builds, so a Google Play listing is a separate track for now.
Sources
Where the specifics came from.
Every rule, limit and price on this page was read from the stores' own documentation or a published study, all opened in September 2026. Field limits come from the App Store Connect and Play Console references; the in-app details from Android's localization guides, Expo's localization guide and Apple's Human Interface Guidelines.
FAQ
Mobile app localization, answered.
Mobile app localization is adapting an app and its store presence so it reads and behaves as native in another language and market. It has three layers: the store listing (name, description, keywords and screenshots per language), the app itself (every string moved out of the code, locale-aware dates, numbers, currencies and plurals, and a layout that mirrors for right-to-left languages) and the market (pricing, payment methods, legal text and support in that language). Translation is one step inside the first two layers, not the whole job.
Build the app the market needs, then localize it.
Strings, formats and the store listing are the same job in every language. The part that differs is the app itself. See what people have built with Newly, then describe yours.