Localizing your iOS app on App Store Connect: the 40-locale workflow.

The locale list

Apple's supported App Store locales have shifted slowly over the years but sit around forty in 2026. Verify the current list for your specific app under App Information → Localizable Information in App Store Connect; Apple sometimes gates availability on region and category.

The commonly supported codes include:

Treat this as an indicative list. The exact set of localizable codes available to your app is rendered in the App Store Connect UI; check there for the canonical list when you plan a localization pass.

How App Store locale fallbacks work

When a user opens the App Store in a specific storefront, Apple resolves which locale to display by walking a fallback chain:

1. Exact match. If the storefront is fr-CA and you have fr-CA metadata, that's what the user sees.
2. Language-only match. If you don't have fr-CA but you do have fr-FR, Apple falls back to fr-FR. Same for en-AU → en-GB → en-US.
3. Primary locale. If no language match exists, Apple falls back to your primary locale (typically en-US).

The primary locale is set when you create the app. It's usually en-US but can be any locale. The primary locale is special in two ways: (1) you cannot delete it, and (2) for search indexing in regions that fall back to it, the primary locale's keyword field is what users actually search against.

Practical implication: your en-US (or primary locale) metadata must be strong because it's the default experience for every user whose locale you don't explicitly support.

What is localizable per locale

Each locale in App Store Connect gets independent versions of:

• App name (30 characters)
• Subtitle (30 characters)
• Promotional text (170 characters)
• Description (4000 characters)
• Keyword field (100 characters, not user-visible)
• Screenshots (up to 10 per device class)
• App preview videos (up to 3 per device class)
• What's New (release notes) (4000 characters, per version)
• Marketing URL
• Support URL
• Privacy policy URL
• Custom product pages (screenshots, app preview, promotional text)

What is not localizable:

• Pricing (set via territory, not locale)
• Availability (territory-based)
• Primary/secondary category
• Age rating questionnaire
• Content rights declaration
• App icon (one icon for all locales)

Full versus partial localization

Full localization — metadata, screenshots, and the app UI in the locale's language — is the ideal. It's also expensive, especially for 40 locales. A pragmatic tiered approach:

Tier 1: Core revenue markets (5-10 locales)

Fully localize everything: metadata, screenshots, app UI, release notes. Typical inclusion: en-US, en-GB, de-DE, fr-FR, ja-JP, ko-KR, zh-Hans, zh-Hant, es-ES or es-MX, pt-BR. This is where most apps make most of their money, and the ROI on localization is highest here.

Tier 2: Growth markets (10-15 more locales)

Localize metadata (name, subtitle, description, keywords) and screenshots. App UI can stay in your fallback language. This captures ASO benefits (keyword indexing in the local language drives install volume) without the engineering cost of full in-app localization.

Tier 3: Long-tail (everything else)

Leave on en-US fallback. The incremental install volume from localizing every remaining locale rarely justifies the translation and maintenance cost.

Translate the app or just metadata?

A user tapping Install on a German storefront after seeing German metadata expects to launch into a German app. If the app is English-only, the first-impression gap hurts retention immediately.

Rules of thumb:

