App localization: why day one is cheaper than later

The short answer: app localization is cheap when the app was built for it and expensive when it was not. Translating the store listing is a small line item. Human translation through Google Play starts at $0.07 per word, delivered within seven days, according to Google’s Play Console Help (verified October 2026). The expensive part is engineering: finding every piece of text hardcoded across hundreds of files, pulling it out and fixing the layouts that break when German or Italian words turn out twice as long as the English ones. If the text lives in one place from the first sprint, adding a language later is a feature. If it does not, adding a language means refactoring the app first.

Here is how it usually shows up. The app is live, gaining traction, and one day sales walks in with good news: “We have a big potential client in Mexico. What would it take to support Spanish?” It is a real deal with real revenue behind it. And the honest technical answer is “first we have to find all the text”, because nobody planned for a second language. Radu, our founder, has been on the receiving end of that question many times, and it is the opening story of the localization chapter in his ebook Mobile App Fundamentals.

If you would rather have the app ready for new markets from the start: we are Digital U, we build mobile apps from $5,000 (pricing page) with all user-facing text kept in one place from the first sprint, so a new language is a translation job, not a rewrite. A free 30-minute call is enough to tell you how ready your current app is. The rest of this article is the reasoning, so you can judge it yourself.

What app localization actually includes

App localization is the work of adapting a mobile app so it feels native to people in another language or region. It has three layers, and teams often budget for only one of them.

The text inside the app. Buttons, menus, error messages, emails and push notifications. This is what most people picture when they hear “translation”, and it is the layer that becomes expensive when the text is scattered through the code.

The formats and the layout. Dates, numbers, currencies, plural rules, and languages written right to left such as Arabic. A layout designed around short English labels will overflow when the same labels are translated, which the next section quantifies.

The store listing. Name, subtitle, description, keywords and screenshots in the App Store and Google Play. This layer decides whether people in a new market find the app at all, and it can be localized before the app itself is.

Engineers split the topic into two words: internationalization (i18n), which means structuring the app so it can hold several languages, and localization (l10n), which means actually adding a language and choosing it based on the user’s settings. The first is a decision made once, early. The second is repeated for every market.

Why app localization gets expensive when it is added late

App localization gets expensive late for one reason: text that was never meant to be translated ends up everywhere. A lean team shipping fast writes “Save” directly inside the button component, the welcome message inside the onboarding screen and the error text inside the network code. Nothing is wrong with that while the app has one language. The day a second language is needed, someone has to search the whole codebase, copy every string into a file, replace every reference and test every screen again.

Three things make the late version worse than it looks on paper.

The work blocks the roadmap. Extracting text is not a feature anyone can see, so it competes directly with the features you had planned, often under pressure from a deal with a deadline.

Translated text is longer. The W3C’s guidance on text size in translation reproduces IBM’s averages for English translated into European languages: strings of up to 10 characters typically grow to 200-300% of their English length, strings of 11-20 characters to 180-200%, and long texts over 70 characters to about 130%. Short labels are exactly what buttons, tabs and badges contain, so the layout breaks precisely where it is most visible.

Missing text can break the app, not only look wrong. The Android localization guide is explicit: if the default strings file is missing a string the app needs, the app does not run and shows an error. A half-finished extraction is a crash risk, not a cosmetic issue.

In his ebook, Radu puts the trade-off plainly: organizing text at the start is a small, one-time setup, while retroactive localization often means days to weeks of cleanup. That is the whole argument of this article in one sentence.

What to do on day one, even with one language

App localization from day one does not mean translating anything yet. It means one rule and one decision.

The rule: never hardcode user-facing text. Every label, message and notification goes into a text file (usually one JSON file per language) and the code references it by key. With a single language, that is one file. It costs almost nothing while you write the app, and it gives you a single source of truth for every word users see, which also helps the people editing copy, not only the developers.

The decision: where the text files live. There are two reasonable options, and the trade-off is about releases, not about code.

Where the text lives	Changing a word needs	Fits when
Bundled inside the app (for example with i18next in React Native)	A new app version or an over-the-air update	You have one or two languages and copy changes rarely
Served from a backend, headless CMS or localization platform, synced at launch	No release at all	Copy changes often, or several languages are maintained by non-developers

The bundled option is the simplest start. If the app is built with Expo, text changes can also ship through EAS Update, because over-the-air updates cover JavaScript and assets, though they cannot change native code. The remote option is what you want once marketing or support teams edit copy regularly: a typo fix stops being a release.

Two smaller habits complete the setup: read the device language with the platform’s tools (for Expo apps, the localization guide covers this) and design buttons and tabs with room for longer words. Android Studio can even preview a screen in another locale or in a right-to-left language before anyone writes a translation, as described in the Android localization guide.

Planning an app that may need a second market later? That is a conversation worth 30 minutes before the first sprint, not after the first deal. Book a free call or request a free audit of the app you already have.

What app localization costs in 2026: translation is the cheap part

