Maestro

How tests are written

Maestro flows are YAML files. A test taps a button, asserts text is visible, scrolls, and so on, declared as a list of steps rather than written as code. Someone who has never used the framework can read a flow and tell what it checks — which is unusual in mobile testing, where Appium suites tend to be dense with driver calls and explicit waits.

The design also builds in tolerance for the thing that breaks mobile tests most: timing. Maestro retries and waits on element lookups by default instead of requiring the author to anticipate every animation and network delay.

Tooling

Maestro Studio lets you build flows interactively against a running app, inspecting the view hierarchy and generating steps. Maestro Viewer handles playback inspection. Self-healing runs with local agents.

The MCP server is the piece that connects this to AI coding tools — Claude Code or Cursor can drive Maestro directly, generating and running flows as part of a development session rather than as a separate QA step.

Cost structure

Local is free and open source: Studio, the CLI, the MCP server and self-healing all run on your own devices and emulators at no charge. For a team testing on hardware it already has, that covers a lot.

Cloud is $250 per device per month and runs flows in parallel on hosted Android, iOS and web devices. The pricing is per concurrent device, so parallelism is the thing you buy. Four-way parallelism is $1,000/month. Enterprise Cloud is quoted for custom contracts, managed testing or security review.

Trade-offs

YAML is readable until a test needs real branching logic. Conditionals exist but complex flows get unwieldy in a way that a programming language would handle cleanly — at which point Appium or a code-first tool fits better.

The ecosystem is also smaller than Appium's, which has years of plugins, integrations and accumulated answers to obscure device problems. Maestro's web support exists but the product's centre of gravity is mobile.

In continuous integration

Maestro runs headless, so flows execute against emulators in CI the same way they do locally. The usual arrangement is a smoke set of flows on every pull request and the full suite nightly, since mobile emulator startup makes long suites slow regardless of framework.

The local tier being free changes the cost calculation here. Teams with their own CI runners and emulators pay nothing for unlimited execution, and the $250-per-device Cloud tier becomes a choice about parallelism and real-hardware coverage rather than a precondition for automated testing at all.

Real devices versus emulators

Emulators catch logic and layout problems. They do not catch the things that break on real hardware — vendor Android skins, aggressive battery optimisation killing background work, genuine network variability. The Cloud tier's hosted devices address that, and the honest framing is that emulator coverage in CI plus periodic real-device runs catches more than either alone.