Guide
How to localize an App Store listing
This is the whole job, written so you can run it yourself. We run the same process on listings every week and sell it as a sprint — 25 languages as standard — for teams who want it handled end to end. For two or three locales, this guide is all you need.
- App Store Connect supports 50 languages and locales. Adding them is free.
- Listing localization needs no code change — but the fields go live with a version update.
- Do keyword research per locale before writing anything. This is the step that decides whether it works.
- Fill name, subtitle, keywords, promotional text, description — then screenshots for your best locales.
- Back-translate and search-test every locale before publishing.
Step 1 — Pick the locales before you touch anything
The most expensive mistake is localizing the wrong languages thoroughly. Start with where your app already has evidence, rather than with the biggest languages by population.
Open App Store Connect and read your existing installs and impressions by country. A country already sending you traffic on an English-only listing is telling you demand exists despite a language barrier — those are your first locales, not the theoretical giants. We cover the selection method properly in which App Store locales to localize first.
Step 2 — Add the language in App Store Connect
In App Store Connect, open your app and use the language selector to add a localization. App-level fields such as the app name sit under App Information, while version-level fields — description, keywords, promotional text and screenshots — sit on the version page. Languages can only be managed while the app is in an editable state. Pick the exact locale rather than the generic language where Apple offers both — Portuguese (Brazil) and Portuguese (Portugal) are different stores with different vocabulary, as are Spanish (Mexico) and Spanish (Spain), and the four English variants.
Check what App Store Connect pre-filled before you start typing. Some fields are copied from your primary language rather than left blank, and copied English screenshots will publish as that locale's screenshots if you leave them in place — that is the most common way a "localized" listing ships half in English. Nothing you do in a new locale affects buyers in your existing ones.
Step 3 — Research keywords for that locale, before writing
This is the step that separates a listing that ranks from a listing that merely reads well. You are looking for the words real buyers in that market type, which are frequently different words from a translation of your English ones.
- Start from the job, not your copy. Write one plain sentence describing what someone hires your app to do, then have that sentence translated. You want the local vocabulary for the problem, not for your marketing.
- Switch your App Store region to that country and search those terms. The autocomplete suggestions are real query data — they are the closest thing to a free keyword tool Apple gives you.
- Read your competitors' localized listings in that store. The terms appearing in the names and subtitles of the top few apps are the terms that market has settled on.
- Check for compounds and synonyms. German compounds several concepts into one word; Japanese mixes scripts for the same term; Brazilian Portuguese and European Portuguese diverge on technical vocabulary. Where two forms both look correct, prefer the one that shows in autocomplete.
Step 4 — Write the fields, in priority order
Apple weights these fields very differently. If you run out of energy, run out at the bottom of this list, not the top.
- App name (30 characters) — the most heavily weighted field. Keep your brand, localize the descriptor after it.
- Subtitle (30 characters) — second most weighted. Treat it as ranking space rather than a slogan, and use it for the terms the name had no room for.
- Keyword field (100 characters) — comma-separated with no spaces, each term used once, category and competitor brand names left out. Every wasted character is a term you could have ranked for.
- Promotional text (170 characters) — editable at any time without review, and it sits outside search indexing. Useful for seasonal or campaign copy.
- Description — outside App Store search indexing, so write it for the human deciding whether to tap Get. Front-load the first three lines; that is all most people read before the fold.
Step 5 — Localize screenshots for your strongest locales
Screenshots do more for conversion than any text field, and they are the part people skip because they need design work rather than typing. The text burned into the artwork has to be replaced per locale, matching your existing layout and type.
Do fewer locales properly rather than all of them with English screenshots. A page whose words are translated but whose images are still English reads as automated, and buyers notice.
Step 6 — Verify before you publish
Check every locale two ways before you publish it.
- Back-translate each field using a different engine than the one that produced it, and read for meaning drift rather than grammar. Inverted meaning and lost negations are the failures that survive a grammar check.
- Search-test your chosen keywords in that country's store. The apps that come back should be recognisably your competitors; anything else means the keywords are wrong, however good the language is.
- Check character limits per locale. German runs roughly 30% longer than English, so budget extra room for a German name that fits comfortably in English.
- Read the fields in context on the rendered product page, not in the form. Truncation only shows up on the page.
Step 7 — Submit, and expect the odd metadata rejection
Localized metadata goes to review with your next version, and metadata rejections are common and not a crisis. The usual triggers are keyword stuffing, naming a competitor, mentioning other platforms, and unsupported claims. A rejection normally names one locale and one field; edit it and resubmit.
Frequently asked questions
Do I need a new app release to localize my App Store listing?
No new binary, but most fields do go live with a version submission. Listing metadata is attached to your App Store product page rather than to the app binary, so localizing it needs no code change and no SDK. Promotional text is the one field Apple lets you update without submitting a new version; name, subtitle, keywords, description and screenshots go live with a version update and are reviewed alongside it. Localizing the app's own interface is a different job and does require a new build.
Does adding a localization affect my existing English listing?
No. Each locale is a separate set of fields. Adding German leaves an English-speaking buyer's page exactly as it was, and any locale you leave empty falls back to your primary language. This makes localization unusually low risk — the downside of a bad German listing is limited to German buyers, and you can revert it.
How long is the App Store keyword field?
100 characters, comma-separated, per locale. Use each word once: anything already in your app name or subtitle is indexed, so repeating it wastes the budget. Separate terms with a comma and no space, because spaces consume characters. Keep category names and competitor brand names out of the field.
Should I translate my app name?
Usually keep the brand name and localize the descriptor around it. If your listing name is "PDFPivot: PDF Editor", the brand stays and the descriptor becomes the local phrase buyers actually search. Translating the brand itself fragments your identity across stores and breaks word-of-mouth, while leaving the descriptor in English throws away the single most heavily weighted ranking field you have.
How do I check a translation in an unfamiliar language?
Back-translate every field with a different engine than the one that produced it and read the result for meaning drift, then search your chosen keywords in the App Store with the store region switched to that country and check that the apps returned are actually your competitors. If the results look unrelated to your app's job, the keywords are wrong regardless of how good the grammar is.
Can Apple reject localized metadata?
Yes, and metadata rejections are among the most common. The usual causes are keyword stuffing, naming competitors, unsupported claims, mentioning other platforms, or a description promising features the app ships only in other regions. A rejection normally affects one locale and is fixed by editing that field and resubmitting.
When this stops being worth doing yourself
Everything above is genuinely doable for two or three locales in an afternoon. It stops scaling at roughly a dozen, where per-locale keyword research and screenshot re-composition turn into a production job — and that is the point where buying it makes sense, from us or anyone else. Our sprints run at that scale as routine work, shipping 25-language listings as standard. For a route-by-route breakdown, read our comparison of App Store localization services, including doing it yourself.