App Store Connect Localization: Fields and Fallbacks

Updated September 8, 2026 · by Sardorbek Rakhimov

Apple treats App Store metadata localization separately from localizing your app binary in Xcode. A localized product page therefore does not, by itself, mean the app interface supports that language. Apple's localization documentation explains the distinction and the storefront behavior. ShipZen's editorial recommendation is to localize the listing only when the product and support experience can serve that audience; whether metadata or the binary comes first is a product decision, not an Apple rule.

The primary language and fallback behavior

The primary language is the metadata default when you have not provided localized metadata for a country or region. Apple does not document one universal, ordered fallback cascade. It says the language shown can depend on the storefront's supported languages, the user's device and system language settings, the localizations you added, and the primary language. If there is no match for the user's language, Apple may use the "next most relevant" localization. See Apple's worked English/French example and its country and region language table.

Choose the primary language carefully. To change it, Apple requires the new language to have been added to a previous version and approved by App Review, with approved screenshots for every supported platform (and additional screenshot requirements for custom product pages). Apple's current change procedure is the authoritative checklist.

What is actually localizable

Common localized product-page properties include the app name and subtitle (up to 30 characters each), plus version-level metadata and media: promotional text (up to 170 characters), description (up to 4,000 characters), keywords (up to 100 bytes in Apple's App Store Connect reference), What's New text for updates (up to 4,000 characters), screenshots, app previews, and certain URLs. Consult Apple's property matrix for the exact field, platform, localization, and editability rules rather than assuming every property behaves alike.

This compact view is a planning aid, not a replacement for Apple's matrix. “Editable without a new version” is deliberately narrower than “you can edit this screen”: it means Apple marks the property as editable at any time without submitting a version.

• Apple says languages can be managed only while the app status is editable.
• Promotional text can be updated without a new version. Description and other version metadata, including keywords, are governed by the relevant version's editable status.

The add-language copy trap

When you add a language in App Store Connect, Apple pre-fills it by copying screenshots and other properties from the primary language, except the description and keywords. That behavior is documented in Apple's add-language instructions. ShipZen's editorial advice is to treat those copied values as placeholders to review, not finished localization. A translated listing can improve relevance for that audience, while copied metadata may be less useful or even misleading; Apple does not promise a ranking lift from adding a locale.

Which locales to add first

The following is ShipZen's prioritization framework, not an App Store requirement:

1. Where users already are — use App Store Connect Analytics and territory filters to identify markets showing real discovery or download activity.
2. Where the current presentation is weakest — compare your primary language with Apple's storefront language table, then validate the opportunity with product and support data.
3. Depth before breadth — prefer a smaller set of carefully translated metadata, researched queries, and localized screenshots over copied placeholders across many locales.

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; or a translated subtitle exceeds Apple's 30-character limit and must be shortened before submission. A per-release locale review catches those differences before they reach App Review.

Illustrative review: a shared English string still needs a locale pass

This is an original, synthetic example, not a rule about which English locale Apple will show. The synthetic Weather Zen app starts with the same subtitle, Weather at a glance, in en-AU, en-CA, en-GB, and en-US. During review, the team leaves en-AU, en-CA, and en-US unchanged, but refines en-GB to Your weather, at a glance after checking its market language. The point is not that one phrase is universally better; it is that copied or shared strings deserve a deliberate per-locale decision. A ShipZen walkthrough shows this synthetic before-and-after pattern in the locale table.

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. Both the scanner and the cross-locale editor are free, and every edit shows a diff before anything is written to Apple.

Sources and verification

Verified September 8, 2026 against Apple's current localization instructions, storefront language reference, and field reference. Apple's pages support the documented rules and limits; locale prioritization and workflow recommendations above are ShipZen editorial guidance. Read how ShipZen verifies its guides and how ShipZen handles App Store Connect access.

© 2026 ShipZen. Not affiliated with Apple Inc. App Store, App Store Connect, TestFlight, and Mac App Store are trademarks of Apple Inc. · Home · Privacy · Terms