Product news and testing tips.
Maestro is an open-source, YAML-based UI testing framework from mobile.dev (mobile-dev-inc) that drives Android, iOS, React Native, Flutter, and hybrid apps through their UI/accessibility tree instead of framework-specific code — flows are declarative YAML (`launchApp`, `tapOn`, `inputText`, `assertVisible`) with no compiled test code to maintain. Against Appium, the other cross-platform option — which needs a running server, the WebDriver protocol, a platform-specific driver, and a language client binding before you write a single test — Maestro ships as one CLI binary with built-in retry/wait logic and writes JUnit-XML natively, where Appium's JUnit output depends entirely on whichever client harness runs it.
Key takeaways
- Maestro is open-source (Apache 2.0) and maintained by mobile.dev (mobile-dev-inc) — 15,330+ GitHub stars and CLI releases roughly every 2–4 weeks as of August 2026.
- Tests are YAML 'flows,' not compiled code — launchApp, tapOn, inputText, assertVisible — and the same flow can drive Android, iOS, React Native, and Flutter builds of an app since Maestro interacts with the UI/accessibility tree, not framework-specific internals.
- Appium requires a running server, the WebDriver protocol, a platform-specific driver (UiAutomator2, XCUITest driver), and a language client binding before the first test runs; Maestro is a single CLI binary with no server to manage.
- Maestro writes JUnit-XML natively via `maestro test --format junit`; Appium has no official JUnit reporter of its own — that comes from whichever client framework runs it (Surefire, pytest, wdio).
- Maestro Cloud is mobile.dev's own paid device-execution product, separate from the open-source CLI. Qualflare is unrelated to it — a results and analysis layer, not a device-execution competitor.
- Mobile build flakiness is rising industry-wide: Bitrise's 2025 Mobile Insights Report found the share of teams experiencing any test flakiness grew from 10% to 26% between 2022 and 2025.
Maestro is an open-source UI testing framework, built by mobile.dev (mobile-dev-inc on GitHub), that automates Android, iOS, React Native, Flutter, and hybrid apps through plain YAML “flows” instead of compiled test code. There’s no server to start, no platform-specific driver to install, and no client library to import — one CLI binary reads a YAML file and drives the app. That’s a direct contrast with Appium, the other cross-platform mobile automation tool, which needs a running server, the WebDriver protocol, a platform driver, and a language binding before the first test executes. This post covers what Maestro is, why it exists, and exactly how the two compare.
What Maestro actually is
Per its own docs, Maestro is “the simplest and most effective framework for painless mobile and web UI automation using intuitive YAML flows,” and its GitHub README describes it as “an open-source framework that makes UI and end-to-end testing for Android, iOS, and web apps simple and fast.” It’s maintained by mobile.dev (the company behind the mobile-dev-inc GitHub org) and released under the Apache 2.0 license.
The core design choice is philosophical as much as technical: “while tools like Appium or Selenium treat testing like unit tests inspecting internal APIs, Maestro treats your app as a black box,” per Maestro’s documentation. It drives the UI/accessibility tree rather than framework internals — the same reason one Maestro flow can exercise an Android build, an iOS build, and, per the project’s own README, “React Native, Flutter, hybrid” builds of the same app. None of that automation depends on framework-specific test code, only on what’s actually rendered on screen.
A flow file has two parts: a short YAML header — at minimum an appId — followed by a --- document separator and a list of commands. Common commands include launchApp, tapOn, inputText, and assertVisible. No compiling, no imports, no test-runner boilerplate — the YAML file is the test.
Why Maestro exists: the problem it solves
Appium’s own docs describe its architecture as split into “Appium Core, Drivers, Clients, and Plugins.” Before writing a single test, that means: starting an Appium server process, choosing and installing a platform-specific driver (the UiAutomator2 Driver for Android, the XCUITest driver for iOS), and installing a client library for whichever language you’re testing in (Java, Python, JavaScript, and others are all supported). Tests then talk to the server over the WebDriver protocol, which drivers translate into platform-native automation calls.
Maestro collapses that stack into a single CLI binary — no server process to keep running, no driver to install, no client library to pull in. Its own README frames this explicitly as being “built on learnings from its predecessors (Appium, Espresso, UIAutomator, XCTest, Selenium, Playwright).”
The second problem is mobile UI timing. Traditional automation frameworks typically need waits hand-coded by the test author to survive animations, network latency, and loading states — a sleep() here, an explicit wait condition there, usually discovered the hard way after a flaky run. Maestro’s documentation describes built-in “Zero-Wait Intelligence” that automatically handles UI settling and network delays, plus a “Built-in Tolerance” philosophy that treats mobile device instability as something the framework absorbs rather than something every test has to defend against individually. That doesn’t eliminate every source of flakiness — a genuinely broken backend is still a genuinely broken backend — but it removes the class of flakiness caused purely by the test not waiting long enough.
Net effect: less setup work, less hand-written wait-handling code, and a YAML file readable (and often editable) by someone who doesn’t know Java or Python.
A Maestro flow, in YAML
Here’s a login flow, saved as .maestro/login.yaml:
# .maestro/login.yaml
appId: com.example.app
---
- launchApp
- tapOn: "Log In"
- tapOn: "Email"
- inputText: "[email protected]"
- tapOn: "Password"
- inputText: "hunter2"
- tapOn: "Submit"
- assertVisible: "Welcome back"appId targets the installed app’s package name (Android) or bundle ID (iOS). tapOn matches visible text or accessibility labels — not brittle XPath selectors or resource IDs tied to a specific build. assertVisible is the pass/fail check: if “Welcome back” never appears, the flow fails. Run it locally with maestro test .maestro/login.yaml; for CI, add the JUnit flag:
maestro test --format junit --output maestro-results.xml .maestro/Per Maestro’s own documentation on test reporting, “JUnit is the standard for CI/CD integration and for test reporting” — one flag, no conversion step, a standard <testsuite>/<testcase> XML file.
Maestro vs Appium: the direct comparison
Maestro and Appium get compared most directly of any two mobile UI frameworks because both are genuinely cross-platform — unlike Espresso (Android-only) or XCUITest (iOS-only). (For where all four frameworks sit side by side, see the full 4-way comparison.)
| Maestro | Appium | |
|---|---|---|
| Test format | Declarative YAML flows — no compiled code | Code in Java, Python, JavaScript, C#, etc. via a client library |
| Setup before first test | One CLI binary | Running Appium server + a platform driver (UiAutomator2, XCUITest driver) + a client language binding |
| Automation approach | Drives the UI/accessibility tree directly (“black box”) | WebDriver protocol between client and server; drivers translate to platform APIs |
| Native JUnit-XML output | Yes — maestro test --format junit | No official reporter — depends on the client harness (Surefire, pytest, @wdio/junit-reporter) |
| Built-in wait/retry handling | Yes — automatic UI-settling and network-delay tolerance | Explicit waits typically written by the test author |
| Cross-platform reach | Android, iOS, React Native, Flutter, hybrid, web — one flow file | Android and iOS via separate drivers; broad plugin ecosystem |
| License | Apache 2.0 | Apache 2.0 |
| Maintained by | mobile.dev (mobile-dev-inc), a company | OpenJS Foundation, vendor-neutral governance |
| GitHub stars (Aug 2026) | 15,330+ | 21,855+ |
| Project age | GitHub repo created 2022 | Project dates to ~2011; GitHub repo created 2013 |
| Release cadence | CLI release roughly every 2–4 weeks | Regular releases; drivers ship independently |
Appium still has the larger absolute star count and over a decade’s head start as the incumbent cross-platform framework — that’s expected for a project the OpenJS Foundation has governed since 2013. What’s more telling for “which way is this going” is growth rate: Maestro crossed 15,000+ stars in roughly four years, averaging close to 3,800 stars a year, against Appium’s roughly 1,700 a year since its repo was created — a rough approximation, not a precise CAGR, but a real signal of accelerating adoption, reinforced by a CLI that shipped five releases (cli-2.4.0 through cli-2.8.0) between April and July 2026 alone.
Maestro Cloud vs Qualflare: two different layers
Maestro Cloud is mobile.dev’s own paid product — parallel execution of Maestro flows across managed devices, with the project’s own materials citing execution-time cuts for large suites. It’s an execution layer: somewhere to run flows.
Qualflare is unrelated to that layer — a results-management and observability platform, not a device-execution product. It doesn’t provision emulators, simulators, or real devices, on Maestro Cloud or anywhere else. It ingests whatever JUnit-XML a run already produced — whether that run happened on Maestro Cloud, a self-hosted CI runner, or a local emulator — and adds run history, AI failure clustering, and flaky-flow scoring on top. Teams running flows on Maestro Cloud still want somewhere to track pass rate over time and see failures alongside their Espresso and XCTest suites; that’s what Qualflare adds, not what it competes with.
Getting Maestro results into Qualflare
Two commands, no conversion step. Maestro already writes JUnit-XML natively (see above); point Qualflare’s CLI at that file:
maestro test --format junit --output maestro-results.xml .maestro/
qf myapp collect maestro-results.xml --format maestro--format maestro labels the launch correctly in the dashboard; the underlying parsing is the same JUnit-XML path Espresso, converted XCTest output, and every other JUnit-XML framework already use — there’s no Maestro-specific parser to write or maintain. It’s the same “no conversion step” simplicity Espresso has natively, and that XCTest only reaches after converting its .xcresult bundles (see unifying Android + iOS test results). For CI wiring across GitHub Actions and GitLab CI, and for troubleshooting flaky flows specifically on CI emulators, see the dedicated Maestro test reporting guide.
For the broader picture of Android/iOS test management beyond any single framework, see the mobile testing complete guide.
Frequently asked questions
What is Maestro used for?
Maestro is used for UI and end-to-end testing of mobile and web apps — tapping through login flows, checkout flows, onboarding, and other user journeys on Android, iOS, React Native, Flutter, and hybrid apps, written as declarative YAML flows instead of compiled test code.
Is Maestro free?
The Maestro CLI and Studio are free and open-source under the Apache 2.0 license. Maestro Cloud, mobile.dev’s hosted device-execution product for running flows in parallel on managed devices, is a separate paid offering.
Does Maestro replace Appium?
Not universally — they solve overlapping but different problems. Maestro is simpler to set up and reaches JUnit-XML natively, which suits teams that want fast, declarative UI flows without maintaining a driver/server stack. Appium’s maturity, broader driver ecosystem, and deeper WebDriver-protocol control still matter for teams with complex existing Appium suites or non-standard automation needs.
Does Maestro support React Native and Flutter apps?
Yes. Because Maestro drives the UI/accessibility tree rather than framework-specific code, the same flow works against React Native, Flutter, and native Android/iOS builds without separate tooling per framework.
What is Maestro Cloud, and is it the same as Qualflare?
No. Maestro Cloud is mobile.dev’s own paid product for running Maestro flows in parallel on managed devices — it’s an execution layer. Qualflare is a results-management and observability layer: it ingests the JUnit-XML a run already produced (from Maestro Cloud or anywhere else), adds history, AI failure clustering, and flaky-flow scoring. The two are complementary, not competing.
Does Maestro produce JUnit-XML for CI reporting?
Yes, natively. Running maestro test --format junit --output <file> <flowFiles> writes a standard JUnit-XML report with no conversion step — the same simplicity as Espresso, and unlike Appium, which has no built-in JUnit reporter of its own.
