Mobile app localisation testing checklist for iOS and Android

To test mobile app localisation, run a release-critical journey on both iOS and Android in the languages and regions affected by the change. Check whether people can read the screen, enter local values and finish the task with the right result. Use pseudolocales to find layout problems early, then run the checks that depend on real translations or regional settings on the release candidate.

Which languages and regions should you test first?

Pick a task that matters for the release, such as booking an appointment. Run it in the app's default language as a baseline, then choose settings that could change the result. For a new German translation, try the smallest supported screen with long labels and error messages. If the app supports Arabic, include a right-to-left run through the same task.

Keep app language, device region and account market in separate columns. A customer might use English on a phone set to France while paying in euros. Agree which setting controls each part of the journey. For example, the phone's region might control how the appointment date is displayed, while the clinic's location controls which time zone is used for the booking. Add these combinations to your mobile device test matrix.

How do you catch layout problems before translations arrive?

On iOS, open Product → Scheme → Edit Scheme in Xcode. Under Run → Options, choose Double-Length Pseudolanguage from App Language and run the app. Repeat with Right-to-Left Pseudolanguage if you need to check mirroring. Apple's Xcode guide to preparing interfaces for localisation

On Android, use a test build with pseudolocales enabled and select English (XA) in the device's language settings to stretch and accent the text. Use AR (XB) for a right-to-left pass. Google's setup guide shows how to enable both the build option and the device settings. Android's pseudolocale setup guide

Enter an invalid value and read the error while the keyboard is still up. If the message pushes the submit button out of reach, try to scroll to it. Open a confirmation dialog too. Look for app-owned text that stayed in the default language while the surrounding text changed.

What should you check in the release candidate?

Run this checklist with real translations and test data. For each row, write down the expected result before testing. A fluent reviewer should see the wording on the screen where people make the decision, especially for actions like cancelling a booking.

Check	What to try	What to verify
Text and layout	Open a form on a small phone, trigger an error and open the confirmation dialog.	Labels and errors are readable, and the button you need stays on screen or can be reached by scrolling.
Right-to-left layout	In a supported RTL locale, go back a screen and open a booking with the reference AB-123.	Directional controls follow the layout. The reference still reads AB-123 and the punctuation around it makes sense.
Counts and empty state	Check a list with zero, one and several results, plus counts that use other forms in the language.	The heading agrees with the count, and the empty-state message makes sense on its own.
Regional input	Enter a local decimal value, such as 1,5, using the supported keyboard and region for that form.	The app accepts the intended input, and the stored value and confirmation both mean one and a half.
Dates and amounts	Compare a booking review with its confirmation. Use a date such as 5 June, where day and month could be swapped.	Both screens refer to the same appointment and amount, with the expected time zone, currency and formatting.
Language changes	Change the app's supported language while leaving the device language alone, then reopen a saved booking.	The booking is still there, and app-owned text and server messages follow the agreed language or fallback.

Check plural forms with values the target language actually uses. Unicode's rules list the different forms by language, so the English singular and plural cases may leave some branches untested. Unicode CLDR plural rules

If the app exposes a language picker, include a switch back to the device default in the last check. On Android 13 and later, also try the app's language setting in system Settings if the app exposes it there. Android's per-app language guide

How do you file a bug someone else can reproduce?

Write down the input and the result as text so the developer can copy them. In a fictional quantity form, 1,5 under French (France) saves as 15. The ticket should show where you entered it and whether you saw 15 in the field, on the confirmation or only after reopening the record. If the same build saved 1.5 correctly under English (United States), record both the input and the settings for that run.

Screen and symptom
App version and build, device and OS
App language and where it was set
Device language and region
Keyboard, time zone or account market if relevant
Starting state and exact test input
Steps to reproduce
Expected text, value or behaviour
Actual text, value or behaviour
Screenshot or recording, and where to look
Result with another setting, if tested

Take the screenshot on a test account. To format the steps and results for your tracker, use the bug report template generator and paste the locale details into the Environment field.