Mobile App Localization Testing: The iOS and Android Checklist for Global Releases

Your app works fine in English. Then marketing books a launch in Germany, Japan, and Brazil, and suddenly the “Continue” button turns into “Weitermachen”, the push notification arrives at 3 AM local time, and the App Store screenshots still show US dollar prices. None of that is a translation problem. It is a mobile QA problem, and it looks nothing like the QA you ran for the English build.

Mobile app localization testing verifies that a translated app renders, functions, and gets discovered correctly on iOS and Android devices in every target market. This piece stays on what actually changes when localization QA moves off the desktop and onto a phone: the platform APIs, the two stores, the push payload, the keyboard, and the physical device matrix. The general definitions and end-to-end process are covered separately in our overview of what is localization QA testing. Everything below is mobile-only.

The stakes are worth naming. Sensor Tower reports that global in-app purchase revenue reached $167 billion in 2025, up 10.6% year over year, with growth pushed by non-English markets across Western Europe, LATAM, and APAC. A localization bug in a top market goes straight to the revenue line.

What We Check in Mobile Localization QA

Translation quality is one input to localization QA, and by itself, it covers maybe a quarter of what can break. When a build lands on our devices, we look at four surfaces in parallel, and a bug in any one of them can sink a launch. This is also where most of the work happens in our localization testing services.

Linguistic Accuracy in Context

A string that reads perfectly in a spreadsheet can be wrong the moment it sits inside a button. “Save,” translated as the Spanish “Guardar,” is fine on a settings page and confusing on a shopping cart, where “Guardar” implies “keep for later” rather than “confirm.” Our testers verify strings in their actual UI context, on a real screen, with real data flowing through. Placeholders like {username} and {count} get special attention because a broken variable often looks like a typo until someone notices it never resolves.

UI Integrity After the Strings Land

Translated text has a length. German runs roughly 30% longer than English, Finnish is close behind, and CJK scripts occupy less horizontal space but have a taller line height. On a 375-pixel iPhone canvas, that difference either wraps gracefully or breaks tab bars, nav headers, and call-to-action buttons. We check text truncation, button overlap, safe-area collisions on notched devices, and how the layout survives Dynamic Type on iOS and font scale on Android.

Locale-Aware Behavior

Dates, currencies, phone number formats, measurement units, and even sort order change with the user’s region. A price that shows “1,000.00 EUR” in Germany should render “1.000,00 €” locally, with the symbol after the number. On iOS and Android 13 and above, region is independent of language, so a user can read the app in English while expecting metric units and 24-hour time. This is where localization testing for mobile applications gets non-obvious: the wrong formatter is a functional bug.

Store-Facing Surfaces Users See Before They Install

The first localized surface most users meet is the store listing, not the app. Title, subtitle, description, screenshots, and preview video have to match the in-app language they will land in after they tap Install. If the App Store page promises German and the app opens in English, the review section fills up with one-star complaints within 48 hours.

Where iOS and Android Localization Diverge

Android holds roughly 71-73% of global smartphone shipments through 2026, while iOS captures the majority of consumer app spend, according to IDC’s Worldwide Quarterly Mobile Phone Tracker. You need both, and the two platforms handle locale in genuinely different ways.

iOS Locale Mechanics

iOS stores translations in .strings files for flat key-value pairs and .stringsdict files for plurals and gendered forms. Info.plist declares which locales the bundle supports through CFBundleLocalizations. NSLocalizedString pulls the right string at runtime based on the user’s preferred languages, resolved through the Bundle. Since iOS 13, users can pick a different language per app in Settings → App → Language without changing the whole device, which means QA has to switch languages mid-session and verify that cached strings refresh.

Android Locale Mechanics

Android uses qualified resource folders: values/, values-fr/, values-b+es+419/ for Latin American Spanish. Strings live in strings.xml, plurals in plurals.xml, and Android walks a fallback chain if a locale is missing. Since Android 13 (API 33), LocaleManager and AppCompatDelegate.setApplicationLocales() enable per-app language selection. Right-to-left support requires android:supportsRtl=”true” in the manifest and start/end layout attributes instead of left/right.

