App Store and Google Play localization: what each store shows and searches

How the App Store chooses a language#

Every App Store app has a primary language. Apple defines it as the default language for product page metadata when you don't provide localized metadata for a country or region. Each language you add is a localization with its own name and subtitle and its own keywords, description and screenshots. Apple's example, with English as the primary language:

Two more rules on the same page matter. If no localization matches a person's language setting, the next most relevant one is used. If you delete a language, the storefronts that showed it go back to your primary language. Apple's localizations reference adds that the language each customer sees can be affected by factors such as the App Store language for their location, their device's language settings, the languages you added and your primary language.

So there is no single switch. Which page a person sees depends on where they shop and how their device is set, and you control only which localizations exist. These store-page languages are also separate from the app's own translations: Apple notes that this differs from adding languages to your app in Xcode when you localize your binary.

Apple's storefront language table#

Apple publishes a table of every storefront with two language columns: "Default language" and "Additional supported language(s)". On November 12, 2026 it listed 175 storefronts. These rows show which languages each storefront supports, which is what decides where a localization's keywords can be searched.

The full table has patterns worth knowing before you choose languages:

• English (U.K.) is the default in 135 of the 175 storefronts, and it is listed in every storefront except the United States, Canada and Japan.
• English (US) is listed in only two storefronts: the United States, as the default, and Japan, as an additional language.
• Spanish (Mexico) is the default in 16 Latin American storefronts, Mexico among them, and an additional language in three more: the United States, Belize and Uruguay.
• French is listed in 32 storefronts, not counting French (Canada), mostly as an additional language. Arabic is listed in 17, always as an additional language.
• India lists 11 additional languages, the most of any storefront. The United States lists nine. Of the 175 storefronts, 71 list none.

NoteThe table copies Apple's own wording, which varies: China mainland's default is "Simplified Chinese" where other rows say "Chinese (Simplified)". Apple can add or change rows, so check its page before you plan a market.

What a second localization adds to search#

Read Apple's French example against the table. French is an additional supported language in the United States, so by Apple's own sentence, people can search for your app in the US storefront using your French localization's keywords. The same reading applies to the eight other additional languages on the US row, Spanish (Mexico) among them. This is the basis of the familiar advice to add a second localization for more keyword room in the US.

Apple's sentence is short, and it leaves a lot unsaid. Apple does not say:

• How a word from an additional localization ranks against the same word in the storefront's default language.
• Whether the name and subtitle of an additional localization count in that storefront the way its keywords do. The sentence names keywords only.
• How a word written in another language, placed in that localization's keyword field, is treated.
• How it picks "the next most relevant localization" when none matches.

Then there is the trap. The localization is not hidden. Apple shows it to people whose language setting is that language, and Spanish (Mexico) is the default language of 16 storefronts. Its name, subtitle, description and screenshots are what those readers see; only the keyword field stays out of sight. The rule: if you add a localization for its keywords, write its visible fields for its readers too.

Each localization has its own keyword field. Apple's App Store Connect reference says up to 100 bytes; its product page and search guides say 100 characters, and neither says which encoding it counts. Count bytes to be safe: in UTF-8, a Japanese, Chinese or Korean character takes 3 bytes and a Cyrillic or Arabic letter takes 2, so those fields can hold far fewer characters than an English one. Apple doesn't say how it counts other scripts, so check the count App Store Connect shows. The keyword field counter counts characters and warns when a line passes 100 UTF-8 bytes.

The same Apple page says your app is already searchable by its app name and company name, so you shouldn't repeat them in the keyword list. Apply that to each localization's own name. The keyword field page covers the rest of the field's rules, and the App Store keywords guide covers choosing the words.

Adding a language in App Store Connect#

If your app is in several languages, Apple's product page guide asks you to localize the description, keywords, app previews and screenshots for each market where you offer it, and says you can translate the app's name and tailor keywords to each market. Apple's steps, in short:

1. Open the app in App Store Connect and click the primary language at the top right.
2. Under Not Localized, hold the pointer over the language you want and click the add button (+).
3. Enter the localized metadata for the platform, such as the description and keywords, then save.
4. Click App Information, add the same language, and enter the app name and privacy policy URL for it, then save.

Apple adds that a language added from the platform version section is automatically added to the shared metadata under App Information. The subtitle sits on App Information too, and Apple lists it as localized.

