Localization coverage by storefront

A lookup table. The mechanism it illustrates is in 10-07; this page exists so you can answer “which languages are indexed in this country” without re-deriving it.

The one thing to take away

B English (U.K.) is indexed in every storefront group below except three: the United States, Japan and Canada. Each of those has its own English variant instead. English (U.S.) in the US and (as an additional localization) in Japan, English (Canada) in Canada.

That single fact is the whole of locale stacking in one line. An English (U.K.) localization is doing work in almost every market you serve, and it is the cheapest keyword surface most apps leave empty.

The table

B Compiled reference. Spot-checked against Apple’s own localizations page for the US, Germany and India rows and consistent on all three. But verify the specific row you are about to act on (App Store localizations). Apple changes this without announcement.

Ordered as in the source, by estimated market value.

The grouped regions

Rest of the World. Afghanistan, Albania, Angola, Anguilla, Antigua and Barbuda, Armenia, Azerbaijan, Bahamas, Barbados, Belarus, Bermuda, Bhutan, Botswana, Brunei Darussalam, Bulgaria, Cape Verde, Cayman Islands, Dominica, Estonia, Eswatini, Fiji, Gambia, Georgia, Ghana, Grenada, Guyana, Iceland, Jamaica, Kazakhstan, Kenya, Kosovo, Kyrgyzstan, Latvia, Liberia, Lithuania, Macedonia, Malawi, Maldives, Malta, Micronesia, Moldova, Mongolia, Montserrat, Mozambique, Myanmar, Namibia, Nauru, Nepal, Nigeria, North Macedonia, Palau, Papua New Guinea, Philippines, Saint Lucia, São Tomé and Príncipe, Sierra Leone, Solomon Islands, South Africa, Sri Lanka, St. Kitts and Nevis, St. Vincent and the Grenadines, Tajikistan, Tanzania, Tonga, Turkmenistan, Turks and Caicos, Uganda, Uzbekistan, Zambia, Zimbabwe.

These storefronts index English (U.K.) and nothing else. For a sizeable group of countries (including Nigeria, the Philippines, South Africa and most of the Baltics and Central Asia) an English (U.K.) localization is your only indexed text.

Arabic world. Algeria, Bahrain, Egypt, Iraq, Jordan, Kuwait, Lebanon, Libya, Mauritania, Oman, Qatar, Saudi Arabia, Tunisia, United Arab Emirates, Yemen.

Hispanic America. Argentina, Belize, Bolivia, Chile, Colombia, Costa Rica, Dominican Republic, Ecuador, El Salvador, Guatemala, Honduras, Mexico, Nicaragua, Panama, Paraguay, Peru, Uruguay, Venezuela.

French-speaking Africa and Asia. Algeria, Benin, Burkina Faso, Cambodia, Cameroon, Chad, Congo (both), Côte d’Ivoire, Egypt, Gabon, Guinea-Bissau, Laos, Lebanon, Madagascar, Mali, Mauritania, Mauritius, Niger, Rwanda, Senegal, Seychelles, Trinidad and Tobago, Tunisia, Vanuatu.

Using a spare locale as keyword space

The table says which fields count. This says what to do with the ones you are not using.

The move. A storefront that indexes a locale you have not filled is indexed text you already have rights to. The most-cited example is the US: an app with no Mexican business can still put terms in the Spanish (Mexico) fields and have them indexed in the US storefront. The same logic applies to every second and third row in the table.

The constraint that decides how you use it. B Keyword combination does not cross localizations, verified 2026-09-20 against three independent sources (30-04). A spare locale is therefore not extra characters bolted onto the first one: each locale’s fields must form their own combinations, which means deliberately repeating a word across locales where the rule inside a single locale is never to repeat. Plan the second locale as a self-contained keyword set, not as an overflow.

The honest reading of the risk. Filling a locale’s fields with terms in a different language is not what the localization is for, and the practitioner literature reports that Apple takes a dim view of it while noting no publicised rejections. Treat it as a grey practice with an unknown enforcement history rather than a free lunch. And note that a Spanish (Mexico) page stuffed with English is a page some users will actually see.

The defensible version of the same idea: localize the title and subtitle properly for the locale, and use the hidden keyword field for the reach. That keeps the visible page honest, and the keyword field is where the unused space actually is (30-05).

How to use this

Read it as “what indexed text can I have here”, not “what language do people speak”. These are indexing slots, not demographics.

Look for markets where you are leaving a slot empty. A Every field is set per localization (Required, localizable and editable properties, verified 2026-09-19). An unfilled localization that a storefront indexes is free keyword space you already have access to.

The US is the biggest opportunity in the table. Nine indexed localizations beyond English (U.S.) (Spanish (Mexico), Russian, both Chinese scripts, Arabic, French, Portuguese (Brazil), Vietnamese and Korean) all inside the single largest storefront, with no new market entry required.

Note the multi-language storefronts. Switzerland indexes German, French and Italian; Belgium Dutch and French; Morocco Arabic and French; Ukraine Ukrainian and Russian; Cyprus Greek and Turkish; Spain Spanish (Spain) and Catalan. Each is more than one keyword field in one country.

Research each one in its own language. A localization added and machine-translated ranks for terms nobody types (30-05).

Then maintain it. A stale localization is worse than none, because users still see it (00-06).

Provenance and caveats

Compiled from a practitioner spreadsheet (source, retrieved 2026-09-19), reproduced here with regional groupings and labels lightly normalised. The raw export is kept at data/localization-coverage.csv.

Why it is B and not [A]: Apple documents that each storefront has a default plus additional supported languages, and publishes the mapping. But this table is a third party’s compilation of it, not Apple’s page. It corroborates on every row checked. It is a working reference, not a citation.

Now corroborated by a second, independent source. The Phiture Advanced ASO e-Book (2022) reports keyword tests using invented terms, strings such as enuk1201 placed in an English (U.K.) localization and then tracked across storefronts, and reaches the same conclusions this table encodes: English (U.K.) indexed almost everywhere but not in the US or Canada, not in Japan where English (U.S.) is indexed instead, and the US indexing Spanish (Mexico) alongside English (U.S.). A compiled spreadsheet and an independent empirical test agreeing is a materially better footing than either alone, which is why IOS-LOC-005 now names both.

One thing that source adds and this table does not carry. It reports that English (Australia) was also indexed globally outside the US and Canada at the time of writing, flags it as unexplained, and warns Apple could reverse it. Not reproduced above, because one source, from 2022, on a behaviour its own author calls unstable, is not a row anyone should act on. On the verification queue.

The source also carries two estimate columns (iOS users in millions, and iOS users weighted by GDP per capita PPP) used to order the table. Those are the compiler’s own estimates with no stated method or date, so they are [C] and are not reproduced as figures here. They are a reasonable sketch of relative market value and nothing more; for a tier-1 decision, use your own volume and revenue data.

Re-check before a market decision. Apple adds languages and changes storefront groupings without announcement. This table is a starting point for the question, not the answer to it.