Mobile App Localization: Strings, Store Descriptions, and In-App Content

You launch the app, get your first reviews from Germany and Poland - “Translation is broken”, “Date format is wrong”, “Button text is cut off”. You thought running the UI copy through DeepL was enough. It wasn’t. Let’s break down what proper mobile app localization actually looks like, from strings in the codebase to App Store listings.

Localization is not the same as translation¶

Localization (l10n) is adapting your app for a specific market. Not just the text, but the entire user experience: date and number formats, currency, reading direction (RTL for Arabic and Hebrew), culturally appropriate images, local privacy requirements.

Translation alone is only half the job. Here’s why:

• The date 03/15/2026 means March 15th in the US. In Germany, the same string looks like an error or December 3rd
• The price “$29.99” for the American market becomes “27,49 €” for Germany - with a comma instead of a period and the symbol after the number
• A thumbs up emoji is positive in Europe, offensive in parts of the Middle East

According to Centus research, 87% of consumers won’t buy from English-only sites. The localization market reached $71.7 billion in 2024 and grows 7% annually. Gaming apps see 200-300% download increases in localized markets; e-commerce apps report 150% higher conversion rates with localized checkout.

Just 8 languages - English, Chinese, Spanish, French, German, Japanese, Portuguese, Arabic - cover 80% of the world’s online purchasing power. You don’t need to target 40 languages from day one, but the first 3-5 can meaningfully expand your addressable market.

Strings - the technical foundation of localization¶

Everything starts with strings - translation resource files stored separately from the code. The first and most important principle: no hardcoded text in the source code.

iOS: .strings, .stringsdict, and .xcstrings¶

iOS has three formats that evolved over time:

.strings (classic format)

Simple key-value pairs stored in *.lproj folders:

/* Confirm button */
"confirm_button" = "Confirm";
"welcome_message" = "Hello, %@!";

Each language gets its own folder: en.lproj/Localizable.strings, de.lproj/Localizable.strings. Simple format, but no pluralization or metadata support.

.stringsdict (for plurals)

XML format for strings with numbers, where the word form depends on quantity. Required when you need “1 message / 2 messages / 5 messages” - and that’s still relatively simple compared to what other languages need.

.xcstrings (Xcode 15+, the modern standard)

Introduced in Xcode 15, a JSON-based format that combines the strengths of .strings and .stringsdict in one file. Supports pluralization, device variants, translator comments, and translation state (new / translated / reviewed / stale). Migration is straightforward: select your .strings file → Editor → Convert to String Catalog. This is the format to use for new projects.

Android: strings.xml¶

On Android, all strings live in res/values/strings.xml:

<resources>
    <string name="confirm_button">Confirm</string>
    <string name="welcome_message">Hello, %s!</string>
    <plurals name="messages_count">
        <item quantity="one">%d message</item>
        <item quantity="other">%d messages</item>
    </plurals>
</resources>

Translations go into res/values-de/strings.xml, res/values-uk/strings.xml, etc. The system picks the right file based on device locale automatically.

Pluralization: harder than it looks¶

English has two plural forms: “1 message” and “2 messages”. But:

• Russian and Ukrainian: 4 forms (1, 2-4, 5+, plus a special form for 11-14)
• Arabic: 6 forms
• Japanese and Chinese: 1 form (no grammatical plural)

As SimpleLocalize explains:

Pluralization isn’t just about singular vs plural - it’s a complex linguistic feature that varies significantly across languages. Arabic has 6 plural forms, while Japanese has only 1. Your localization framework needs to handle all of these cases correctly.

This is why “You have ” + count + ” messages” (string concatenation) is a dead end. Word order differs across languages, and a split string can’t be translated grammatically. The right approach: one key with ICU Message Format or native plurals, and the translator fills in all required forms.

Store descriptions: App Store and Google Play - two different approaches¶

Once the app is technically ready for localization, you need to handle the storefront.

Apple App Store¶

The App Store supports 40 locales and requires manual upload of all metadata for each language - there’s no automatic translation.

What gets localized in the App Store:

A critical mistake: translating keywords literally. As AppLaunchpad notes, you should rebuild your keyword list from scratch for each country to reflect how users actually search in that language. Translating your existing keywords word-for-word means inheriting their SEO problems instead of finding better positions.

Screenshots are the most important conversion element. Most users never read the full description but will scroll through every screenshot. Localized screenshots with local-language text overlays and culturally relevant imagery deliver significantly higher CTR than generic ones.

Google Play¶

Google Play supports 70+ languages with some differences from the App Store:

Google Play offers automatic translation of descriptions - but that’s a starting point, not a finished result. Auto-translations are literal and lose the nuance that matters for conversion.

One important detail: both stores determine that your app is localized based on what locales and translations you uploaded via App Store Connect and Play Console, not from anything in the description text. Writing “available in 10 languages” in the description is wasted characters.

Minimum and full store localization¶

Minimum Viable Localization (MVL) - 1-2 weeks: just store metadata (name, description, keywords, screenshots). The goal is to launch in a new market and collect initial feedback before committing to full in-app localization.

Full localization - 4-8 weeks: metadata + all UI strings + QA testing on real devices.

In-app content: what else needs to be localized¶

Strings and store descriptions are only part of the picture. A real app has several more content layers.

Onboarding¶

The first screens after install are critical for retention. If onboarding looks like a machine-translated afterthought or is confusing, 60-70% of new users are gone within the first week.

But even a quality translation of your onboarding isn’t enough. A value proposition that resonates in the US (“Save time, save money”) might fall flat in Japan where reliability and safety are the key drivers. That’s cultural adaptation, not just translation.

Push notifications¶

Push notifications can be localized in two ways:

