New: the QA x AI radar, the glossary and 8 ready-to-copy QA prompts.See the radar →

Tools· 2 min read

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:

  1. Waiting is handled by the tool: Maestro waits for the screen to settle before acting, which removes a large share of random failures.
  2. Readability: a PO or a functional tester can read and write a flow without learning Java.
  3. 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:

  1. Take stock of existing scenarios, and use the opportunity to delete the ones that are no longer useful.
  2. Prioritise the critical journeys, migrated and stabilised first.
  3. Run both suites side by side during the transition, so you never lose coverage.
  4. Factor out repeated steps (login, onboarding) into reusable sub-flows.
  5. 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.

// author

Ismail Haiber · Full-Stack QA Engineer

A product to make reliable, a QA team to launch or a test suite to fix? Drop me a line, I reply within 48 hours.

See the profile →