iOS and Android Testing Frameworks: Appium, Maestro, Detox, XCUITest and Espresso

There is no Playwright for native apps

A Playwright, Cypress or Selenium suite will tell you the website works. It will not tell you whether the iOS or Android app launched, handled a permission prompt, survived a background kill, or recorded a tap on a real phone. Device emulation in a desktop browser is mobile web. Native and React Native apps need a different runner.

RedQA still specialises in Playwright, Cypress and Selenium for web. We also test iOS and Android: real devices, Appium, Detox, Maestro, and the platform tools Apple and Google ship. This guide is how those frameworks differ and when to use each.

Related reading: how to test a mobile app and mobile accessibility (VoiceOver and TalkBack).

What you are actually testing

Name the product first. The framework follows.

• Native iOS (Swift, UIKit, SwiftUI): Apple’s own UI tests are the most reliable
• Native Android (Kotlin, Java): Google’s Espresso is the same idea on Android
• Both stores, one suite: a cross-platform runner (Appium or Maestro)
• React Native / Expo: Detox (grey-box) or Maestro (YAML smoke), Appium if you also have native apps in the same fleet
• Flutter: Flutter’s integration_test first; Appium if you already live in Appium
• Mobile web / PWA: Playwright. Do not buy a device farm for a website you can emulate

A lot of mobile QA is still manual. Automation earns its keep on regression: login, the money path, push notification deep links, and the flows that break every OS release.

XCUITest and Espresso: the native defaults

XCUITest ships with Xcode. Tests are Swift or Objective-C, in-process with the app. Best for a native iOS team that already builds in Xcode. Weakness: it does not drive Android.

Espresso ships with Android Studio. Kotlin or Java, synced to the UI thread, fast and usually less flaky than a black-box driver. Weakness: it does not drive iOS.

If you will accept two suites for fewer flakes, this pair is the quality ceiling. It is what platform engineers already use. It is not “one Playwright for both stores.”

Appium: the cross-platform default

Appium is WebDriver for phones. One suite, JavaScript, Python or Java, iOS and Android, simulators and real devices, BrowserStack and similar clouds. It can drive native, hybrid, React Native and (with the right driver) Flutter.

That breadth is why QA teams still cite it first. The cost is operational: Appium Server, drivers (XCUITest on iOS, UiAutomator2 on Android), session flakes if waits are sloppy, and slower runs than in-process tools.

Use Appium when you need one language across mixed apps, a device cloud, or a team that already thinks in Selenium. Do not start a greenfield React Native smoke suite in Appium if Maestro will cover the happy path this week.

Maestro: the fastest way to a smoke suite

Maestro flows are YAML. Install the CLI, point it at a simulator or device, write tap and assert steps. It runs on iOS and Android, including React Native and Flutter. In the 2025 State of React Native survey it was the most used E2E tool in that community, ahead of Detox and Appium.

Best for: “does login, checkout and the main tab still work after this build?” Weakness: it is not a typed, huge regression codebase. Complex logic, heavy reuse and a 500-test suite still belong in Appium, Detox or XCUITest/Espresso.

Detox: grey-box React Native

Detox runs with the React Native app. It waits until the bridge is idle, which is why it is usually more stable than Appium on RN. JavaScript, Jest-style tests, iOS and Android.

Best for a React Native product that needs a real CI suite, not three YAML smokes. Weakness: it is not the tool for a fully native Swift/Kotlin app, and setup is heavier than Maestro.

Playwright still belongs, just not on the store binary

Use Playwright (or Cypress or Selenium) for:

• The website and the authenticated web app
• Mobile web and PWAs, with device emulation or real Chrome
• APIs the app calls, so a native failure is not “the phone” when the endpoint 500s

Treat the native runner as an unreliable, slower sibling of that suite. Critical path on device, everything else on web and API where you already have Playwright.

How to pick

• Native iOS only: XCUITest
• Native Android only: Espresso
• Native iOS and Android, one QA team: Appium, or XCUITest plus Espresso if flake rate matters more than one codebase
• React Native / Expo, smoke this sprint: Maestro
• React Native / Expo, CI that has to hold: Detox
• Website that merely looks like an app: Playwright

Run automated regression on simulators in CI. Validate release candidates on a short real-device list (latest two iOS majors, a current Pixel, a Samsung). VoiceOver and TalkBack are not optional if you claim WCAG. See mobile accessibility testing.

What a first mobile testing engagement looks like

1. Name the stack: native, React Native, Flutter, or mobile web
2. Pick the runner (list above) and the device set
3. Automate the revenue and login paths; keep exploratory and store-checklist work manual
4. Wire the suite into CI/CD on simulators, then a real-device pass before TestFlight or Play internal testing
5. Hand over the project so your team can extend it

That is the core of our iOS and Android testing work, next to Playwright, Cypress and Selenium. Fixed mobile testing projects typically start from about £3,950 (roughly $5,150 USD) for one app on both stores. We also build React Native and Expo apps when you need the product as well as the tests.

Get a quote if you need Appium, Detox or Maestro on a store app, or a real-device pass before launch. See testing pricing. Guide to the wider process: how to test a mobile app.