1. Localized keys (recommended for iOS): the payload includes a loc-key, and iOS looks up the translation from the .strings file on the device
2. Server-side localization: the backend sends fully translated text based on the user’s language setting

Beyond text, cultural adaptation matters: send time (what’s fine at 9pm in the US is 3am for users in Tokyo), tone (Japan and Korea prefer indirect, non-pushy messaging), and content (a Black Friday promo only makes sense where that holiday exists).

In-app purchases and subscriptions¶

Apple lets you localize the name and description of each in-app purchase through the App Store Connect API. “Premium Plan” sounds neutral in English, but a localized name in the user’s language can meaningfully improve conversion to payment.

Pricing also needs adaptation - and this isn’t just currency conversion. Apple and Google have tier-based pricing systems for different markets. $4.99 in the US maps to ¥680 in Japan not by exchange rate, but by purchasing power parity.

System messages and errors¶

“Error 404”, “Network error” - these are content users see too. English error messages inside an otherwise localized app immediately signal an unfinished product. Localize all user-facing messages: errors, hints, tooltips, empty states (“No results found”).

Common localization mistakes¶

Hardcoded strings in code¶

// Wrong
label.text = "Loading..."

// Right
label.text = NSLocalizedString("loading_label", comment: "Loading indicator text")

Hardcoded text is invisible to translators. This is the most common mistake in projects where localization was “added later”.

String concatenation¶

// Wrong - untranslatable
label.text = "You have " + String(count) + " messages"

// Right
label.text = String(format: NSLocalizedString("messages_count", comment: ""), count)

Word order differs across languages. A string split into fragments can’t be translated grammatically correctly no matter how good the translator is.

No context for translators¶

The string "OK" could be a delete confirmation button, a purchase confirmation, or just closing a modal - and the right translation differs in each case. Without a screenshot or comment, translators guess.

Not planning for text expansion¶

Different languages take different amounts of space compared to English:

The button “Save” (4 characters) becomes “Speichern” (9 characters). If the UI isn’t designed to accommodate expansion, text gets clipped or buttons deform.

No RTL support¶

For Arabic, Hebrew, and Persian, it’s not just text that goes right-to-left - the entire layout needs to mirror. The “Back” button moves to the right side, icons swap positions. iOS and Android both have APIs for this, but developers regularly forget to test RTL mode.

As Phrase points out:

RTL support isn’t just about flipping text direction - it’s about mirroring the entire UI, including icons, progress bars, and animations. When targeting Arabic or Hebrew speakers, test your app in RTL mode before release.

Tools for mobile app localization¶

Managing translation files by hand works for 1-2 languages. For 5+ languages and CI/CD, you need a TMS (Translation Management System).

Key features to look for:

• Over-the-air updates: push translation changes without submitting a new release to the App Store or Google Play
• GitHub/GitLab integration: automatic file sync on every commit - new keys reach translators automatically
• Context: screenshots or live preview for each key - translators see exactly where and how a string appears
• Plural editor: proper editing UI for plural forms in every target language

According to an independent Crowdin vs Lokalise comparison, Crowdin has the edge for open-source projects and heavy GitHub integration; Lokalise wins for product teams where mobile SDK and over-the-air delivery matter most.

How to run the process: continuous localization¶

Don’t localize after the app is “finished” - that’s the worst anti-pattern. The right approach is continuous localization, running in parallel with development.

Recommended workflow¶

1. i18n from day one: move all strings to resource files, set up date/number formatting via ICU/NSDateFormatter, design the layout with RTL in mind from the start
2. Connect a TMS: set up sync with your repo via GitHub Action or webhook - new keys automatically reach translators
3. Provide context: for every key, add a screenshot or description of where it appears
4. Order translation: machine translation as first draft + human post-editing for public-facing text (store description, onboarding)
5. QA on real devices: check every language, RTL layout, text truncation, dates and numbers, in-app purchases
6. Ship and monitor: reviews and ratings in new locales will tell you what was missed

One clarification: machine translation for technical strings (system messages, error messages) is fine - the quality is sufficient. But onboarding, store descriptions, and marketing copy need a human translator or at minimum careful post-editing. That’s where conversion happens.

FAQ¶

What’s the difference between i18n and l10n?¶

i18n (internationalization) is technical preparation: move strings to resource files, configure formatting, add RTL support. A developer does this once.

l10n (localization) is market-specific adaptation: translating strings, adapting screenshots, setting local prices, cultural adaptation. It’s an ongoing process for each new language.

Which languages should I localize first?¶

Follow your product data and market priorities. For English-language products, the usual first steps are Spanish, French, or German - large markets, familiar culture, many good translators. For Eastern European products, if you already have Ukrainian or Russian, English is typically next, then Polish or German.

8 languages cover 80% of purchasing power - don’t try to hit 40 markets at once.

Can I use only machine translation?¶

For technical strings and system messages - yes, DeepL or GPT-4 quality is sufficient. But for store descriptions, onboarding, and marketing copy, you need a human translator or post-editing. Machine translation at critical conversion points reduces trust and lowers CTR.

How much does mobile app localization cost?¶

Depends on content volume and number of languages. Rough estimates per language:

• Store metadata only: $150-400
• MVL (metadata + critical strings): $300-800
• Full localization of a medium-size app: $800-3000+

TMS tools: Crowdin from $25/month, Lokalise from $120/month.

Do push notifications need to be localized?¶

Yes, and not just the text. Pushes sent at the wrong time (due to timezone differences), with an aggressive tone that doesn’t fit the market, or with irrelevant content are a direct path to unsubscribe and uninstall. This is especially important for Japan and Korea, where communication norms are quite different from US defaults.

What if App Store rejects my screenshots for a localized version?¶

Check the App Store Review Guidelines for that specific country and adapt accordingly. For some markets (China, Saudi Arabia), content requirements differ significantly from the general rules.