Which parts of your app should you localize first? The screens that pay first: onboarding and the paywall. Most teams treat mobile app localization as a final polish pass, translating every settings page and error message before entering a market. That order is backwards. A non-English user decides whether to keep your app in the first session, long before they ever open settings. Localize the first-session screens first, adapt more than the words, plan for text expansion, and ship translations without waiting on an app release.
Why the first session decides if localization pays
A new user opens your app seconds after install with zero context and zero commitment. If the screens explaining your value are in a language they only half understand, most will not push through. They quietly close the app, and you never get a second first session. An English settings screen is a minor annoyance for a retained user. An English onboarding screen is a lost user.
That asymmetry is why localization ROI is front-loaded. Every user sees onboarding, and they see it at the moment of lowest trust. Only your most engaged users ever reach the long tail of secondary screens. Translating your onboarding flow into five languages will usually do more for international retention than translating your entire app into one.
Onboarding and the paywall are one surface
Treat the paywall as part of onboarding, not a separate project. In most subscription apps the first session runs straight from welcome screens into a trial offer, so the experience shifts from learning to paying in a single swipe. If the screen asking for money suddenly flips to English at that moment, you break trust exactly where trust matters most.
Paywall copy also carries the highest comprehension stakes in your app. Users need to understand what a trial is, when it converts, what the renewal price is, and how to cancel. Ambiguity a native speaker would shrug off becomes a hard stop in a second language, and misunderstood trial terms turn into refunds and one-star reviews. Where the offer sits in the flow matters too; see our guide to onboarding paywall placement.
Localize more than the strings
Translation is the floor, not the finish line. Three things deserve attention beyond the words themselves:
- Imagery and screenshots. Product screenshots with English UI baked into the image undo the translated text around them. Review photos and illustrations for gestures, symbols, and cultural context that do not travel.
- Formality. Many languages force a choice English hides: tu or vous in French, du or Sie in German, distinct politeness registers in Japanese and Korean. Pick the register that matches your brand and keep it consistent from the first welcome screen through the paywall.
- Numbers, dates, and prices. 1,000.50 in one market is 1.000,50 in another, and currency symbols switch sides. A price formatted the wrong way on a payment screen reads as careless at best and untrustworthy at worst.
If you personalize screens with user data, formatting has to follow the language too. Setgreet's Variable Bindings support locale-aware currency and number formatting through format modifiers, so a bound value renders in the user's local conventions instead of defaulting to English ones.
Plan for text expansion before it breaks your layout
Translated text rarely matches the length of the English original. German compounds stretch, French runs long, and a button label that fit comfortably in English can truncate, wrap awkwardly, or push your call to action off the visible screen. These bugs hide until a real user in a real locale hits them.
Pseudo-localization catches much of this early: replace your strings with padded, accented versions and watch what breaks. But it has pitfalls of its own. It only tests expansion, not meaning, so a layout can pass while the translation still reads wrong in context. It will not catch text baked into images. And it says nothing about strings concatenated in code, which can become grammatical nonsense once word order changes.
So design for elasticity: avoid fixed-width text containers, let buttons grow, and review your longest target language rather than your prettiest. Flexible layouts that reflow with content absorb routine expansion far better than pixel-perfect frames. Then open every language and actually read every screen before it goes live. No automated check replaces that pass.
Ship translations without waiting on a release
The classic localization tax is the release cycle. Strings live in the app binary, so every new language, and every typo fix, waits on a build, a review, and users actually updating. Apple reports that 90% of submissions are reviewed in under 24 hours, but review is only one step: you still cut a full release for a one-word change, and users on older versions never see it.
Server-delivered screens remove that tax. In Setgreet, you build onboarding and paywall flows once in your base language, then add any of 100+ languages from the Localization modal. Auto-translate with AI, which is rolling out gradually and may not be enabled on every workspace yet, drafts the missing text, shows the credit cost before it runs, and preserves binding expressions exactly; every line stays editable, so a native-speaking reviewer keeps final say. When you publish, live apps pick up the new language with no App Store release, the SDK detects the device locale and serves the matching translation, and anything untranslated falls back to your base text per property. A half-finished language shows mixed text, never a blank screen. More on this model in updating your app without App Store review.
Start small. Pick your top non-English market, localize the first session end to end, and watch whether day-one retention moves before you widen the net.
Frequently asked questions
Which languages should you localize first?
Let your install data decide. Look at where downloads and store page views already come from, then compare first-session retention across those markets. Most apps find a shortlist of countries where demand clearly exists but non-English users bounce early. Those gaps are the highest-ROI targets because the users are already arriving; you are just losing them at hello. Localize the first session for that shortlist before adding more languages anywhere else.
Do users need to update the app to get new translations?
Not if your first-session screens are delivered from the server. With Setgreet, publishing a translation updates live apps without an App Store release or a user-side update, so a fixed mistranslation reaches everyone at once. One detail to plan for: device locale matching is exact, so es-MX will not match a generic es translation. Add the specific locales your users actually run, not just the parent language.
What happens to text you have not translated yet?
In Setgreet, any property without a translation falls back to the base language text, property by property. A partially translated screen shows finished lines in the target language and the rest in your base English, rather than blanks or raw keys. That makes incremental localization safe: ship the languages you have and fill gaps as you go. Keep the base English version complete and current, since it is the safety net behind every other language.