A quick side-by-side to keep on your QA whiteboard:

The Mobile-Only QA Checklist

Here are six checks that only matter on a phone. Skip any of them, and the launch will show it. The sections below vary in shape because the checks themselves do; some fit prose, and some belong in a list.

Text Expansion on a 375-pixel Canvas

Pseudo-localize before the real translations arrive. Replace English strings with elongated Latin variants (“Sëttîngß” instead of “Settings”) to force layout stress in every build. Verify landscape orientation, split-view on iPad, and font-scale set to 200% for accessibility. Buttons that look tight in English will break in German the day translations land, and by then the sprint is over.

RTL Layout on Touch UI

Arabic, Hebrew, Urdu, and Persian flip the entire interface. Navigation gestures reverse, chevrons mirror, progress bars fill from the opposite edge, and video scrubbers move in the opposite direction. Icons that imply motion need mirroring, while brand marks and logos stay as they are. Verify that the device is actually set to Arabic, and hit the surfaces most teams forget: transaction history, chat message alignment, form validation errors, and any custom-drawn charts.

Push Notifications per Locale

Push notification localization breaks in ways that are hard to catch without dedicated tests. APNs supports loc-key and loc-args, and FCM supports title_loc_key and body_loc_args, both of which let the OS render notifications in the device’s current language rather than the language your server assumed at send time. This matters because a user can change the app language after registering their push token. Testers should verify:

• Notification body truncation on the lock screen, roughly 60 characters on iOS and 65 on Android, depending on the device.
• Time-based sends are against the recipient’s timezone rather than UTC. A “good morning” push scheduled at 8 AM UTC hits Tokyo at 5 PM.
• Quiet hours, Do Not Disturb, and Focus mode behavior per region.
• Rich notification images with locale-specific content, when used.

OS-Level Formatters, not Hard-Coded Strings

Anywhere you see a date, currency, phone number, or unit of measurement in the UI, verify it goes through the platform formatter. On iOS, that means DateFormatter, NumberFormatter, and MeasurementFormatter. On Android, DateFormat.getDateInstance() and NumberFormat.getCurrencyInstance(). Hard-coded formatting like String.format(“$%.2f”, price) is the single most common source of locale bugs and one of the easiest to catch in code review before it ever hits QA.

Keyboards, Autocorrect, and Dictation

Japanese, Chinese, and Korean IMEs change the input field height when the suggestion strip appears, which can shove a submit button behind the keyboard on smaller screens. Cyrillic and Devanagari require different character validation regex than Latin scripts. Autocorrect can silently mangle a proper noun in one language and pass it through untouched in another. Test every form field with the actual keyboard the target user will use, not the English default.

On-Device Locale Switching Without a Restart

Both iOS 13+ and Android 13+ allow users to switch app language without restarting the device. If your app caches strings at launch and never re-reads them, half the UI stays in the old language until the user force-quits. Switch languages mid-session in QA, navigate through every major flow, and confirm every screen updates. This bug is common, silent, and only surfaces on real devices with real users. The same real-device gap shows up across the broader set of mobile testing challenges, where locale bugs and OEM quirks tend to cluster together.

App Store and Play Store Listing Localization QA

Store metadata is not the app, but it is the first localized surface a user sees. Two stores, two workflows, two sets of gotchas, and both submissions can be rejected for issues QA should have caught first.

App Store Connect

App Store localization on iOS runs through App Store Connect, where each locale gets its own title (30 characters), subtitle (30), keyword field (100), promotional text (170), description (up to 4000), screenshots per device size, preview videos, and “What’s New” per release. App Store Connect localization has a specific trap: character counts are calculated by code points, so Japanese katakana or Chinese hanzi in a title can silently overflow visual width even when they fit the count. Verify each locale’s screenshots use the actually localized in-app UI, rather than the English UI with a translated caption pasted on top.

