Translating App Store Connect Metadata

You can have a perfectly localized iOS app and still lose the German market. The reason: a user in Berlin lands on your App Store page and sees English. Name, subtitle, description, screenshots — all English. They bounce.

The .xcstrings workflow handles everything inside your app. The App Store product page is a separate world. It lives in App Store Connect, has its own per-locale fields, its own character limits, and its own ASO mechanics. If you skip it, your in-app localization work mostly doesn’t matter — because users never get to the install.

This post is the field guide. What each ASC field is for, how it interacts with App Store search, and the workflow I use to translate it without doing 30 copy-paste sessions in App Store Connect.

What ASC localizes

For every locale your app supports, App Store Connect exposes these fields per app version:

Field	Limit	Visibility
App name	30 chars	Below icon, search results, lockups
Subtitle	30 chars	Below name, search results
Promotional text	170 chars	Top of description, editable without new build
Description	4,000 chars	Below screenshots
Keywords	100 chars	Not visible — search index only
What’s New	4,000 chars	Per version, on the update prompt
URL fields	n/a	Marketing, Support, Privacy URLs

There are also localized screenshots and app previews — those need their own pipeline (frame compositing, simulator screenshot automation), which is out of scope for this post.

Every field is per-locale and independent. You can have 20 fully-translated locales for name/subtitle and skip description on the long tail if your bandwidth is limited. Apple’s behavior: if a locale-specific field is empty, it falls back to your primary locale (usually en-US).

Why each field matters

It’s worth understanding how each one drives behavior, because the translation strategy is different for each.

App name. Single most important text element on your product page. Appears in search results, on the device home screen as the icon label, and in every system-level reference to your app. Three rules:

1. Keep it short. 30 chars is a hard limit but 20 is the sweet spot for visual hierarchy in search results.
2. Don’t translate the brand. “Cube” stays “Cube” in every locale. A common indie mistake: localizing the product name into Cyrillic or Kanji. Don’t.
3. You can localize a descriptor after the brand. "Cube — App Localization" in English, "Cube — App-Lokalisierung" in German. The brand anchors; the descriptor adapts.

Subtitle. Single line under the app name. 30 chars. Visible in search results. Critical for conveying value at a glance.

This is where I spend the most translation effort, because it’s where the most differentiation happens. The English subtitle “AI Localization for Xcode” needs to compress the same value into 30 chars of German, where the equivalent phrase is naturally longer. You can’t just translate it — you have to rewrite.

Promotional text. 170 chars, sits above the description. Updateable without submitting a new build, which makes it the perfect place for: “New: Claude 4 support — try it now.” Or seasonal pushes. Or A/B testing copy.

This is the only ASC text field you can change between builds. Use it.

Description. 4,000 chars of long-form copy. Below the screenshots. Most users don’t read past the first 2-3 lines, but search engines (Apple’s and indirectly Google’s) do.

Structure: open with the strongest value proposition, list features with line breaks, end with social proof or trust signals. Translate the structure, not just the words.

Keywords. This is the field that catches indie developers off guard.

100 characters of comma-separated terms. Not visible to users. Used exclusively by App Store search. Do not repeat words from your name, subtitle, or other fields — they’re already indexed. Do not add spaces after commas (wastes chars). Do localize per-locale — German keyword strategy is different from Korean, not just translated from English.

I’ll come back to keywords in detail below.

What’s New. 4,000 chars per version. Shows up in the “Update” prompt and on the product page after launch. Users actually read this on apps they care about — make it scan-able. Bullet list, line breaks, brief.

Localize this every release. The temptation to write it once in English and let it fall back is real; the cost is real too.

Keywords are not translations

This is the most important non-obvious thing in the post.

For all other ASC fields you’re doing translation: same meaning, different language. Keywords are different — you’re doing keyword research, per-locale, from scratch.

Why: search behavior is locale-specific. The German equivalent of “translate xcode strings” isn’t “übersetze xcode strings” — German developers search in a mix of English and German, and the actual high-volume queries depend on which terms are loanwords vs. translated.

Concrete example. English keywords for Cube (excluding what’s already in the title): localization,xcstrings,translate,ai,app store,metadata,ios,macos,gpt,claude.

A naive German translation: lokalisierung,xcstrings,übersetzen,ki,app store,metadaten,ios,macos,gpt,claude. Reasonable. But:

• German devs search for “xcstrings” and “iOS” in English anyway — those English terms belong in the German keyword list too.
• “AI” (English) often outranks “KI” (German) in technical contexts.
• “lokalisierung” is correct but long; “lokalisieren” (verb form) might be searched more.

