Mobile: Appium, Espresso, XCUITest, Maestro

Mobile test automation drives a real or simulated phone rather than a browser.

Four tools dominate. Appium is cross-platform and driver-based, using the same WebDriver protocol Selenium uses. Espresso is Google's in-process framework for Android. XCUITest is Apple's equivalent for iOS. Maestro is a newer declarative tool with a much simpler configuration.

The framework choice is the easy part. The hard parts are the same for all four. Getting a build to test, finding devices to run on, and a phone having state and interruptions a browser never has.

The terms you will hear

• Emulator and simulator. A virtual Android device, and a virtual iPhone. Fast, and not identical to hardware.
• Real device. Actual hardware, locally or in a cloud farm.
• Device farm. A hosted pool of devices you run against, such as BrowserStack or Sauce Labs.
• Instrumentation. Espresso and XCUITest running inside the app process, which is why they are fast and reliable.
• Appium driver. The component translating commands into platform automation.
• Flow. Maestro's term for a test, written in YAML.

Choosing between them

• Appium when one suite must cover both platforms and the team writes in a shared language. The cost is speed and a heavier setup.
• Espresso and XCUITest when the app teams own their tests. Faster, more stable, and you maintain two suites.
• Maestro when you want a small readable suite quickly, especially for smoke checks. Less powerful for complex flows.

There is no wrong answer here, and the honest tiebreaker is who will maintain it. A suite the app developers will run beats a cross-platform suite only you understand.

The mobile-only failure modes

These are the cases a web suite never has to think about, and they are where real defects live.

1. Permissions. Denied, then granted later. Revoked while the app runs. The dialog appearing on first launch only.
2. Interruptions. An incoming call, a notification, the app backgrounded and restored an hour later.
3. Network transitions. Wifi to mobile data, an airplane-mode toggle, a captive portal, genuinely slow 3G.
4. State and storage. Upgrading over an old version with existing data. A full disk. Cleared cache.
5. Device variety. A small screen, a large font accessibility setting, dark mode, an old OS version.
6. Background limits. Android killing your process, iOS suspending a background task mid-upload.

How to make it survivable

1. Choose the device matrix from analytics. The four or five combinations your users actually have, not a spread for coverage's sake.
2. Run smoke on emulators, release checks on real devices. Emulators are fast and lie about performance and hardware.
3. Reset state per test. Reinstall or clear data, so tests are hermetic in the same sense as determinism requires everywhere else.
4. Handle permissions explicitly, granting them in setup so the dialog is never a surprise, plus one deliberate denied-permission test.
5. Automate the smoke path only, at first. Launch, log in, the one core journey. This catches most build-level breakage for little maintenance.
6. Keep the interruption cases manual until they are stable. They are valuable and the hardest to automate reliably.
7. Expect a higher flake rate than web and hold the same quarantine discipline anyway.

A worked matrix

For example, here is one team's mobile setup and what it caught.

The four manual findings are the point. Every one is a mobile-only failure mode, and none of them would appear in a framework comparison or in an automated suite aimed at the happy path.

How to show you know it

• A matrix from analytics. Five combinations with percentages beats twenty chosen for symmetry.
• An interruption finding. Backgrounding during payment is the classic, and it lands with everyone.
• A separated flake category. Distinguishing farm failures from product defects keeps the numbers honest.
• A staged plan. Emulator smoke per pull request, real devices nightly, manual interruptions per release.