• If install volume is your current bottleneck (for example, you're trying to grow in a new region and have capacity to handle churn): metadata-only localization is acceptable as a first step.
• If retention or revenue is your bottleneck: localize the app UI. A metadata-localized, English-UI app has noticeably worse retention curves in non-English markets.
• If your app has minimal UI text (games, creative tools, media playback): app-level localization is cheap and worth doing even for Tier 2 locales.
• If your app is text-heavy (reading, note-taking, productivity): full app localization is an engineering commitment. Scope carefully.

Right-to-left: Arabic and Hebrew

Arabic (ar-SA) and Hebrew (he) App Store pages render right-to-left. Apple handles RTL layout at the page level — text flows right-to-left, and navigation affordances flip. You need to make sure the content you upload fits:

• Screenshots should be captured from the RTL-configured version of your app. A UI that's laid out left-to-right looks backwards in the RTL preview.
• Captions on screenshots should be right-aligned and reading right-to-left.
• Screenshot order reads right-to-left in the App Store preview; the first screenshot shows at the right edge of the visible triplet, not the left. Order your screenshot sequence accordingly, or check how your set renders in App Store Preview before publishing.
• Description and release notes should be written in Arabic or Hebrew, respectively. Don't leave English text that gets reversed by the RTL renderer and becomes unreadable.

If your app itself supports RTL (correct semantic mirroring of layouts, not just translation), the localization is dramatically more valuable. An English UI with Arabic captions on screenshots reads as incomplete; a fully RTL Arabic app with matching screenshots reads as native.

CJK character density

Apple counts characters in UTF-16 code units for the field limits (30 / 30 / 170 / 4000 / 100 / 4000 for name / subtitle / promo / description / keywords / what's new). Most CJK characters occupy one UTF-16 code unit. That means a Chinese description holds roughly 4000 actual characters — significantly more information than 4000 English characters, where you are constrained by spaces and word length.

This has consequences:

• Translate your description in full for CJK locales; don't just cram a translated English description in. You have room for much more.
• The 30-character app name and subtitle limits are comfortable in English but extremely tight in CJK (a single Chinese character can stand for an English word). Write CJK names and subtitles from scratch rather than translating word-for-word.
• Keyword field: the 100-character budget holds vastly more keywords in Chinese, Japanese, or Korean. Use the density — tokenization in CJK is internal to Apple's index, and you have room for many more terms than you'd fit in English.

Keyword localization is search-critical

Each locale's keyword field is searched only when the user's storefront is that locale. A French user on the fr-FR storefront searches against the fr-FR keyword field, not en-US. So your English keyword research doesn't translate to other storefronts.

Don't just translate the English keyword field into French. Research the actual search terms French users type into the App Store. A French user looking for a budget app types budget or argent, not budgeting. The App Store's own autocomplete on a French-configured device reveals the local vernacular. See the keyword strategy guide for the full locale-specific research workflow.

Seasonal and regional content

Different markets have different calendars. Some examples worth building into your localization workflow:

• Lunar New Year is the dominant gifting/shopping period in CJK markets, not Christmas.
• Diwali drives retail activity in India (October-November), typically a larger spike than Christmas.
• Ramadan shifts consumer behavior in MENA locales; food, fitness, and meditation apps see strong seasonal demand.
• Back-to-school in the US is August-September; in Australia it's late January-February.
• Tax season in the US runs February-April; in the UK it's January-early February; in Australia it's July-October.

Update promotional text per locale to align with local seasons. Because promotional text doesn't require a new version, it's the lightest-touch localization surface you have. A German user seeing a Lunar New Year promotion will tune out; the same user seeing a German-language Christmas promotion converts.

A realistic workflow

For a team supporting 15 locales through a quarterly release cadence, a workflow that scales:

1. Maintain a single source of truth. A spreadsheet or JSON file with one column per locale, one row per field. Changes flow from source into App Store Connect, not the other way.
2. Translate once per quarter. Core metadata (description, subtitle) changes rarely; translate it once per quarter and reuse.
3. Update release notes per locale per version. This is the frequent, small translation task. AI-assisted translation with a human review pass is the most cost-effective pattern here — machine translation quality is good enough for most release notes, and a native-speaker reviewer catches the 5% that's off.
4. Refresh screenshots annually or when UI changes significantly. Screenshot re-capture across 15 locales is expensive; do it in batches tied to major UI changes.
5. Use a tool that surfaces all locales side-by-side. App Store Connect's web UI requires clicking into each locale individually — painful for comparative editing. AppConsul's metadata editor renders locales as tabs with cross-locale copy, missing-translation warnings, and diff views.

Frequently asked questions

How many App Store locales does Apple support?

Around 40, evolving over time. Verify the current list in App Store Connect under App Information.

What is the master fallback locale?

Your primary locale, usually en-US. Apple falls back to it when no language-level match is available for the user's storefront.

Do I have to translate screenshots per locale?

No, but it meaningfully improves conversion in non-English markets. Screenshots fall back to your primary locale if you don't upload per-locale sets.

Which fields are localizable?

Name, subtitle, promotional text, description, keywords, screenshots, app preview videos, What's New, marketing URL, support URL, privacy policy URL, and custom product pages. Pricing, availability, category, icon, and age rating are app-wide.

Should I translate the app itself?

For Tier 1 revenue markets, yes. For Tier 2 growth markets, metadata-only is acceptable as a first step. For Tier 3 long tail, fallback to the primary locale.

How does RTL work for Arabic and Hebrew?

Apple applies RTL layout automatically. Your screenshots should be captured from an RTL-configured app, captions should be right-aligned, and the description should be in Arabic or Hebrew.

Does Apple count CJK characters like Latin characters?

Apple counts UTF-16 code units. Most CJK characters occupy one code unit, so 4000-character limits allow approximately 4000 CJK characters — much more information than 4000 Latin characters.