App Store Connect Localization: Fields and Fallbacks

Updated July 12, 2026 · by the Shipzen team

Localizing your App Store listing is a different project from localizing your app: the metadata languages you manage in App Store Connect are independent of the languages in your Xcode project, and you can ship one without the other. Listing-first is usually the right order — it changes what storefront visitors see without touching a single binary string. Here is how the machinery actually behaves, including the two traps Apple's defaults set for you.

The primary language and the fallback cascade

Every app has a primary language, and it is the worldwide default. When a user browses your listing, the App Store resolves which localization to show in order:

A localization matching the user's language setting, if you have one.
Otherwise, a localization in a language the user's storefront supports.
Otherwise, your primary language — everywhere else on Earth.

Apple's own example: English-only metadata shows in English in every country. Add French, and it shows to users whose device language is French — and also in countries whose storefront supports French but not English. The practical consequence: a small number of well-chosen localizations covers a disproportionate share of storefronts, because the cascade does the routing.

Choose the primary language carefully: you can only change it later to a language that already shipped in an approved version, and a change requires approved screenshots in the new primary language first.

What is actually localizable

Per locale, the listing carries its own app name (30 characters), subtitle (30), keyword field (100), promotional text (170), description, What's New notes, screenshots, and app previews. Two timing rules from Apple's docs worth planning around:

Languages can only be managed while the app status is editable — not mid-review.
Promotional text is the one field you can update any time without a new version; keywords and description ride with version submissions, per locale.

The add-language copy trap

When you add a language in App Store Connect, Apple pre-fills it by copying screenshots and most properties from the primary language — except the description and keywords. That default creates the most common localization defect in the wild: a "localized" listing that is really English metadata wearing a locale label, plus empty or stale fields nobody went back to fill. If you add a locale, budget the work to actually translate it; a copied listing earns none of the keyword-surface multiplier and reads as neglect to native speakers.

Which locales to add first

Where your users already are — App Store Connect's analytics by territory tell you where downloads happen despite the missing localization. That demand is the cheapest to convert.
Storefronts your fallback doesn't reach well — markets where the storefront doesn't support your primary language get the most lift from a native listing.
Depth before breadth — a fully translated listing (keywords researched natively, screenshots captioned) in three locales beats a copied shell in fifteen.

Keeping locales healthy after every release

Localization drift is a release-cycle problem: v1.4 updates the en-US description and nobody touches de-DE; a new feature renames a flow and four locales still promote the old name; a translated subtitle quietly exceeds 30 characters and blocks the next submission. Checking means opening every locale, one page load each, every release — which is why it doesn't happen.

Where Shipzen fits

Shipzen, a native macOS App Store Connect client, runs a locale health scanner across every language at once: untranslated and copied fields, missing content, and per-locale character violations, in one table instead of N page loads. The scanner tier is free forever, and edits happen in a cross-locale editor with a diff before anything is written to Apple.

App Store Connect, the way you need to see it. One email at launch, no spam.

Join the waitlist