How to Manage App Store Metadata in Many Languages

Per locale, the App Store Connect API puts name and subtitle under app info localizations, and description, keywords, promotional text, What's New, support URL and marketing URL under version localizations. That is eight text fields, plus screenshots and previews.

The unit matters. A German or Japanese keyword list that looks short in characters can already be over 100 bytes.

1. Create a locale table. Rows are fields, columns are locales. Mark each cell as written, reviewed or stale.
2. Choose the source locale. Usually your primary language. Changes start there, then flow to others.
3. Keep one file per locale in version control, with the same field names in each. The same keys let a script compare locales.
4. Validate automatically. A script checks character limits and byte limits for every file and fails on any overflow. See the metadata limits tool for the numbers.
5. Review in the language. A native reader checks tone and meaning; the script cannot.
6. Mark dependent fields. A change to the English name may require changing the keyword field, because Apple advises not repeating words from the name, subtitle or category in the keywords.
7. Upload in batches. Push locales you changed, not the whole set; see metadata via the API.
8. Log every change. Date, locale, field, old value, new value, reason. Without it you cannot explain a rank change.
9. Review stale fields monthly. What's New and promotional text age fastest.

A hypothetical habit tracker, Streakly, has 12 locales. It has 12 x 8 = 96 text values. In one release it changes the English subtitle. The locale table marks the 11 other subtitles as stale, because they were written from the old one. Streakly updates the three highest-traffic locales first, leaves eight marked stale, and logs the dates. Two weeks later it compares rank in those three storefronts against the eight that kept the old subtitle, which gives a rough control group.

When Streakly adds a thirteenth locale, Apple's behavior matters: a new language starts with the primary language's screenshots and properties, except description and keywords. The table shows those two cells as empty, which is the correct "not written" state.

• Languages can be managed only when the app status is editable. Plan changes around versions.
• A shared name across locales is not guaranteed: names can be localized, but one name can be used for only one app per localization.
• No process replaces review by a speaker of the language.

An AI model is good at first drafts and at finding where a locale deviates from the source. It is risky when it writes unchecked text in a language nobody on the team reads. Give it the limits, the unit, the app's real feature list and the previous version, and review the result.

LocalASO covers 52 storefronts, each in the storefront's local language, and works per language: it can write the keyword field, name, subtitle, promotional text, description and What's New for each language of your app, using the AI you bring. Its MCP server lets your own AI tools read the saved listing with listing_get. See the localization docs and the Optimize docs.