Guide

How to localize an App Store listing

By The Nexus Pivot. Last updated 13 August 2026.

This is the whole job, written so you can do it yourself without paying anyone. We also sell this as a service, and we would rather you read this first and decide you do not need us for three locales than buy a sprint you did not want.

Step 1 — Pick the locales before you touch anything

The most expensive mistake is localizing the wrong languages thoroughly. Do not start with "the big ones" by population; start with where your app already has evidence.

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 not the translation of your English words.

1. 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.
2. 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.
3. 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.
4. 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. Not a slogan. Use it for the terms that did not fit in the name.
• Keyword field (100 characters) — comma-separated, no spaces after commas, no repeats of anything already in the name or subtitle, no competitor names, no category names. Every wasted character is a term you did not rank for.
• Promotional text (170 characters) — not indexed for search, but editable at any time without review. Useful for seasonal or campaign copy.
• Description — not indexed for App Store search, 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.

If you cannot do all of them, 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

Never publish a locale you cannot read without checking it two ways.

• 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. If the apps returned are not recognisably your competitors, the keywords are wrong no matter how good the language is.
• Check character limits per locale. German runs roughly 30% longer than English, so a name that fit in 30 characters in English will very often not fit.
• 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, or a claim that cannot be substantiated. 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 does not alter what an English-speaking buyer sees, and a locale you have not filled simply 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. Do not repeat words that already appear in your app name or subtitle — they are already indexed, so repeating them wastes the budget. Do not add spaces after commas, because spaces consume characters. Do not include your category name or competitor brand names.

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 if I do not speak the 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, claims that cannot be substantiated, mentioning other platforms, or a description that promises features the app does not have in that region. 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 at which buying it makes sense, from us or anyone else. If you want to see how the routes compare, we wrote an honest breakdown of App Store localization services, including doing it yourself.