The right approach: research the locale’s actual search terms, don’t translate from English. Tools like AppFollow, Sensor Tower, or App Radar give per-locale search volume estimates. Or — for indie scale — just look at competitors’ keywords and the autocomplete suggestions in App Store search within that locale.

If you’re using a translation tool, treat keywords as a separate step from name/subtitle/description. Most tools (Cube included) handle this by translating name/subtitle/description in one pass and treating keywords as a manual research step, optionally with AI-assisted brainstorming.

Character limits in non-Latin scripts

A subtle gotcha. Apple counts characters, not bytes or grapheme clusters in the simple sense. For most languages a “character” is what you’d expect. For CJK languages:

• Japanese: 30 characters is much more semantic content than 30 chars of English. A subtitle that’s tight in English fits comfortably in Japanese.
• Chinese: similar — each character carries more meaning. A 30-char English subtitle might be 12 characters in Chinese with the same meaning.
• Korean: in between. Hangul syllable blocks count as one char each.

For German, Russian, Finnish, and other naturally longer languages, 30 chars is brutal. Plan to rewrite, not translate.

If the translated subtitle blows the limit, the workflow is:

1. Drop adjectives.
2. Use shorter synonyms.
3. Rephrase as a noun phrase rather than a sentence.
4. As a last resort, drop a feature from the subtitle and surface it elsewhere.

My workflow

For Cube I run this end-to-end in about an hour per release. The split:

Once, when setting up a new locale (~10 min per locale):

1. Add the locale in App Store Connect (App Store tab → Localizations → +).
2. Translate name (if applicable) and subtitle — usually requires 2-3 rewrites to fit char limits.
3. Translate description (long-form, AI-translated then reviewed).
4. Research keywords from scratch (15 min for a top-priority locale, 5 min for long-tail).
5. Save.

Per release (~20 min total across all locales):

1. Write What’s New in English (3-6 bullets).
2. AI-translate to all locales in one batch.
3. Spot-check 2-3 top-revenue locales for register and naturalness.
4. Push to App Store Connect.

The tooling matters here. Doing this in the App Store Connect web UI for 20+ locales is slow and error-prone — every save is a network round-trip and the field-by-field navigation is built for one locale at a time.

I use Cube for both ends of this: the in-app .xcstrings translation and the App Store Connect metadata. Same project, same glossary, same model, same review pass. The ASC integration uses the App Store Connect API directly — pulls all current locale data, lets me edit/translate in a grid, validates char limits inline, and pushes back. The metadata never lives on a server.

Other tools that handle the ASC side: ASO.dev, AppDrift. The TranslateR CLI handles .xcstrings only, not ASC. If you’re not using a tool, you can hit the App Store Connect API yourself — app-store-connect-cli (now asc) supports asc metadata pull and asc metadata push for round-tripping the metadata as files you can edit/translate locally.

Common mistakes

A short list of the ones I’ve made or seen.

Localizing the brand name. Don’t translate “Cube” to “Куб” or “立方体”. Brand stays brand. The exception is when your brand name is a generic word in English that has a clear localized form, and you want that — rare.

Translating keywords instead of researching them. Covered above. Each locale needs its own keyword list, derived from how users in that locale actually search, not from your English list run through a translator.

Forgetting What’s New. Every release. If you have 20 locales and you only update English, 19 locales see stale “What’s New” content on the App Store. Apple may even reject this as a metadata issue.

Wrong locale for the wrong market. App Store Connect distinguishes pt (Portuguese, Portugal) from pt-BR (Portuguese, Brazil). They’re different markets, different vocabularies, different audiences. Same for es-ES (Spain) vs es-MX (Mexico) — or use the generic es if you want one Spanish for all. Same for zh-Hans vs zh-Hant.

Description without structure. A 4,000-char wall of text in any language is unreadable. Use line breaks, bullet points (just dashes or •), and short paragraphs. Translate the formatting, not just the words.

Promotional text never updated. This is the one field you can change without a new build. Most apps set it once at launch and forget. It’s free A/B testing real estate — use it.

Long-form translation without a review pass. A 4,000-char description run through an LLM produces readable output but will have register inconsistencies and occasional awkward phrasing. The cost of a 10-minute native review per locale is much smaller than the cost of a description that reads as machine-translated to a native speaker.

Wrap up

App Store metadata localization is the part of internationalization that indie developers most often skip, because it lives outside the codebase and Xcode doesn’t remind you to do it. The payoff is real — for most apps, properly localized ASC metadata is the difference between 5% non-English revenue and 25% non-English revenue.

The workflow scales with the right tools. Manually, it’s painful at 5+ locales. With automation it’s an hour per release for 20+ locales.

If you’ve already done the .xcstrings work — and if you haven’t, start there — this is the next high-leverage move. Ship your store page in the same languages your app speaks. Otherwise you’re doing half the job.