Moving mobile tests from Appium to Maestro: my takeaways
I led the migration of an Appium mobile test suite (Java, Cucumber) to Maestro. Why switch, how to organise the move, and the traps to avoid.
On my current assignment, I led the migration of mobile tests from an Appium + Java + Cucumber stack to Maestro. It’s not a decision to take lightly: a test suite represents months of work. Here are my takeaways.
Why move away from Appium?
Appium remains a reference, and for good reasons: it’s versatile, standard, and built on WebDriver. But as a suite grows, several things start to weigh:
- Speed: every command goes through several layers before reaching the device.
- Instability: badly tuned explicit waits produce tests that fail at random.
- The entry cost: a Java + Cucumber + Appium project needs a real developer profile to maintain.
What Maestro changes
Maestro describes journeys in plain YAML files:
appId: com.example.app
---
- launchApp
- tapOn: "Log in"
- inputText: "demo@example.com"
- tapOn: "Submit"
- assertVisible: "Welcome"
Three differences stood out for me:
- Waiting is handled by the tool: Maestro waits for the screen to settle before acting, which removes a large share of random failures.
- Readability: a PO or a functional tester can read and write a flow without learning Java.
- The feedback loop: you write and replay a flow in a few seconds while fine-tuning it.
How to organise the migration
A successful migration doesn’t mean translating tests one by one. My approach:
- Take stock of existing scenarios, and use the opportunity to delete the ones that are no longer useful.
- Prioritise the critical journeys, migrated and stabilised first.
- Run both suites side by side during the transition, so you never lose coverage.
- Factor out repeated steps (login, onboarding) into reusable sub-flows.
- Measure every sprint: number of scenarios migrated, pass rate, run time. These KPIs are presented at the sprint review, which makes progress visible to everyone.
Traps to avoid
- Fragile selectors: relying on displayed text is convenient, but it changes with translations. Ask the developers for stable accessibility identifiers; it also improves the app’s accessibility.
- Trying to do everything in YAML: for data setup (creating accounts, business states), it’s better to call an API beforehand than to click through the app.
- Forgetting CI: a flow that doesn’t run on every build silently decays.
In short
Maestro isn’t magic, but for end-to-end mobile journeys it makes tests faster to write, more stable and readable by the whole team. If you’re hesitating, migrate a single critical journey first and compare: the numbers from your own suite will be worth more than any opinion.


