Key takeaways
- Apple says the App Store is available in 175 regions and 50 languages, and App Store Connect accepts metadata in 50 localisations.
- App names are limited to 30 characters on both the App Store and Google Play; Apple's keyword field is limited to 100 bytes, not characters.
- On Android, an app missing a default string resource will not run on a device set to an unsupported locale.
- Google Play's free store-listing machine translations are not reviewed or approved by humans.
- Testing with pseudolocales before translation catches hard-coded text and layouts that break when text grows.
This guide is for product managers and developers of iOS and Android apps who want to launch in new languages. It walks through the process from code preparation to release, and covers both the app itself and its store listing.
App localisation has two halves that are often handled by different people. The in-app text lives in your codebase, while the store listing lives in App Store Connect or the Google Play Console. Both need planning, and both affect downloads.
What does mobile app localisation include?
Mobile app localisation includes every piece of text, image and format a user meets, from the store listing to the last error message. A complete scope usually covers:
- interface strings, buttons, menus and onboarding screens;
- push notifications, emails and in-app messages;
- error messages, empty states and permission prompts;
- help content, FAQs and support macros;
- terms of use and privacy information;
- in-app purchase and subscription names;
- store listing text, screenshots and preview videos;
- dates, times, numbers, currencies and units.
How do you localise a mobile app, step by step?
Localising a mobile app follows the same ten steps whether you build for iOS, Android or both. Doing them in order avoids paying to fix the same problem twice.
- Choose your locales. Use download and revenue data by country to pick languages, and decide on variants such as Spanish (Spain) or Spanish (Mexico).
- Internationalise the code. Move all user-facing text into resource files, use the platform's formatters for dates and numbers, and allow layouts to grow.
- Run a pseudolocale test. Catch hard-coded strings and truncation before any translation is paid for.
- Export strings with context. Add a comment for each string explaining where it appears and any length limit.
- Create a glossary. Fix the translation of your product name, feature names and key terms.
- Translate and review. Use native-speaking translators, with a second linguist reviewing.
- Localise the store listing. Write keywords and descriptions for each market, within the character limits, and re-shoot screenshots in each language.
- Import and build. Bring the translations back into the project and build for each locale.
- Test on real devices. Check every screen in every language, including right-to-left languages if you support them.
- Set up continuous localisation. Agree how new strings will be sent, translated and returned for each release.
How do iOS and Android handle localisation?
Both iOS and Android separate translatable text from code, but they use different tools and file formats. Your translation provider needs to know which ones you use.
iOS: String Catalogs in Xcode
Apple's tooling extracts strings automatically. Apple explains that you "can use a string catalog to translate text, handle plurals, and vary the text your app displays on specific devices", and that Xcode can export "all localizable content" for translators (Apple Developer: Localization). Comments added to text views help translators understand where each string appears.
Android: strings.xml resources
Android stores text in resource files. Google's guidance is direct: "As you build your apps, don't hardcode any strings." It also warns that if the default strings file "is absent, or if it's missing a string that your app needs, then your app doesn't run and shows an error" (Android Developers: Localize your app). Always keep a complete default file, and add translated files for each locale.
How long can localised App Store and Google Play listings be?
Store listings have strict length limits, and translated text often needs rewriting rather than simple translation to fit. The main limits are:
| Field | Apple App Store | Google Play |
|---|---|---|
| App name | 2 to 30 characters | 30 characters |
| Subtitle or short description | Subtitle: 30 characters | Short description: 80 characters |
| Keywords | Up to 100 bytes | No separate field |
| Promotional text | 170 characters | No separate field |
| Description | 4,000 characters | Full description: 4,000 characters |
Sources: App Store Connect Help and Google Play Console Help. Google notes that its "Character limits apply to both full-width and half-width characters."
Apple's keyword limit is measured in bytes, not characters. In the common UTF-8 encoding, accented letters take two bytes and most Chinese, Japanese and Korean characters take three, so fewer keywords fit in those languages. Keyword research should be done separately for each market, as our guide to multilingual SEO explains for websites.
Which locales and language variants should an app support?
Choose app locales from your own user data first, then check how each store maps languages to countries. Apple says the App Store "is available in 175 regions and 50 languages", and its list of App Store localisations shows how variants are assigned.
For example, App Store Connect offers both Spanish (Spain) and Spanish (Mexico), and uses Spanish (Mexico) as the default for most Latin American countries. It also separates Portuguese (Brazil) from Portuguese (Portugal). Our article on Spanish for Spain vs Latin America explains how to choose.
Should you use the stores' built-in machine translation?
Store machine translation is quick and free, but it is not checked by people and should not be published unreviewed. Google Play offers instant machine translations for store listings with the warning: "As these are machine translations, they are not reviewed or approved by humans." (Google Play Console Help).
A store listing is a sales page. Errors in the first lines of the description or in screenshots reduce trust at the moment a user decides whether to install. If you use machine output, have a native speaker post-edit it and check the keywords.
Common mistakes in mobile app localisation
Most app localisation problems are visible within seconds of opening the app in another language. Watch for these:
- Hard-coded strings that stay in English in every locale.
- Concatenated sentences built from fragments, which break grammar in other languages.
- Fixed-width buttons that truncate longer translations.
- Screenshots left in English on a translated store listing.
- Keywords translated literally instead of researched in each market.
- No process for updates, so new features ship half-translated.
- Missing content ratings, which can block release; our article on game culturalisation covers age ratings for games and apps.
Developers will find string-level detail in our guide to software and UI string localisation. Games published as apps follow the wider process in our guide to video game localisation.
How TranslationWorks can help
TranslationWorks is a UK-based translation agency that localises mobile apps and their store listings, using native-speaking linguists in 150+ languages. Our IT and gaming translation team works with string files exported from iOS and Android projects, and our transcreation service adapts store descriptions, promotional text and screenshot captions for each market.
We are ISO 17100 certified, ISO 9001 and ISO 27001 registered and Cyber Essentials certified, so your unreleased features stay confidential. Send us your string files, current store listing and target locales, and we will reply with a free app localisation quote within 24 hours.


