App Localization: The Complete Guide for Indie Developers

App localization is adapting an app so another locale can actually use it — UI copy, plural and gender rules, placeholders, date, number and currency formats, layout direction, and the store listing. Translation is the visible part. The engineering part is getting strings out of code and into a format that can express those rules without breaking at runtime. The store-side surface got bigger in 2026: Apple's App Store Connect now supports 50 metadata localizations, up from 39 on 31 March 2026, and Google Play Console lists 52 languages. None of that makes "50 languages" a to-do list. The work worth doing is choosing a few locales on purpose, picking the right file format for your stack, and paying for translation in a way that does not commit you to a monthly bill.

Pick languages from economics, not from the locale picker

Apple and Google will happily let you add dozens of localizations. A solo developer should not. Language choice is a budget and a support commitment, and the only figures that belong in it are published ones.

Global consumer app spend in 2024 was $127bn — $91.6bn on the App Store and $35.7bn on Google Play. The United States led at roughly $47.6bn. Brazil was the fastest-growing market at +73% year over year. That is the entire numeric picture; everything past it is inference, and it is more honest to keep inference qualitative.

1. Ship a clean source locale first. For most indie apps that is English. If the English strings are ambiguous, every translation inherits the ambiguity and you pay for it in every language at once.
2. Localize where you already have users. Your store analytics beat a world map. A language with real sessions and real support mail is worth more than a language that merely exists in App Store Connect.
3. Treat Brazilian Portuguese as the one speculative bet with a number attached. Brazil's +73% year-over-year growth is the only growth rate in this data. If you are adding a locale on speculation, pt-BR is the one you can justify without inventing market share.
4. Weight the App Store over Play if you can only afford one metadata pass. $91.6bn against $35.7bn is not a subtle gap. That is not a reason to skip Play; it is a reason the first listing budget goes to Apple.
5. Do not read Apple's 2026 expansion as demand. The eleven added localizations were Bangla, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Slovenian, Tamil, Telugu and Urdu, and eight of them are languages of India. That makes listing in those languages possible. It says nothing about spend. The full language list and a first-pass ordering goes through this properly.

Operational constraints cut the list further. If you cannot read support email in a language, or your privacy and legal text is English-only, a full UI translation ships a product you cannot actually operate. Listing-only localization is the cheap way to test a locale without taking that on.

Right-to-left locales and text expansion are real costs, but they are implementation costs rather than market-size arguments. German and Finnish strings routinely run 40–60% longer than English; Arabic and Hebrew need a layout pass, not just a string pass. Budget for them — but pick the language because you have users who read it.

File formats: how each stack stores plurals and placeholders

Externalise every user-visible string. Hard-coded copy is the single thing that makes later localization expensive. After that, the format decides whether plurals, substitutions and comments survive a round trip through a translator or a script. The file formats guide covers conversion between them; this is the shape of the decision.

Rules that hold across all of them:

• Never concatenate sentences in code. Word order changes between languages; a sentence assembled from fragments cannot be reordered by a translator.
• Prefer named or explicitly positional placeholders. Reordering arguments is normal in German and Japanese, and a bare %s gives the translator nothing to reorder.
• Comment anything with a placeholder, a unit, or a product-specific noun. .xcstrings comments, Android XML comments and ARB @key.description all exist for this, and translators genuinely use them.
• If you have a raw .strings file and any quantity in the UI, fix it. Add .stringsdict or migrate to a String Catalog. English "1 item / N items" is not a plural system, it is a special case that happens to work in English.
• Keep one source locale canonical. New copy should never be born in a translated file.

What it costs, without a sales call

There are four ways to pay, and two well-known vendors still will not show you a number.

Pricing checked 28 August 2026 on each vendor's own pricing page. Sources: Lokalise, Crowdin, Localazy, SimpleLocalize, String Catalog, OneSky, Blend, Phrase, Smartling

Read that table as a warning about idle seats rather than a claim that those tools are bad. Lokalise, Crowdin, Localazy, SimpleLocalize and String Catalog are built for teams who live inside a translation workflow, and if that is you they are worth the money. Phrase and Smartling declining to publish a price is itself useful information: if reaching a number requires a sales call, you are not their intended customer. Per-word human translation between $0.005/word and $0.12/word is the honest cost of a careful pass.

