Maestro
Modern, YAML-based mobile UI testing. Simple syntax, fast setup, and cross-platform support for iOS and Android.
Overview
Maestro, created by mobile.dev (now part of Robinhood) in 2022, is a modern mobile UI testing framework that uses simple YAML files to define test flows. It aims to solve the complexity and flakiness of existing mobile testing tools by providing a declarative, human-readable syntax and built-in synchronisation that waits for UI elements automatically.
Maestro has gained rapid adoption in 2024-2025 as teams seek simpler alternatives to Appium. It supports both iOS and Android, runs on simulators and real devices, and can be integrated into CI/CD pipelines with minimal configuration.
What it's used for
Maestro is perfect when:
- Simple mobile test automation needed: Write tests in YAML without coding knowledge.
- Cross-platform mobile testing: One YAML test runs on both iOS and Android.
- Fast setup is critical: Install via Homebrew, write a YAML file, run — no complex configuration.
- Flaky tests from Appium: Maestro's built-in synchronisation reduces timing issues.
Pros & Cons
Pros
- Extremely simple YAML syntax — no coding required
- Cross-platform iOS and Android support
- Built-in element synchronisation reduces flakiness
- Fast installation and setup
- Free and open source
Cons
- Newer tool with smaller community than Appium
- Less flexible for complex test scenarios
- Limited debugging capabilities compared to IDE-integrated tools
- Not as mature as Espresso/XCUITest for native apps
- Some advanced gestures and interactions are not yet supported
Platforms & Integrations
Maestro runs on macOS, Windows, and Linux. It tests iOS (simulator and device) and Android (emulator and device) apps.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Full framework, all features, community support |
| Maestro Cloud | From $99/mo | Cloud device farm, parallel execution, analytics |
NZ Context
Maestro is gaining traction in NZ mobile teams that find Appium too complex or flaky. Several NZ startups have adopted Maestro for its simplicity. For NZ QA professionals looking to add mobile testing skills, Maestro is the fastest path from zero to running tests.
Alternatives
- Appium — More mature and flexible but harder to set up and maintain.
- Detox — Better for React Native specifically.
- Espresso / XCUITest — Native frameworks for Android-only or iOS-only teams.
When to choose Maestro
A quick decision guide for NZ teams evaluating mobile testing options.
| Choose Maestro when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team writes YAML or JSON config files but has no Appium/Selenium experience — Maestro's syntax is learnable in a day. | You need deep native-gesture control (drag-to-refresh, pinch-zoom at precise coordinates) — use Espresso on Android or XCUITest on iOS instead. | Bitrise or GitHub Actions for CI scheduling; BrowserStack App Automate if you need a cloud real-device farm without Maestro Cloud pricing. |
| You have a React Native or Flutter app and want one test suite that covers both iOS and Android without maintaining two frameworks. | Your app is a pure native iOS app with complex SwiftUI animations — XCUITest has far better introspection of SwiftUI accessibility trees. | Playwright or Cypress for the web layer of a cross-platform product; Maestro handles the mobile shell while web tooling covers the browser surface. |
| Appium tests are constantly breaking due to timing issues and the team is spending more time fixing tests than writing them — Maestro's auto-synchronisation solves the root cause. | You need WebView or hybrid-app DOM inspection at the element level — Appium's WebDriver protocol gives you direct access; Maestro treats WebViews as opaque. | Allure Report for test result visualisation; Percy or Chromatic for visual regression snapshots on top of Maestro's flow assertions. |
| Startup or small team with no dedicated automation engineer — Maestro lets a manual tester record and run flows without writing code. | You need to test Bluetooth, NFC, or hardware peripherals — no mobile UI testing framework solves this; you need device-lab tooling or manual testing protocols. | k6 or Artillery for load testing the API behind the app; Maestro covers the UI layer while a separate performance tool validates the backend under realistic concurrency. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I was the QA lead at ListRight and our Appium suite was taking 40 minutes per run with a 30% flake rate on the React Native app
I would…
Port the top 20 critical-path flows to Maestro over a two-week spike — not a full rewrite, just the flows that break most often. Run Maestro and Appium in parallel for one sprint to compare flake rates and execution time. If Maestro wins (it almost certainly will on React Native), migrate the rest incrementally. Keep Appium only for the WebView flows that Maestro can't inspect. The goal is a sub-10-minute smoke suite that engineers actually trust and run before merge, not a theoretical framework migration.
If…
I was setting up mobile testing from scratch at KiwiFirst Bank for a new Flutter-based banking app targeting both iOS and Android
I would…
Start with Maestro for all happy-path UI flows — account summary, payments, biometric login. Flutter's semantic tree is well-supported and the YAML syntax means non-coders on the team (business analysts, manual testers) can read and review test flows during sprint ceremonies. I would pair it with k6 for API-layer load tests simulating peak payroll days, and BrowserStack real devices for the final release regression rather than Maestro Cloud — BrowserStack gives access to the specific Samsung and iPhone models that KiwiFirst Bank's support data shows are most common in NZ. I would not use Maestro for the security layer; those tests belong in a dedicated OWASP Mobile Security Testing Guide checklist run by a specialist.
If…
I was a solo QA contractor hired by Foodstuffs NZ to build automated regression for their customer-facing mobile grocery app, with a three-month engagement and no existing automation
I would…
Use Maestro unconditionally. Three months is not enough time to build, stabilise, and hand over an Appium framework — the setup complexity alone would consume the first four weeks. With Maestro I can have 30 flows covering search, add-to-cart, checkout, and loyalty points running in CI within two weeks. The remaining time goes into coverage breadth and writing a handover guide that a developer can maintain without a QA specialist. I would store all flows in the main repo under /e2e/maestro/, wire them into the existing GitHub Actions pipeline, and document the maestro test command in the project README. That is something Foodstuffs devs can actually keep alive after I leave.
The bottom line: Maestro earns its place when the cost of maintaining tests exceeds the cost of writing them — that tipping point usually arrives within six months on any active Appium suite. Choose Maestro early and spend your time on coverage, not framework archaeology.
Interview questions
Questions you are likely to get if you list Maestro on your CV — with what interviewers are really testing for.
What is the difference between Maestro and Appium, and why would you choose one over the other?
What they’re really testing: Whether you understand the trade-offs at a technical level or just copied "Maestro" onto your CV because it sounded modern.
Strong answer covers: Maestro’s declarative YAML syntax vs Appium’s WebDriver protocol and code-first tests; Maestro’s built-in auto-synchronisation vs Appium’s explicit waits; and the honest limitation that Maestro treats WebViews as opaque while Appium can inspect hybrid-app DOM. A NZ angle: many NZ teams still run Appium because their existing frameworks pre-date Maestro — knowing when migration is worth the cost shows maturity.
When would you use Maestro over Detox for a React Native app?
What they’re really testing: Whether you can navigate framework choices without defaulting to "it depends" with no follow-up.
Strong answer covers: Detox runs inside the RN JS thread giving it deeper introspection and deterministic synchronisation, making it better for complex state-driven flows; Maestro wins when you want cross-platform coverage from one YAML file and your team has non-coders (BAs, manual testers) who need to read and review tests. Mention that Detox requires Xcode and Android Studio fully configured on CI, which adds pipeline setup time that many NZ teams underestimate.
You’re joining CloudBooks NZ as the QA lead on their iOS and Android expense-management app. The existing Appium suite has a 35% flake rate and takes 50 minutes to run. How would you approach improving this with Maestro?
What they’re really testing: Whether you can translate tool knowledge into a realistic migration plan with business trade-offs, not just a "rewrite everything" answer.
Strong answer covers: Start with a two-week spike porting the top 15 highest-flake flows to Maestro and running both suites in parallel to compare metrics; avoid a big-bang rewrite. Keep Appium for any WebView flows that Maestro can’t inspect (CloudBooks’s in-app browser screens). Target a sub-10-minute Maestro smoke suite that runs on every PR, with the full Appium suite demoted to nightly. Quantify the win: 35% flake → near-zero, 50 min → ~8 min, team trust restored.
Your Maestro flows pass on your local simulator but fail consistently in GitHub Actions CI. How do you debug this?
What they’re really testing: Practical debugging instinct — can you reason about environment differences, or do you just re-run until it passes?
Strong answer covers: Check CI runner specs first — GitHub-hosted macOS runners are slower than a dev machine so animations and transitions may not complete within Maestro’s default timeouts; add extendedWaitUntil or increase the global timeout. Verify the app build variant (debug vs release) matches what you test locally — release builds have ProGuard/minification that can change element IDs. Check that the simulator iOS/Android version in CI matches your local setup. Use maestro test --debug-output to get screenshots at failure points.
How would you structure a Maestro test suite for a large mobile app so it scales as the product grows?
What they’re really testing: Whether you’ve thought about maintainability and CI strategy, not just writing individual YAML files.
Strong answer covers: Organise flows under /e2e/maestro/ in the main repo, grouped by feature domain (auth, payments, profile) rather than by platform. Use Maestro’s runFlow command to extract reusable login and navigation sub-flows so they aren’t copy-pasted across 50 tests. Tag flows with tags for smoke vs regression vs edge-case, then run only the smoke tag on PR and the full suite nightly. For a large NZ enterprise like TeleNZ with concurrent iOS and Android releases, add Maestro Cloud or BrowserStack to parallelise across real devices and cut wall-clock time.