Maestro review: mobile testing pricing, pros and cons

Maestro describes its model as arm’s length: it pilots the device rather than the app. The CLI installs a small companion driver on the Android device or iOS simulator, reads the screen through the operating system’s accessibility tree and sends low-level taps, swipes and text input. Because nothing is compiled into the app, the same flow works on native, React Native and Flutter builds, and Maestro can act on anything the device shows, including permission dialogs, notifications, Settings and other apps. The trade is that a flow knows only what the accessibility tree exposes, so elements without text, content descriptions or identifiers are hard to target.

A flow is a YAML file with a header, holding the appId or a web url, tags and other settings, and a list of commands such as launchApp, tapOn, inputText, scrollUntilVisible and assertVisible. The CLI interprets it directly, so there is no build step, and continuous mode reruns a flow every time you save it. That speed of iteration is the main reason a first flow takes minutes rather than days. Reuse comes from runFlow, which calls another flow file or an inline block, optionally with its own variables.

Maestro’s documentation calls this built-in tolerance. Commands wait for the screen to settle before acting, and assertions such as assertVisible and assertNotVisible poll the UI until the condition holds or a timeout passes, then continue at once. extendedWaitUntil sets a longer timeout for slow work such as payments, and waitForAnimationToEnd covers movement after a transition. The effect is that flows rarely contain explicit waits. The limit is that tolerance cannot fix genuine instability, and a retry block wrapped around a whole flow can hide it, which the docs themselves call an anti-pattern.

When a flow needs logic, Maestro runs JavaScript in a sandbox: inline expressions inside ${...}, evalScript for logic-only steps and runScript for external files. GraalJS is the engine from Maestro 2.0, with modern JavaScript syntax. Scripts have no file system or Node.js modules, but get a built-in HTTP client, a faker object for test data and a shared output object for passing values back to later commands. It is enough for creating a user through an API or generating unique emails, and deliberately not a general programming environment.

Keep flows in a .maestro folder at the repository root, which is also the default workspace for the Cloud GitHub Action. By default the CLI runs only flows at the top level of the folder, so add a config.yaml with flows patterns as soon as you create subfolders, and use negation patterns to keep helper files out. Put shared steps such as signing in under a subflows folder and call them with runFlow, passing variables with env. Tag every flow, at least smoke or regression, so CI can choose a subset without moving files. Keep each flow to one journey; long flows are slower to debug and run into Cloud’s 20-minute soft limit.

Use runFlow with a when block for genuinely optional screens, such as a rating prompt or a platform-specific permission dialog, and keep separate flows for scenarios that differ a lot; the docs warn that heavy conditional logic makes flows hard to read. For test data, a runScript step can call your API through Maestro’s HTTP client and store values on the output object, which later commands read inside ${...}. This keeps setup out of the UI, which is faster and less flaky than creating accounts through screens. Use retry sparingly, around a single unstable step with maxRetries between 0 and 3, never around a whole flow.

Without Maestro Cloud, a Linux runner can host an Android emulator: enable KVM, install Java 17 and the CLI, add ~/.maestro/bin to the path, and let the android-emulator-runner action boot the emulator and run your commands. Pin the CLI with MAESTRO_VERSION so a new release cannot change behaviour between runs of the same commit, and write a JUnit report plus the test output folder so failures can be inspected after the runner is gone. iOS flows need a macOS runner with a booted simulator instead.

There are two ways to run faster. Locally, start several emulators or simulators and pass --shard-split with the device count so flows are divided between them; this costs nothing but machine capacity, and iOS needs a Mac. With Maestro Cloud, the official action mobile-dev-inc/action-maestro-cloud uploads the app file and the .maestro workspace with an API key and project id, runs flows in parallel on hosted devices, and accepts include-tags, device-model, device-os and device-locale inputs. It requires a Cloud plan. Whichever you choose, keep flows independent, starting from launchApp with clearState where needed, because sharded flows run in no guaranteed order.

Each run writes an artifact bundle with a screenshot before every step, device logs and, on failure, the view hierarchy, so start there rather than rerunning. maestro hierarchy prints the current tree as JSON, Maestro Viewer shows commands and the live hierarchy, and maestro record turns a flow into a video for bug reports. Before upgrading, read the changelog: 2.0 moved to Java 17 and GraalJS and dropped URLs in appId in favour of url; 2.6 removed the Rhino engine and the bundled Studio; 2.7 discontinued maestro chat in favour of MCP. The next release will also reject out-of-range scroll speeds and negative point coordinates that were previously ignored.