App Store Localization: Which Languages to Add First

Short answer

Add languages where you already get impressions and a weak conversion rate in App Store Connect, then check competitors, market fit, and cost. Apple supports 50 localizations, each with its own metadata, so you don’t need many. Start with one or two metadata-only localizations, measure them, and pay for full translation only where the numbers hold up.

OpenASO publishes this guide. Apple details were checked on November 1, 2026. We don’t quote market sizes here, because your own data is a better guide.

How many languages does the App Store support?

Apple supports 50 localizations. Apple’s news post of March 31, 2026 added 11, namely Bangla, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Slovenian, Tamil, Telugu, and Urdu, with a stated focus on India. The full list is on Apple’s reference page, so older tables with fewer languages are out of date.

What does a localization include?

Each localization has its own App Store metadata, including the name, subtitle, description, screenshots, and keywords. Keywords get a separate field per language, and Apple’s reference page gives that limit as 100 bytes.

When you add a language, screenshots and most properties default to the primary language. The description and keywords do not, so you must write those. Apple says you can add localized metadata with your next version submission.

Which languages work in which storefronts?

Apple’s reference page maps every storefront to a default language and any additional supported languages. Here are a few rows, checked November 1, 2026:

Which language a customer sees also depends on their device settings and the languages you added, as Apple notes on that page. If you provide only English, Apple says your metadata appears in English everywhere.

Is cross-localization an Apple feature or a vendor claim?

It is both, and it helps to separate them. Cross-localization means using a second language’s metadata to reach more searches in a storefront, such as filling Spanish (Mexico) to reach searches on the US store.

What Apple documents. The storefront table above, and one important line. Apple’s localization help uses French as an example and says users can search using localized keywords in all countries or regions where the App Store supports French.

What Apple does not document. How those keywords are weighted, and whether they combine with terms in other languages. Apple’s reference page does not mention search or indexing at all.

What vendors claim. These are observations, not Apple policy:

• AppTweak, updated November 21, 2025, says keywords in at least two locales can index in each territory, and that keywords do not combine across locales. It credits its table to tests with made-up keywords from a 2022 book.
• MobileAction, April 15, 2026, publishes a similar table and says the behavior it describes rests on industry observation.
• AppTweak also says that mixing languages this way is frowned upon by Apple, though it knows of no publicized rejections. We found no Apple statement on this either way.

The sources also conflict. Both vendors list English (Australia) as indexed on the UK store, while Apple’s table lists no additional language there. So test any row you plan to rely on.

Remember that real people see this text. Spanish (Mexico) metadata on the US store is shown to people using Spanish, so it should be proper Spanish, not a keyword dump.

How do you check whether it worked?

Run a rank check in the storefront you care about. Add the terms in the second locale, ship the version, wait for it to go live, then search those terms in that country with the keyword rank checker. That tool uses Apple’s public iTunes Search API, so confirm terms that matter on a real device. If you see no position, treat the table as wrong for your app, or try again later.

How do you choose which languages to add first?

Work through four filters in order, and drop a market as soon as one fails.

1. Your own data. In App Store Connect analytics, filter impressions, product page views, downloads, and conversion rate by territory. Look for places with real impressions and low conversion, which may point to a language barrier. Also split by source type, since App Store search traffic is what keywords affect.
2. Competitors. Search your main terms in that storefront. If the top apps show unlocalized English names, you may have an opening. If they are local apps with strong ratings, expect a harder fight.
3. Market fit. Ask whether your app works there. Check pricing, content, payment methods, regulation, and whether you could answer a support email in that language.
4. Cost. Compare translation and upkeep with what the market can repay. Every localization adds work to each release.

A US app with spare storefront languages can also test Spanish (Mexico) before spending on a new country. That test still depends on the vendor claims above.

Should you localize metadata only, or the whole app?

Start with metadata unless your data already justifies more. Apple treats App Store metadata and the binary as separate localizations.

Metadata-only has a cost of its own. Someone may download an app that does not speak their language, so state that in the description if it applies. Don’t translate keywords word for word either, because people in another market may use different terms. Have a native speaker review them, and research each locale as you would in English.

What should you do next?

Open App Store Connect, sort your territories by impressions, and pick the top market with weak conversion. Write metadata for that one language, ship it, and compare conversion after a few weeks.

If you use OpenASO, the localization section of our MCP workflows shows a prompt for comparing competitors across countries. It gathers evidence only. It does not translate your text or publish to App Store Connect, and it covers Apple’s store, not Google Play.