The usual advice on App Store localization is to translate your listing. Follow it exactly and you will end up with a listing that reads correctly in German and ranks for nothing in the German store.
The reason is one field. Your name and description are prose, and prose translates. The keyword field is not prose — it is a list of the words people type into a search box. What a German speaker types is a fact about German search behaviour, and it is frequently not the translation of what an English speaker types. Run those hundred bytes through a translator and you have produced a technically correct list of words nobody searches.
What Apple supports
Apple's App Store localizations reference lists 50 languages and locales for app metadata — counted from Apple's own list for this post, and corroborated by developer.apple.com's own "50 languages" figure. Worth checking the count yourself if you have seen a smaller number quoted: this list grows, and several widely-repeated figures are out of date.
The list includes four English variants (U.S., U.K., Canada, Australia), two Chinese scripts, two Portuguese, two Spanish, and ten languages of India. It does not include a language for every storefront Apple operates — a point that matters below.
Two of Apple's other statements set the constraints:
- The keyword field's size is stated two different ways by Apple. App Store Connect's platform version information reference says "up to 100 bytes of content"; the App Store search page says "limited to 100 characters total". In English the two agree. In Japanese, Greek, Arabic or Hindi one character costs two, three or four bytes, and they describe very different fields. Plan against the smaller reading until your own field saves without truncation.
- "Don't repeat any words any words included in your app name, subtitle, or category" — from Apple's App Store search page, typo and all. This applies per localization, not once globally.
Localizing versus translating, concretely
The difference shows up in four places:
The keyword field. Use the terms that market actually searches. If a market genuinely searches an English loanword — and many do, for software categories especially — then the loanword is the right keyword, and translating it away loses you the traffic.
Byte budget. Spaces after commas cost a byte each and index nothing. In a two-byte script that already halves your effective field, throwing away another dozen bytes on whitespace is worse than careless.
Cross-field repetition. A word in your localized name or subtitle is already indexed. Repeating it in that locale's keyword field spends bytes on nothing.
Other companies' names. Do not put them in any localization. Apple rejects for it, and the rule does not soften in a smaller market.
Which storefront speaks which language, and where it breaks
Mapping a storefront to a metadata locale looks trivial and is not. Scanning Apple's locale list in order and taking the first match on the country code gets two obviously wrong answers immediately: it offers Catalan for Spain (es) and French (Canada) for Catalonia's code (ca). An explicit override table is unavoidable.
Several storefronts have an obvious answer that is not their own country code: Austria takes German, Hong Kong takes Traditional Chinese, Ireland takes English (U.K.), the UAE and Egypt take Arabic, and the Latin American storefronts take Spanish (Mexico).
Others have no defensible single answer, and guessing is worse than declining:
| Storefront | Metadata locale | Why |
|---|---|---|
| Austria | German | Not its own country code |
| Ireland | English (U.K.) | Nearest supported variant |
| Hong Kong | Chinese (Traditional) | Script, not country |
| UAE · Egypt | Arabic | — |
| Argentina · Chile · Colombia · Peru | Spanish (Mexico) | Apple's Latin American locale |
| Spain | Spanish (Spain) | A naive first-match offers Catalan |
| Belgium · Switzerland · Singapore | none | Genuinely multilingual — a guess is a decision |
| Iceland · Philippines · Pakistan | none | Apple has no localization for the language |
- Belgium, Switzerland, Singapore — genuinely multilingual storefronts. Picking one language for them is a choice about the market, not a lookup.
- Iceland, the Philippines, Pakistan — Apple has no App Store localization for the primary language. There is nothing to map to.
Appstro's tools leave all of those unresolved and say so, rather than filling in a plausible-looking answer. A storefront reported as "no single App Store language" is information. A storefront silently assigned the wrong one is a bad decision made on your behalf.
Detecting what is actually localized
If you want to know which storefronts are currently serving your English listing, the test has to be an OR across the name and the description, not the name alone.
Verified against live data: WhatsApp returns an identical product name in every storefront while returning localized descriptions. Test the name only and you would conclude that WhatsApp has localized nothing, anywhere. That is what the localization audit checks, and it is a one-line design decision that changes every row of the output.
The English-variant storefronts deserve their own bucket too. A UK, Canadian or Australian visitor reading your US listing understands every word of it. The gap there is idiom and spelling, not comprehension, and it belongs at a different point on the priority list than a storefront reading a language its users do not speak.
Prioritising, without pretending to know more than you do
Which storefront to localize first is answerable from public data, but only in one narrow form: storefronts where your app already has meaningful rating volume and the listing is not localized.
Verified: WhatsApp in India carries 7,996,710 ratings against a description byte-identical to its US listing — 2,382 characters, the same on both. Across a full sweep, 40% of that app's worldwide ratings came from storefronts reading English.
That ranking says something real: these people found you, used you, and rated you, in a language you did not write for them. What it emphatically does not say is that translating will produce more of them — nothing public exposes impressions or conversion rate per storefront, so the size of the opportunity is not computable from outside. Localization priority states the verifiable half and stops.
One implementation detail worth stealing
Any text box where someone drafts Arabic or Hebrew metadata needs dir="auto". Without it the draft renders backwards, and the person reviewing it cannot tell whether the copy is wrong or the box is. It is one attribute and it is the difference between a usable review and a confusing one.
What this cannot tell you
- Not search volume in any language. There is no public App Store search volume in English and there is none in Japanese either. Any localized keyword you generate is a candidate, and it needs checking with a rank check in that storefront before you trust it.
- Not whether localizing improves ranking. Apple names the text-relevance fields; it does not publish a localization factor. What is verifiable is that users in that storefront read that text.
- Not whether the copy is good. Character counts and byte budgets are arithmetic. Whether the German reads like German is what a native speaker is for, and no score should pretend to stand in for one.
- Not which language a multilingual storefront wants. See Belgium, Switzerland and Singapore above.
The work
Run the audit to see which storefronts are reading your English listing, priority to see which of those already has users, and localized metadata to draft the replacement — then have somebody who speaks the language read it before it ships. That last step is not optional, and the draft is the input to it, not a substitute for it.