Translating and Localizing a Mobile App

What localization covers

Apple's localization overview defines it as "the process of translating and adapting your app into multiple languages and regions". Its String Catalog guide adds that "supporting multiple languages and regions is more than translating text". Android's localization guide lists what has to fit the user's locale: "text, audio files, numbers, currency, and graphics".

In practice a localized app has four layers:

• the interface text, including buttons, errors, notifications and empty states;
• formats for dates, times, numbers and currency, which the system can handle if the app uses its formatting tools;
• layout, which has to cope with longer words and, for languages such as Arabic and Hebrew, a mirrored screen;
• the store page, with its name, description, keywords and screenshots.

Keep every string out of the code

The single most useful step happens long before any translator is involved. Android's guide puts it plainly: "don't hardcode any strings." Every piece of user-facing text should live in the platform's string files, with a key the code refers to. Text baked into images counts too: Android says that if you generate images with text, you should put those strings in your string file "and regenerate the images after translation".

Translators also need context. Android recommends describing "the context in which the string is used" next to each string, and notes that "translations are less flexible in buttons than in text boxes".

Avoid building sentences from pieces in code ("You have" + count + "new messages"). Word order changes between languages; whole sentences with placeholders translate far better.

String Catalogs on iPhone

Apple's current tool is the String Catalog, a file called Localizable.xcstrings by default. The String Catalog guide says Xcode finds localizable text on its own: "Each time you build your project, Xcode updates your string catalogs with changes you make to localizable strings in your code." Most SwiftUI text inside views is localizable automatically.

The catalog shows each language's progress, marks new strings that still need translation, and can vary a string by plural or by device. You can translate in Xcode itself or export the strings and send them to a translator.

String resources on Android

Android uses resource folders. Default text goes in res/values/strings.xml and each language gets its own folder, such as res/values-fr/ for French. When the app runs, "Android automatically selects and loads the resources that best match the device."

The default file matters more than it seems. If a phone is set to a language you have not translated, Android falls back to the default strings. If that default file "is absent, or if it's missing a string that your app needs, then your app doesn't run and shows an error". The rule is simple: the default file contains every string; translated files may contain fewer.

Plurals are harder than they look

English has two forms: "1 item" and "2 items". Many languages have more. Android's string resources documentation says "the full set supported by Android is zero, one, two, few, many, and other". Its examples include Polish, which treats numbers ending in 2, 3 or 4 (but not 12, 13 or 14) differently, while "some languages (such as Chinese) don't make these grammatical distinctions at all".

Apple's String Catalog handles this with "Vary by Plural". Xcode adds the forms each language needs: One and Other for English, but One, Few, Many and Other when you add Russian.

Two practical points from Android's documentation: use plural strings only when the message shows the number, and where you can, avoid plurals altogether with neutral wording such as "Books: 1".

Right-to-left languages

Arabic, Hebrew, Persian and Urdu are written right to left, and people reading them expect the whole interface to mirror. Apple's right-to-left guidelines say system UI frameworks "support right-to-left (RTL) by default", so standard components flip on their own. The guidelines add rules that still need care:

• controls that move through screens in order flip, so "a back button must point to the right";
• the digits inside a number, such as a phone or card number, never reverse;
• "avoid flipping images like photographs, illustrations, and general artwork", because flipping can change their meaning.

On Android, Google's guide to supporting different languages and cultures asks apps to declare android:supportsRtl="true" and to "convert left and right to start and end" in layouts. Mixed text causes subtle bugs: an English address inside a Hebrew sentence can display in the wrong order unless the app wraps it with BidiFormatter.

Letting people pick the app's language

Not everyone uses their phone in one language. Android's per-app language preferences page notes that "multilingual users set their system language to one language—such as English—but they want to select other languages for specific apps". Since Android 13 users can choose a language for each app in system settings, and Android Studio can generate the needed configuration automatically from the app's resources. If the app has its own language picker, Google recommends moving it to the platform APIs so both places stay in sync.

Apple's right-to-left guidelines likewise note that people may choose a language "for their device — or just your app or game". When you test, Apple's Xcode scheme has an App Language option, so you can run the app in another language without changing the whole phone.

Testing before and after translation

Layout problems can be found before a single word is translated. Android's pseudolocales make the English text longer and accented (English XA) or reverse its direction (AR XB). Google says they "can help you make an RTL version of your app, even if you don't write or speak any RTL languages".

On iPhone, Apple's testing guide shows how to choose the app's language and region in the Run scheme. Android's guide suggests setting a test device to a language the app does not support, to make sure every default string is there.

After translation, people who speak the language should use the app. Apple's localization overview advises: "To get the best feedback on your translations, distribute your app to native speakers in the languages that you support", for example through TestFlight.

Localizing the store listing

The store page is localized separately from the app. Apple's App Store Connect help says languages there "are part of your app's metadata", which "differs from adding languages to your app in Xcode". If you add French, the French listing shows to people whose language setting is French, and "if no localization matches a user's language setting, the next most relevant localization is used". A new language starts with the primary language's screenshots and properties, "except for the description and keywords", which you write for it.

In Google Play Console, store listing translations are added under Store listing, with optional localized graphics. Google's translation help notes that without them, "your app's graphic assets show from the default language". Play Console can also translate app strings with Gemini "at no cost". It warns that if you choose right-to-left languages, you must "ensure your app is RTL-ready".

Localized keywords and screenshots also affect search. Our guide to app store optimization covers the listing fields, and multilingual websites covers the same questions for your website.

A checklist

• All user-facing text is in String Catalogs or strings.xml, including text in images and notifications.
• The default language file is complete; each string has a comment explaining where it appears.
• Sentences are whole strings with placeholders, and counts use plural variants.
• Dates, numbers and currency use the system formatters.
• Layouts use start and end, survive longer text and mirror correctly for right-to-left languages.
• The app has been run in pseudolocales or another language before translation, and by native speakers after.
• The App Store and Google Play listings have their own translated text and, where useful, localized screenshots.

Frequently asked questions

Can I use machine translation for my app?

It can be a starting point. Play Console can translate Android app strings with Gemini at no cost, and Xcode can generate translations in a String Catalog. Both let you review and edit the results, and Apple recommends getting feedback from native speakers before you release.

Are the app and its store listing translated separately?

Yes. The languages inside the app come from its String Catalog or strings.xml files. The App Store and Google Play listings are set up separately in App Store Connect and Play Console, with their own name, description, keywords and screenshots.

What happens if a phone uses a language my app does not support?

On Android the app falls back to its default strings, so the default file must contain every string or the app can fail to run. On the App Store, the next most relevant localization of your listing is shown, or your primary language.

Does a right-to-left language need a separate design?

Usually not. iOS and Android mirror standard layouts for languages such as Arabic and Hebrew. You still need to check custom layouts, directional icons and mixed text, and photos and illustrations should not be flipped.

Which languages should I add first?

Start where your users already are. Play Console may show translation recommendations based on install data for your app and similar apps. Your own analytics, support requests and target markets are other good signals.

Planning an app for more than one language? We build iPhone and Android apps together with the backend, API and admin dashboard behind them. See our mobile app development service and all our services, or email [email protected].