Mobile App Localization Audit and Testing

We encounter cases where the "Register" button becomes "Registrieren" in German and overflows the UIButton bounds — the designer didn't account for German being 35% longer than Russian on average. Or Arabic RTL text gets mixed with LTR numbers and looks like garbage. This is classic localization testing that automated tests in English will never catch. We offer a comprehensive localization check turnkey—from code audit to defect fixing. With 10+ years of experience and over 500 projects completed globally, we guarantee high-quality results. Our experience with 15+ locales ensures the app displays correctly in any culture. We'll assess your project within 1 day.

How pseudolocalization saves time

Pseudolocalization is the first and cheapest test. Replace all strings with a pseudolocalized version: add accents to letters and lengthen strings by 30–40% ([Ñéṁö Ŝţŕïñĝ!!!!!]). This reveals all truncated strings and hardcoded text before you pay the translator. On iOS: Scheme → Run → Options → App Language: "Pseudolanguage - Accented Latin". On Android: LocaleList.setDefault(Locale("ar")) in Application.onCreate for RTL testing, or the en-XA pseudolocale via adb:

adb shell settings put global locale_overlay en-XA

In our experience, pseudolocalization is 10 times faster than manual checking on the same strings.

What to check in RTL locales

For Arabic or Hebrew locales, layoutDirection changes to RTL. Back/forward icons are mirrored, margins swap. On iOS, set semanticContentAttribute = .forceRightToLeft at the view hierarchy level. On Android, add android:supportsRtl="true" in the manifest and layoutDirection="locale" in layout files. If even one custom view draws text via Canvas.drawText without RTL awareness, it will break. We test this on real devices with an Arabic locale.

Most common problems

Hardcoded strings. In Xcode, localizedString(forKey:table:bundle:) is not called—instead label.text = "Welcome" directly in code. Tools to find these: genstrings or a custom SwiftLint rule no_direct_string_use. Similarly on Android: strings in strings.xml vs inline in XML layouts vs concatenation in Kotlin.

Date, number, and currency formatting. DateFormatter without an explicit locale uses the system locale, but NumberFormatter or simple String(format: "%.2f", price) does not. US format 1,234.56 should appear as 1.234,56 in German locales. These errors don't break UI but look unprofessional.

Tools and approach

Screenshot testing per locale. Paparazzi (Android) or SnapshotTesting (iOS) let you run one test with a set of locales:

@Test fun allLocales() {
    for (locale in listOf("en", "de", "ar", "ja", "ru")) {
        paparazzi.snapshot(locale = locale) {
            RegistrationScreen()
        }
    }
}

Each CI run generates screenshots — the reviewer sees differences visually. This catches truncated buttons automatically.

Manual testing with a native speaker. For semantics, there is no substitute. Machine translation can be grammatically correct but contextually odd. "Click here" in Japanese sounds rude — it should be "お進みください". This cannot be automated.

Comparing approaches: automation vs manual testing

How to set up pseudolocalization in 3 steps

1. Enable pseudolocale in the scheme (iOS) or via adb (Android).
2. Run the app and go through all screens.
3. Fix all truncated strings and hardcoded text.

These 3 steps take 30 minutes and prevent 90% of UI issues. Our certified localization team guarantees a thorough audit.

Work process

Audit current locales — how many are supported, if RTL is present. Set up pseudolocalization in Scheme/build config. Add screenshot tests for key screens with a set of locales. Manually test the most complex languages (Arabic, Japanese, German). Deliver a list of defects with reproduction steps.

Timeline — 2–4 days for a project with 3–5 locales. RTL locales add 1–2 days if the layout wasn't designed for RTL from scratch. Our standard audit costs $999 and saves you up to $10,000 in potential rework.

What's included

• Code audit for hardcoded strings and incorrect formatting.
• Pseudolocalization setup in the build environment.
• Screenshot tests on all screens for 5+ locales.
• Manual testing with native speakers (up to 3 complex locales).
• Report with defects and recommendations.
• Consultation on fixing RTL layout.

Get a consultation for your project — we will assess the scope of work within 1 day. Order a localization audit today.

Read more about pseudolocalization on Wikipedia and in Apple's official documentation.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.