How to localize your App Store and Google Play listing

Localizing a store listing looks like a translation job: copy the English text, run it through a translator, paste it into each language. In practice it is closer to writing a small listing from scratch for every market. Each store has its own fields and limits, Apple and Google treat languages differently in search, screenshots carry their own text, and the way a change goes live is not the same on the App Store and on Google Play. This guide walks through what each store gives you per language, where translation goes wrong, and a routine that keeps several languages in order.

Which fields each store has, and their limits

Both stores let you supply text per language. The fields and limits differ, and the limits apply to every language separately.

Store	Field	Limit	Notes
App Store	Name	30 characters	Changes with a new version
App Store	Subtitle	30 characters	Shown under the name in search results
App Store	Promotional text	170 characters	Can be changed at any time, without a new version
App Store	Description	4,000 characters	Plain text, no HTML
App Store	Keywords	100 bytes	Comma separated, not shown to users
App Store	What's New	4,000 characters	Required on every version after the first
Google Play	App name	30 characters
Google Play	Short description	80 characters	The first text on the listing
Google Play	Full description	4,000 characters	Google Play has no separate keyword field

Two details catch people out. First, Apple measures the keyword field in bytes, not characters. Latin letters take one byte each, but Japanese, Chinese, Korean, Arabic, Hindi and most other non-Latin scripts take several, so the same 100 bytes hold far fewer keywords in those languages. Second, a limit that is easy to meet in English is often tight in German, Finnish or Portuguese, where the same idea needs more letters. A 30 character subtitle rarely survives translation unchanged.

Keywords per language are not a translation job

The App Store keyword field is a list of search terms, not a sentence. Translating your English list word by word gives you terms that are grammatically correct and that nobody types. People in Brazil searching for a budgeting app use their own everyday words, which may not be the dictionary translation of "budget" or "expense".

Apple's own guidance on the field applies in every language: separate terms with commas and no spaces, do not repeat words already in your app name, subtitle or category, skip plurals of words you already have, and leave out filler words and generic terms such as "app". Names of other apps and companies are not allowed. So for each language, start from what users there search for, then remove anything the name and subtitle already cover. Treat the English list as a description of intent, not as source text.

Google Play has no keyword field. Search there draws on the text you publish, so the words people use need to appear naturally in the app name, short description and full description of each language. Google's metadata policy treats repetitive or irrelevant keywords as a violation, so a translated description padded with search terms is a risk, not a shortcut.

How Apple uses localizations across countries

Here it is worth sticking to what Apple documents, because a lot of advice about App Store search is guesswork.

Apple's help page on localizing app information says that a French localization is shown to users whose language setting is French, and also in countries or regions where the App Store supports French but not English. It also says users can search for your app using localized keywords in all countries or regions where the App Store supports French.

Apple's App Store localizations reference lists, for each country or region, a default language and additional supported languages. For example, the United States lists English (U.S.) as the default, with Arabic, Chinese (Simplified), Chinese (Traditional), French, Korean, Portuguese (Brazil), Russian, Spanish (Mexico) and Vietnamese as additional languages. Canada lists English (Canada) and French (Canada). Pakistan lists English (U.K.) and Urdu.

The practical reading: one localization can matter in more than one country, so it pays to check which languages Apple lists for the markets you care about before deciding which localizations to write. Apple does not publish how it weighs keywords from different localizations against each other, so be careful with any claim that goes further than that.

Two more documented behaviours are useful. When you add a language in App Store Connect, its screenshots and most fields start as copies of the primary language, except the description and keywords, which you must write. And if no localization matches a user's language, Apple shows the next most relevant one, and otherwise your primary language.

Screenshots per language and size

Screenshots usually contain text: captions, interface labels, sample data. A German listing with English screenshots looks half finished, and captions are often where the main message sits. Plan screenshots per language from the start, with captions short enough to survive longer languages.

App Store. Each device size takes 1 to 10 screenshots in JPEG or PNG, with no transparency or alpha channel. Apple groups sizes by display class: for example, the large iPhone display with Dynamic Island accepts 1320 x 2868, 1290 x 2796 and 1260 x 2736 pixels in portrait, and the 13 inch iPad accepts 2064 x 2752. You need at least one iPhone set, and a 13 inch iPad set if the app runs on iPad. If your interface looks the same across sizes and languages, App Store Connect scales the largest set down for smaller displays. Apple adjusts the required sizes when new devices arrive, so check the current screenshot specifications page before a release.