Google Play Console

Play Store localization on Android is managed in Google Play Console under Store Listing, with title (30), short description (80), full description (4000), feature graphic, screenshots, and promo video per language. Custom store listings let you serve different content by country, pre-registration state, or install state. The Data Safety form needs to be localized too. One deliberate check: confirm that Google Play’s auto-translate is disabled if you shipped human translations, because auto-translated metadata layered on top of human copy creates inconsistent user-facing text and hurts conversion.

A store listing that promises full localization while the app itself stays half-translated will earn one-star reviews faster than any other launch mistake. Ratings drop, and ASO rankings follow.

The Real-Device Matrix Problem

Emulators lie about locale rendering. Xiaomi ships MIUI with its own font stack that can mangle Devanagari and Arabic glyphs. Samsung’s One UI overrides some Dynamic Type behaviors. Older iPhones without a notch have different safe-area math that can break localized banner text on the home screen. Font fallback chains differ across manufacturers, and a Chinese string that renders cleanly on a Pixel can look off on a Vivo phone popular in that exact market.

A pragmatic device matrix for a launch across Germany, Japan, and Brazil looks something like this:

• iPhone 15, iPhone 13, iPhone SE (2nd gen) covering current and legacy iOS layouts
• Pixel 8 as a reference Android
• Samsung Galaxy S23 for One UI behavior
• Xiaomi Redmi Note 12 for MIUI font rendering
• One tablet per platform (iPad and any 10-inch Android tab)

We test only on real devices for exactly these reasons, and it is baked into our mobile application testing practice across 300+ products. Simulators cannot reproduce OEM font stacks, real keyboard behavior, or the way a specific device model renders a notification on its lock screen. When a bug shows up in a five-star market, it is almost always device-specific, and it is almost never something the emulator would have caught.

Before You Hit Submit

Mobile localization QA is where translation, platform APIs, store submissions, and device fragmentation all meet at the same launch date. Get any layer wrong, and the market you invested in goes cold on you. Get all four right, and the app feels native the moment a user opens it, which is the whole reason to localize in the first place. If you are planning a multi-market rollout and want QA that has seen these failure modes across hundreds of products, contact us, and we will scope it around your target markets and device profile.

FAQ

How do you test mobile app localization?

Start by switching a real device to the target locale, rather than changing a flag on an emulator. Verify translations in context on every screen, check UI for text expansion and truncation, confirm that dates, currencies, and phone formats use platform formatters, test push notifications and their timing per timezone, and run through the store listing separately in App Store Connect and Google Play Console. Do all of this on the actual devices popular in the target market, not on whatever hardware sits on your desk.

What is localization testing for a mobile app?

It is a QA discipline that verifies a translated mobile app works correctly for users in a specific language, region, and device environment. It covers linguistic accuracy in context, UI integrity after strings expand or contract, locale-aware formatting for dates and currencies, push notification behavior, store listing metadata, and rendering on real devices from the OEMs popular in that market. Translation alone is only part of it.

What's the difference between iOS and Android localization testing?

The platforms handle locale through different file formats, APIs, and store workflows. iOS uses .strings and .stringsdict files with NSLocalizedString and submits per-locale metadata through App Store Connect. Android uses qualified resource folders and strings.xml with getQuantityString and manages per-language listings in Google Play Console. Per-app language settings arrived in iOS 13 and Android 13. Fragmentation is deeper on Android because OEM skins like MIUI and One UI change font rendering, so the device matrix runs larger.

Do I need real devices for localization QA?

Yes. Emulators cannot reproduce OEM font stacks, keyboard behavior, notification rendering on real lock screens, or the way region-specific devices handle glyph fallback. A Chinese string that renders cleanly on a Pixel emulator can look broken on a Vivo phone that dominates that market. Every localization bug that reaches App Store or Play Store reviews is almost always device-specific, which is why real-device testing is a hard requirement for a global launch.