One-time credits invert the subscription model: you pay for strings times languages, once. A 200-key catalogue into eight languages is 1,600 strings of work, not a year of $144/mo per month. Add twenty keys next quarter and you buy more credits instead of reopening a subscription. The full cost breakdown works the arithmetic through for real app sizes.

Listing first, binary second

Two different jobs get lumped together under "app localization", and they should not be.

Store listing localization is metadata: name, subtitle, description, keywords, what's-new, screenshots. It lives in App Store Connect and Play Console, never ships inside the IPA or AAB, and it affects search and conversion for people who do not have your app yet.

Binary localization is every string in the running app — onboarding, settings, errors, paywall, notifications, permission purpose strings, plurals, RTL layout. It lives in your .xcstrings, strings.xml, .arb or JSON, and it has to be right or the UI breaks.

For a solo developer, localize the listing first, for reasons that are not marketing:

• The listing is a small, bounded set of fields. The binary is every string you will ever write.
• A localized listing can convert someone who then happily runs an English UI. The reverse almost never happens — nobody finds an English-only listing in a Japanese search and then thanks you for the translated settings screen.
• You can test a locale with metadata alone, watch what downloads do, and only then spend on the string catalogue.
• Permission strings, purchase copy and legal text carry review and policy risk if you get them wrong. Listing experiments are cheap to revert.

The exception is an app that is unusable without translation — a children's reader, a voice app, a regulated local service. There the binary and the listing have to move together, but that is a product constraint rather than the default indie path.

The order to do it in

1. Internationalize the code. Externalise strings, remove concatenation, use the platform plural APIs, format numbers and dates through DateFormatter, Android's ICU formatters or Dart intl, and mark layouts as mirroring so RTL is not a rewrite later.
2. Choose the native catalogue format and stay in it. New iOS work belongs in .xcstrings; Android in strings.xml with real <plurals>; Flutter in .arb with the @ metadata filled in; React Native in one i18n library with one interpolation syntax.
3. Write English as though a translator will read it — full sentences, comments on every placeholder, no jokes that depend on English grammar, and no text baked into a screenshot that is not also a string.
4. Localize the App Store listing for one target locale you can justify, then Play. Treat 50 as a ceiling, not a target.
5. Translate the binary for locales that already convert. Pay per word, per credit, or with a TMS seat depending on how often your strings change. For a stable catalogue and a handful of languages, one-time credits or a single per-word pass beats a subscription comfortably.
6. Add languages only when a metric moves. Apple's new Indian-language slots are listing tests, not a binary commitment.

Whether machine translation is good enough to carry step five is a fair question, and the honest answer has conditions attached.

Frequently asked questions

Is app localization the same as internationalization?

No. Internationalization is the engineering work — externalised strings, plural APIs, formatters, layouts that can mirror. Localization is filling that machinery in for one specific locale. You internationalize the codebase once; you localize once per language.

Should I migrate from .strings and .stringsdict to .xcstrings?

For new iOS work, yes. A String Catalog holds source text, translations, plural variations and comments in one file that diffs cleanly in git. Keep .stringsdict only if you are maintaining an older target and cannot raise the Xcode floor.

Apple added Indian languages in 2026. Should I translate into Tamil or Telugu next?

Only if you have users there or a listing test you can measure. Apple added eleven metadata localizations in March 2026 and eight are languages of India, but that is store capability, not evidence of spend. The only published spend figures point at the United States and at Brazil growing 73% year over year.

Should I localize the store listing or the app itself first?

The listing, unless your app is unusable in English. Metadata is a small bounded set of fields, it drives acquisition, and it is cheap to revert. Spend on the binary for locales that already show up in your analytics.

Why use one-time credits instead of a subscription platform?

It depends on how often your strings change. If you localize in bursts, a subscription bills you for the months you are not translating. If strings change weekly and several people touch them, a translation management system is genuinely the better tool.

Can I mix AI translation with a human review pass?

Yes, and for most indie apps that is the right shape: machine translation for a first draft of UI chrome, a human on anything where being wrong is expensive — paywalls, permission prompts, legal and medical copy, and plurals that can go grammatically wrong.