Google Play. Graphics are also set per language:

• App icon: 32 bit PNG, 512 x 512 pixels, up to 1 MB.
• Feature graphic: JPEG or 24 bit PNG without alpha, 1024 x 500 pixels.
• Screenshots: JPEG or 24 bit PNG without alpha, each side between 320 and 3,840 pixels, up to 8 per device type (phone, 7 inch tablet, 10 inch tablet, TV, Wear OS), and at least 2 in total.

How changes go live

This is the part that differs most between the stores, and it decides when you can fix a typo.

App Store. Most listing text belongs to an app version. You edit it on a version that is being prepared for submission, and it goes live with that version after App Review. On the version that is already live, the main text field you can still change is promotional text, which updates without a new submission. That makes promotional text the place for anything time sensitive, and it means a mistake in a translated description waits for your next version.

Google Play. There is no draft listing tied to a version. Store listing changes are treated like an app update and go through Google's review before they appear. Changes that need review collect under "Changes not yet sent for review" in Play Console, and are reviewed together. With managed publishing turned on, you decide when approved changes are published. Either way, a translated listing on Google Play is never just a quiet text edit.

Machine translation: useful, with a person in the loop

Machine translation, including the large language models most tools now use, is good at a first draft. Google Play Console itself offers free machine translation for store listings in a number of languages and notes that those translations are not reviewed by humans. Play can also show visitors an automated translation of your page in languages you have not provided, labelled as such.

The risks are predictable:

• Limits. A translation that reads well can still be 38 characters for a 30 character field, or more than 100 bytes of keywords.
• Literal keywords. As above, a translated term is not always the searched term.
• Tone and claims. A careful English sentence can become stronger in translation. "Helps you track" turning into "guarantees" is a store policy problem, not a style problem.
• Product names and interface labels. Feature names should match what users see in the app in that language, which a translator cannot know.
• Required wording. Subscription terms, health disclaimers and similar text should stay accurate in every language, not be paraphrased.

The rule that works: use machine translation for the draft, and have someone who reads the language check every field before it is saved. If you have no fluent reader for a language, it is fair to ask whether you are ready to support users in it.

A routine for several languages

1. Write the primary listing first and get it right. Every flaw in it gets copied.
2. Choose languages from where your users are, and check Apple's localizations reference for the countries you target.
3. Draft each language, then research keywords for it separately.
4. Check every field against its limit, in characters and, for App Store keywords, in bytes.
5. Prepare screenshots with translated captions in the sizes each store requires.
6. Have a person review each language, then save.
7. Keep a record of what changed and when, so you can compare and undo.

Doing this in AppForShare

AppForShare's store listing editor (Pro and Team) puts both stores on one page, using your own App Store Connect key and Google Play connection.

• App Store: name, subtitle, promotional text, description, keywords, what's new, support and marketing URL, and privacy policy URL, per language, with Apple's limits shown and enforced. Spaces after commas in keywords are removed. Only a version being prepared (or rejected) can change; on the live version only promotional text can change, by an Admin of the workspace, and it shows at once. You can add a language and start a new version, and Apple copies the last version's text and screenshots into it.
• App Store screenshots: PNG or JPEG files are sorted into the App Store size they match, transparency is flattened to white, up to 10 per size, with reorder and delete.
• Google Play: app name, short and full description and YouTube video link per language, plus the icon, feature graphic, screenshots per device type and TV banner. Because every Play save goes to Google's review, Play changes need an Admin of the workspace, and AppForShare never cancels changes already in review.
• AI translation: translate from one language into as many languages as you pick. It uses 1 AI action per language, picks keywords for each language rather than translating the list, and copies URLs and the video link. The result is shown for a person to read and edit, and it is never saved automatically.
• History: every field change is kept with the text it replaced, and "Put back" restores an older version of a field.

Translations do not promise better ranking or more downloads; they give you a reviewed draft faster. When the version is ready, the same page can send it for App Store review; see App Store submission.

Pro is $12 a month and includes 100 AI actions a month; Team is $39 a month with 500 actions shared by the workspace. Details are on the pricing page.