If your listing exists only in English, you are competing in one language across 175 countries and regions. Localization means rewriting your title, subtitle, keywords and screenshots for each market. It gives you a separate chance to rank in each storefront, and a much better chance to convert the people who see you there.
This guide covers the difference between localizing your listing and localizing your app, how Apple maps languages to storefronts, how to approach keywords per locale, how to adapt screenshots for different cultures, and a workflow a solo developer can actually maintain.
Why localization moves the needle
App Store search is not one global index. Each storefront ranks apps for its own users, in the languages that storefront supports. A Japanese user searching in Japanese will rarely find an app whose metadata exists only in English, however good the app is. Localizing gives you more keyword space, more relevance in local results and more convincing product pages.
The math is simple. Every localization you add is another set of name, subtitle and keyword fields that a storefront can index, plus a product page that speaks the visitor's language. For an indie developer, it is often the highest-leverage ASO task after getting the primary language right.
Localizing the listing vs localizing the app
These are two separate jobs, and you can do them in either order.
| What | Where it lives | Affects search? | Affects conversion? |
|---|---|---|---|
| App name (30 chars) | App Store Connect, per locale | Yes, strongly | Yes |
| Subtitle (30 chars) | App Store Connect, per locale | Yes | Yes |
| Keyword field (100 bytes) | App Store Connect, per locale | Yes | Hidden from users |
| Description, promo text | App Store Connect, per locale | Not documented as indexed | Yes |
| Screenshots and previews | App Store Connect, per locale | Not documented | Yes, a lot |
| In-app strings | Your Xcode project (String Catalogs) | No | Retention and reviews |
Listing first is a valid strategy. It is cheap, fast and lets you see whether a market responds before you invest in translating the app itself. Be honest about it, though. The Languages row on your product page comes from the localizations in your app binary, not from your metadata. A German listing for an English-only app can draw installs that turn into frustrated one-star reviews. If the app works fine for non-native speakers (many utilities do), that's okay. If the core experience is text-heavy, translate the app before you push hard in that market.
Which locales each storefront uses
Apple's App Store localizations reference includes a table of every storefront with its default language and any additional supported languages. This is the map to work from: localizing into a language listed for a storefront gives that storefront's users a listing in their language.
A few examples from the same table show how varied the mapping is:
| Storefront | Default | Additional supported languages |
|---|---|---|
| United States | English (U.S.) | Arabic, Chinese (Simplified), Chinese (Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico), Vietnamese |
| Canada | English (Canada) | French (Canada) |
| Mexico | Spanish (Mexico) | English (U.K.) |
| Germany | German | English (U.K.) |
| Japan | Japanese | English (U.S.) |
| Switzerland | German | English (U.K.), French, Italian |
| India | English (U.K.) | Hindi, Bangla, Tamil, Telugu and seven more Indian languages |
The "extra keywords" question
Many ASO practitioners report that metadata in a storefront's additional languages can also help an app rank in that storefront. The example usually given is English keywords placed in the Spanish (Mexico) localization to gain more US keyword space. Apple's documentation lists which languages each storefront supports, but it does not document how additional locales are weighted in search, and practitioners' reports differ on the details.
Research keywords per market. Don't translate them
The single most common localization mistake is running your English keyword list through a translator. People in different markets describe the same need with different words. Some use English loanwords, some use a local term, and some search for a brand-name category leader. Treat every important locale as its own keyword research project. Find the terms with real search volume, check who ranks for them, then write a name and subtitle that sound natural in that language.
Watch the byte limit too. The keyword field allows 100 bytes, not 100 characters. Accented Latin letters take more than one byte in UTF-8, and Japanese, Chinese and Korean characters usually take three, so the field holds far fewer characters than it does in English.
In the English example, "sleep app" is struck through because "sleep" is already in "sleep sounds", and repeating words within a locale wastes bytes. Our keyword field guide covers formatting rules in depth, and the free character counter counts bytes the way App Store Connect does.
Appsium generates name, subtitle, keywords, promo text and description per locale, checks the byte and character limits as you edit, and previews how the listing looks on the store.
Adapt screenshots for each culture
Translated captions are the minimum. The best-converting localized pages also change what is inside the screenshots, so the product looks like it was made for that market. See our screenshot guide for the fundamentals, then adapt:
Localize
- Currency, number, date and time formats in demo data
- Names, places and examples that feel local
- Caption length: German and French often run longer, so plan the layout for it
- Right-to-left layouts for Arabic and Hebrew, mirrored where your app mirrors
Avoid
- English UI under a translated caption, which looks unfinished
- Text baked into art you can't re-export per language
- Idioms and wordplay that don't survive translation
- Holidays, gestures or imagery that only make sense in one culture
Design expectations differ, too. Some markets respond well to dense, information-rich frames, while others prefer one bold message. You don't have to guess. Look at the top-ranked apps in your category in that storefront, and once you have traffic, test the variants with Product Page Optimization, which supports localized treatments.
Prioritize markets you can actually win
You don't need all 50 locales on day one. Score each candidate market on two axes: opportunity (category demand, willingness to pay, how weak the local competition is) and effort (translation cost, support load, payment and legal fit).
Some practical heuristics:
- Start with English variants. English (U.K.), English (Australia) and English (Canada) are separate localizations. Adapting spelling and keywords ("colour", "organiser") costs little and is relevant to several storefronts that list English (U.K.) as an additional language.
- Follow your own data. App Analytics in App Store Connect breaks down impressions, product page views and downloads by territory. Countries that already download you without any localization are strong candidates.
- Look for competitive gaps. If the top apps for your main keyword in a market are English-only, a well-localized listing can stand out quickly.
- Consider support. Localizing invites reviews and emails in that language. Make sure you can respond, even with help from translation tools.
Five localization mistakes to avoid
Most localizations that don't perform fail for the same few reasons. They are all easy to avoid once you know them.
- Translating the brand name awkwardly. Keep your brand as it is and localize only the descriptive part of the name, for example "Driftly: Schlafgeräusche" in German.
- Copying the English keyword field into every locale. Unless a storefront's users really search in English, this wastes the field. Research local terms instead.
- Leaving fields empty. A localization with a translated name but no subtitle or keywords gives up most of its search value.
- Mixing variants. Spanish (Spain) and Spanish (Mexico), or Portuguese (Portugal) and Portuguese (Brazil), use different vocabulary. Write for the variant that the storefront lists.
- Forgetting updates. A localized page that still shows last year's UI or a feature you removed is a conversion problem and can become a guideline 2.3 problem.
A localization workflow that scales
- Lock the primary listing firstGet your primary-language name, subtitle, keywords and screenshots right. Every locale inherits its positioning, so fix the source before you multiply it.
- Write a short briefDescribe in one paragraph what the app does, who it is for, its tone and its top three benefits. Translators (human or AI) produce better work from a brief than from a list of strings.
- Research keywords per localeFind local search terms, check competing apps in that storefront, and choose a name and subtitle that read naturally to a native speaker.
- Write and validate the metadataDraft every field per locale within Apple's limits (30-character name and subtitle, 100-byte keywords, 170-character promo text) and avoid repeating words across fields within the same locale.
- Get a native reviewEven a 20-minute pass by a native speaker catches unnatural phrasing and embarrassing mistranslations.
- Localize screenshotsTranslate captions at minimum, and localize demo content for your top markets.
- Ship, then measureName, subtitle, keywords and screenshots change with a new app version (promotional text can be edited anytime), so bundle locale updates with a release. Then watch impressions and conversion by territory and iterate.
Measure, maintain, repeat
A localization is not something you do once. Your app changes, competitors change, and search behavior shifts. Build a light routine:
- After each release, check impressions and conversion rate by territory in App Analytics.
- Every quarter, re-check keyword rankings in each localized storefront and swap out terms that never moved.
- Update localized screenshots whenever the primary set changes, so no market shows an outdated UI.
- Translate "What's New" text and promotional text along with the release, not weeks later.
- Read reviews in each language. They are free keyword research and an early warning for translation problems.
Before you add a new market, it's worth getting a baseline. The free ASO score tool rates any App Store listing's metadata, and our introduction to ASO explains how localization fits with everything else that affects ranking.
Frequently asked questions
Do I need to translate my app to localize my App Store listing?
No. App Store metadata (name, subtitle, keywords, description, screenshots) is localized separately in App Store Connect. However, the Languages list on your product page comes from the localizations inside your app binary, so a translated listing for an English-only app should set expectations honestly.
How many languages does App Store Connect support for metadata?
Apple's App Store localizations reference currently lists 50 languages and locales for app metadata, from Arabic to Vietnamese, including several regional variants of English, Spanish, French, Portuguese and Chinese.
Does the US App Store use more than one localization?
Apple's localization reference lists English (U.S.) as the default for the United States and also lists additional supported languages such as Spanish (Mexico), Chinese, French, Korean and others. Apple does not document exactly how each additional locale affects search ranking, so test changes and measure before relying on it.
Which countries should I localize for first?
Start where your category already has demand and where you can serve users well: markets that share your app's language variants, large paying markets, and countries where competitors have not localized. Then expand based on your own App Analytics data by territory.
Is machine translation good enough for App Store metadata?
It is a good starting point, but keywords need to be researched per market rather than translated, and a native speaker should review the final text. Literal translations often miss the words local users actually search for.
