We’re curious people, so we ran a real head-to-head: take one app, one test flow, and two of the most popular iOS test-automation tools — Appium and Maestro — and see which actually gets you to a passing test faster. The app under test was Flixtr (React Native 0.84, New Architecture) on an iPhone 17 Pro simulator running iOS 26.0. Same flow for both: launch → demo login → browse the feed → search in Discover → return to the feed.
The short version: on this stack, one tool was running in under a minute, and the other never ran at all.
TL;DR
| Category | Maestro | Appium |
|---|---|---|
| Setup time | ~15 min | 2+ hours (blocked) |
| Test authoring | 5 min (YAML) | 30 min (JS) |
| First run (cold) | ✅ 41s | ❌ Timed out |
| iOS 26.0 support | ✅ Full | ❌ WDA incompatible |
| Language flexibility | YAML only | Any WebDriver language |
| Verdict (this stack) | Winner — 40/50 | Significant barriers — 30/50 |
Setup
Maestro was brew install maestro, set the Java path, write a short YAML flow, and maestro test — running inside ~15 minutes (including two small fixes: a changed placeholder text, and a search bar that needed a coordinate tap rather than a text match).
Appium took the classic route — npm install webdriverio, install the XCUITest driver, start the server, write ~100 lines of WebdriverIO JavaScript — and then hit a wall. WebDriverAgent (WDA), Appium’s iOS automation backbone, builds for iOS 26.0 but fails to bind its HTTP server on the host: iOS 26 changed how the simulator exposes ports, and appium-xcuitest-driver v11.17.4 doesn’t forward port 8100 yet. Time to first successful test: infinite, on this OS.
Authoring the test
Maestro’s flow was 45 lines of declarative YAML — no programming, sub-flow reuse to stay DRY, and text-based targeting that falls back to coordinates when accessibility isn’t wired up. Appium’s was 105 lines of JavaScript — far more boilerplate, but precise accessibility-ID targeting, rich assertions, parallel runs, and it speaks the WebDriver protocol so it slots into an existing cross-platform suite.
Runtime
Maestro completed the whole flow in 41 seconds. Appium sat at 120 seconds and timed out — WDA never bound to the host port. Same simulator, same app, same flow.
Scoring (on this specific stack)
| Dimension | Maestro | Appium |
|---|---|---|
| Setup friction | 3/5 | 0/5 |
| Time to first test | 5/5 | 0/5 |
| Test readability | 5/5 | 3/5 |
| Element targeting | 4/5 | 5/5 |
| Reusability / DRY | 5/5 | 4/5 |
| CI integration | 4/5 | 3/5 |
| Debug tooling | 4/5 | 3/5 |
| OS compatibility | 5/5 | 2/5 |
| Language flexibility | 2/5 | 5/5 |
| Community / ecosystem | 3/5 | 5/5 |
| Overall | 40/50 | 30/50 |
When to choose each
Choose Maestro when a small mobile team wants tests running fast, you don’t want to manage Xcode provisioning or WDA compilation, the app is on stable iOS / React Native, and you like YAML flows readable by non-engineers.
Choose Appium when you need one suite across iOS + Android + Web, your team writes TypeScript and wants tests in the same repo, you need advanced assertions or custom reporting, and you have the infra to manage WDA compilation and signing — on stable iOS versions (18 or earlier). The iOS 26 port-binding issue will almost certainly be fixed in a future appium-xcuitest-driver release.
Reproducibility
- Appium: WebdriverIO 9.15, appium-xcuitest-driver 11.17.4, Xcode 26.5, iOS 26.0 sim
- Maestro: 2.5.1, Java openjdk@17
- App: Flixtr (React Native 0.84, New Architecture), iPhone 17 Pro simulator, July 2026
How we made the video
True to the “fuel your curiosity” spirit, the making-of is part of the story. The whole experiment was kicked off with a single plain-English prompt, and the accompanying YouTube Short was produced with an AI-assisted pipeline: the two test runs are the real screen recordings, and the bright “face-off” graphics — the versus intro, the setup and scorecard cards, the verdict — were built with Clipkit, a JSON-timeline motion-graphics renderer, then assembled with ffmpeg. The tools we compare here are the same kind of automation we lean on to make the content.
More experiments at roverplanet.co.uk.