Apple says a new language takes the primary language's screenshots and properties, except the description and keywords. So a fresh localization shows your primary-language name, subtitle and screenshots until you change them. Our advice: replace the screenshots and write the name and subtitle before you submit. You can manage languages only while the app status is editable, and the name changes with a new version, so plan language work into a release.

Changing the primary language later takes planning. Apple requires that the language was added to an earlier version, approved by App Review, and has approved screenshots for every platform in the same sizes as the current primary language. If the app has custom product pages, each needs screenshots in that language too.

To compare localized images, product page optimization lets you localize each treatment in all of your app's languages or only some. Apple warns that a test may take longer to reach results depending on the localizations you select.

How Google Play chooses a language#

Google Play's translations work by the user's language, not by country; to vary a listing by country, Play uses custom store listings. Google says that if a user's language preference matches a translation you added, they see the translated version. A new app's default language is English (United States, en-US), and you can add translations along with in-language screenshots and other graphics.

Where you add no translation, Play shows either an automated translation generated by Google Translate or your default language. An automated translation carries a note that says so, with an option to view the default language. Google lists four languages without automated translations: Armenian, Raeto-Romance, Tagalog and Zulu.

Two details catch people out. Custom store listings are not translated automatically, so their audience sees them in the listing's default language unless you add translations. And Play's language list is finer than Apple's: Spanish (Latin America), Spanish (Spain) and Spanish (United States) are separate entries, and Chinese (Hong Kong) sits beside Simplified and Traditional. Google lists 86 languages and locales for your own translations; Apple lists 50 for App Store metadata.

Translating a Play listing#

Play Console gives you three ways to translate the title, short description and full description, plus a fallback when you do nothing.

That is the one link Google draws between translation and search: a professionally translated description. The free machine translation covers Arabic, French (France), German, Indonesian, Italian, Japanese, Portuguese (Brazil), Spanish (Latin America), Spanish (Spain) and Thai. Treat its output as a draft. The Gemini translation on the same help page is for the strings inside your app bundle, not the store listing.

Translations are policed like the original. Google's best practices say the Metadata policy and its other policies apply to all translations of your listing, so the Metadata policy's rules for the title, icon and developer name (no emoji, no rank claims, no prices or promotions) hold in every language. Keep each title within 30 characters and each short description within 80; a translation can run longer than the original. The title counter and the short description counter check both.

Localized screenshots and graphics#

On Play, localized graphics show to users whose language preferences match the languages you add. If you add text translations without localized graphics, Google says your default language's graphics show. Google's best practices ask for separate screenshots and promotional videos for each language when the screenshots contain text.

Localized graphics also change who sees a store listing experiment. Google says users viewing your app in a language that has localized graphic assets are excluded from your default graphics experiments, even when you test only the icon. To test in those languages, run a localized experiment, which covers up to five languages. The store listing tests guide covers both stores' tests, and the store test calculator shows how long a test needs.

On the App Store, a new localization starts with the primary language's screenshots. With English as the primary language, a new French localization shows the English screenshots until you replace them. If your screenshots carry captions, that is the first thing to translate after the name and subtitle.

A localization routine#

1. Pick markets from your own numbers. App Store Connect lets you filter acquisition by territory and device, not by language, so in the filters Apple lists, a US Spanish localization cannot be read apart from US English. Play Console's conversion analysis filters by country and by language.
2. For each App Store storefront, find its row in Apple's table: the default language, and the other languages it supports.
3. Write the visible fields for native readers: the name, the subtitle or short description, the first lines of the description, and screenshot captions.
4. Fill each App Store localization's keyword field with words for that market, without repeating that localization's app name.
5. On Google Play, have the full description translated by a professional or a native speaker, and check each translated title against the Metadata policy.
6. Ship one language change per store at a time, and note the day it appears on the live listing.
7. Read the same territory or language for whole weeks before and after. That is a before-and-after read, not a controlled test.

Google adds one check of its own: if your click-through rate in a language is lower than your peers', Play Console Help suggests checking whether the listing is correctly translated in that language. For the companion question of which words are worth a localization's keyword field, see Apple's search popularity.

Where RocketASO fits#

RocketASO reads your App Store and Google Play reports, names the fix estimated to be worth most this week, and compares installs before and after it. It starts you with a draft of the copy or the keyword field, and nothing reaches the store until you approve it. Each comparison is a before-and-after read at 7 and 14 days, not a controlled test. To check a public listing first, run the free ASO audit.