App localization: which markets are actually worth it

App store localization gets written about by two groups who never talk to each other. Translation platforms explain resource files, plurals and pseudolocalization, then treat the store listing as a closing paragraph. ASO tools explain keyword localization and never mention that your app also contains strings. This piece covers the store half properly, because that is the half you can ship this week without touching code.

It is also the half where the published advice is factually wrong most often. Nearly every guide currently ranking states a language count for one or both stores that is out of date, and several quote a 2012 study as if it were current data.

Three words people use interchangeably

• Internationalization is the engineering work that makes localization possible: strings out of the code, no hardcoded date or currency formats, layouts that survive German text being roughly a third longer than English.
• Translation converts text from one language to another.
• Localization adapts the whole experience to a market: the copy, the screenshots, the examples, the pricing, and critically for ASO, the keywords, which are not a translation of your English ones.

Store localization can be done entirely without internationalizing the app. An English-only app with a properly localized Spanish listing will outperform the same app with an English listing in Spanish-speaking storefronts. Start there, because it is cheap and reversible.

How many languages each store supports

One detail with real strategic value: Google states that its character limits count full-width and half-width characters the same. A Japanese or Chinese character costs one of your 30 title characters, exactly like a Latin letter, so a CJK title can carry far more meaning than an English one in the same budget.

What your listing looks like in a market you skipped

The two stores behave completely differently here, and it changes how aggressively you should localize each.

Applefalls back in two steps. If a user's language does not match any of your localizations, Apple shows the next most relevant one, and failing that, your primary language. A French localization therefore serves users in every storefront where the App Store supports French, not only France. Delete a localization later and those storefronts revert to your primary language.

Google does not fall back to a related language. It offers the user a machine-translated version of your listing with a visible banner saying so, or the default language, which is English (US) unless you changed it. Google also offers free machine translation into ten languages inside the Play Console, with an explicit warning that no human reviewed the output.

Neither fallback earns you a single keyword ranking in that market. A machine-translated listing is a courtesy to a user who already found you. It is not discovery.

The keyword rule that decides your strategy

Apple indexes keywords per localization, and keywords do not combine across localizations. If “bus” sits in your English (US) keyword field and “metro” sits in your Spanish (Mexico) field, you can rank for each term in the US storefront, but you will not rank for the two words used together as a phrase.

This matters because of how the App Store maps storefronts to languages. Apple publishes a table giving each country a default language plus additional supported languages, and terms in any of those localizations can be indexed in that storefront. The United States storefront, for example, supports English (US) as the default plus Arabic, Chinese (Simplified and Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico) and Vietnamese.

The practical consequence: filling in additional locales multiplies your indexable keyword budget in a storefront you already sell in, without translating a single screenshot. That is a real and underused tactic. Two caveats keep it honest. First, this indexing behaviour has been observed by practitioners through controlled testing rather than documented by Apple, so it can change. Second, repeating the same word across your title, subtitle and keyword field, or across a primary and secondary locale, wastes budget; the union is what gets indexed, so every duplicate is a character you spent twice.

Choosing which markets to do first

The instinct is to sort by population. The better sort is by proven demand and by monetization fit, because the download-leading markets and the revenue-leading markets are different sets of countries.

India, Brazil and Indonesia dominate install volume. The United States, Japan, China, Germany, the United Kingdom and Korea dominate in-app purchase revenue, with the US alone a large multiple of any single European market. If you monetize with ads at scale, the first group is your list. If you monetize with subscriptions, the second is.

Score each candidate market on five things before committing:

1. Existing organic installs from that storefront with no localization at all. This is your only piece of real evidence and it should dominate the decision.
2. Category revenue in that market for apps like yours, not for apps in general.
3. Competitive density. A market where the top ten listings are already properly localized is a market where localization is table stakes, not an edge.
4. Total cost per locale, including screenshots, not just words of text.
5. Ongoing maintenance. Every locale you add is a locale that goes stale on your next feature release.

A realistic honest note on cost: budgeting roughly a few hundred dollars per locale for a proper text pass, plus screenshot production, plus native review, is a reasonable planning figure. The recurring cost is larger than the launch cost over a year, and almost nobody plans for it.

A workflow that survives the tenth language

1. Pick a pilot pair. Two markets, chosen on the evidence above. Not eight.
2. Rebuild the keyword list locally.Read the top local competitors' titles and subtitles, read local reviews for the words users actually use, and run a small Apple Ads campaign in that storefront to see which real search terms Apple matches you to. Our keyword research workflow works the same way in any language.
3. Write the title and subtitle first, natively. These are 30 characters each and carry most of the ranking and most of the first impression. They deserve a human, not a draft.
4. Draft the description with AI, then have it reviewed. The description is long, low-risk and where machine assistance pays off.
5. Localize the screenshots. If captions are baked into images, and they are, this is the expensive step. Sizes and per-locale set counts are in our screenshot sizes guide.
6. Publish, then wait. Indexing takes days, not hours, and comparing week one against week zero will tell you nothing.
7. Measure per country, never in aggregate. A blended conversion rate hides the entire result.

Where AI translation genuinely helps

Machine translation is now good enough for a first pass on long-form copy, and bad enough on short copy that shipping it unreviewed is visible. The difference between useful and useless output is almost entirely context.

Three things to give any translation step, human or machine:

• A do-not-translate list. Your product name, feature names you have branded, integration names, and any term your users already search for in English. Without this, your brand gets translated into a word nobody searches.
• The ASO constraint. A title has 30 characters. A translation that is faithful and 42 characters long is unusable. State the limit as part of the task.
• The category vocabulary. The local word for your feature is often not the translation of your word for it. This is the single biggest cause of a perfectly grammatical listing that nobody finds.

In AppBoard the assistant runs on your own OpenRouter key and drafts translated metadata per language directly into the listing editor, where it lands as a draft. Nothing reaches either store until you review and publish it, and the change history records what changed per field per language so you can roll a bad translation back. That review gate is the point, not a limitation.

The mistakes that cost the most

• Translating keywords instead of researching them. The most expensive mistake on this list, and the most common.
• Reusing one locale for a related one. Portuguese (Brazil) is not Portuguese (Portugal), and Spanish (Mexico) is not Spanish (Spain). Users notice immediately.
• Localizing text and leaving screenshots in English. The screenshots are what people actually look at.
• Repeating words across title, subtitle and keyword field. Pure waste of a 160 character budget.
• Shipping the Play Console machine translation as final. Google itself warns that no human reviewed it.
• Adding twelve locales and never touching them again. Stale localizations describe a version of your app that no longer exists.
• Measuring in aggregate. If you cannot see conversion per storefront, you cannot tell which localizations worked.

The maintenance loop nobody writes about

Launching a localization is a project. Keeping twelve of them current is an operation, and it is the part that quietly fails. Ship a feature, update the English description, and eleven listings now describe an older product. Six months later nobody remembers which locales are current.

Whatever tooling you use, you need to be able to answer one question at any moment: which language versions differ from what is live, and in which fields? That is a diff, and treating listing copy like code, with a draft state, a visible diff against what is published, and a history you can roll back, is what makes ten locales maintainable instead of theoretical. It is the reason AppBoard versions listings that way.

Before you add a language, make sure the base listing is worth translating. Our guide to writing app store descriptions covers the structure that should exist in English before you multiply it by ten.

Frequently asked questions

If you want to see per-language listing editing, diffs and publishing without setting anything up, AppBoard is free while it is in beta.