App localization cost has two parts: translating words and preparing the app to hold them. Translation prices are public, at least for store listings, and they are lower than most people expect.

Option	What it covers	Price (verified October 2026)
Digital U (us)	Text kept in one place from the first sprint, ready for any language	Included in every app we build, from $5,000
Google Play paid human translation	Store listing and in-app product names, by a professional third-party vendor	From $0.07 per word, completed within 7 days
Google Play free machine translation	Store listing and in-app products, in a limited list of languages (French, German, Spanish, Japanese and others)	$0, not reviewed by humans
Google Play app strings translation with Gemini	The app’s own text (strings.xml), regenerated for every new app bundle	$0

The Gemini option is worth knowing about: once it is turned on, Play Console translates the Android app’s text automatically each time a new bundle is uploaded, keeps translations consistent between versions and lets you edit them before publishing, according to the same Play Console Help page. It only works on text that already sits in the standard strings file, which brings us back to the day-one rule. Free translation tools are useless to an app whose text is scattered through the code.

What these prices do not cover is the engineering: extracting text, fixing layouts, testing every screen in every language and keeping translations updated with each release. On an app built for localization that is a predictable task. On an app that was not, it is the expensive part, and nobody can quote it honestly without looking at the code. For the full picture of what an app costs to build and run, see how much a mobile app costs in 2026.

App Store localization: how a new market finds you

App Store localization is the cheapest first step into a new market, because it changes what people see before they download anything. Apple says the App Store is available in 175 regions and 50 languages, and lets you localize the app name, description, keywords, app previews and screenshots for each one.

The rules for what users see are specific, according to App Store Connect Help. If English is your primary language and the only one you provide, your metadata appears in English in every country. If you add a French localization, users with French language settings see it, users can search for the app with the French keywords, and when no localization matches a user’s settings the store falls back to the closest one and then to the primary language.

In practice, this gives you a cheap test: localize the store listing for a target market first, watch whether impressions and downloads move, and only then invest in translating the app itself. Radu’s ebook makes the same point from the other side: in many regions an English-only listing feels incomplete or untrustworthy, so planning localized screenshots and descriptions early is far easier than retrofitting them under launch pressure. The full launch checklist is in how to launch an app.

When app localization is not worth it yet

App localization is not automatically the right investment, and an agency that says otherwise is selling hours.

If all your users speak one language and nothing in your plans points to another market, do not translate anything. Keep the text in one file, which costs nothing, and spend the budget on features users asked for. If you are unsure whether a market will respond, localize the store listing and measure before translating the app. And if a single large client needs a second language, ask whether the parts they use are a subset: localizing the screens one customer actually touches can close the deal at a fraction of the cost.

The only version that is never worth it is the one where nobody decided: the app ships with text scattered everywhere, and the decision gets made for you the day sales brings a deal from Mexico.

Frequently asked questions

What is app localization? App localization is adapting a mobile app to a language and region: its in-app text, its formats for dates, numbers and currencies, its layout, and its listing in the App Store and Google Play. Apple’s App Store alone is available in 175 regions and 50 languages, and each one can get its own app name, description, keywords and screenshots.

How does localisation work? Localisation works by keeping every piece of user-facing text in separate files, one per language, and letting the app load the file that matches the user’s device settings. On Android, the system picks the matching strings file automatically and falls back to the default one, as described in the Android localization guide. The store listing is localized separately, in App Store Connect and Play Console.

How much does app localization cost? $0.07 per word is the starting price for professional human translation of a Google Play store listing ordered through Play Console, delivered within seven days, according to Google’s Play Console Help (verified October 2026). Machine translation of the listing and of Android app strings is free in Play Console. The larger and more variable cost is engineering: on an app whose text was never extracted into files, the cleanup can take days to weeks before translation even starts.

What is App Store localization? App Store localization is translating and adapting your listing (name, description, keywords, previews and screenshots) for each language in App Store Connect. According to App Store Connect Help, users see the localization matching their language settings and can find your app with localized keywords; without one, they see your primary language.

How does app localization work on Android? On Android, app localization works through resource folders: the default text sits in res/values/strings.xml and each translation goes in a folder named for its locale, such as res/values-fr/. The Android localization guide warns that if the default file is missing a string the app needs, the app does not run and shows an error, so every string must exist in the default file.

How does app localization work on iOS? On iOS, app localization combines translated text resources in the Xcode project with localized metadata in App Store Connect. Apple’s localization page lists the tools, including string catalogs in Xcode, and the App Store side lets you translate the app name and tailor screenshots for each of its 50 supported languages.

Do I need app localization services? Not at the start. $0 is what it costs to keep text in one file per language from day one, and Play Console even offers free machine translation for store listings and Android app strings, per Google’s Play Console Help. Paid localization services make sense once you are maintaining several languages, marketing copy matters, or a regulated market requires reviewed translations.

Want to know how much work a second language would be in your app today? Drop us two lines or book a 30-minute call: we look at how your app handles text, tell you what a new language would take and what you can safely postpone, no obligation.