Maestro is an open-source framework for mobile UI testing. Test cases are described as YAML flows instead of written as test code, and the same file can run against iOS and Android. Wait conditions for animations and loading states are part of the tool rather than manual work inside each test.

Maestro vs. Appium or Detox — when to use which?

Maestro plays to its strength when flows should be written quickly and stay readable — including for people who do not write test code. Appium is the broader, older standard with very far-reaching control and correspondingly more setup. Detox is tightly tailored to React Native and works very close to the app process in return. We choose based on your team, your platforms and what stays maintainable in your CI.

How long does it take to build a flow suite?

That depends on scope — on the number of screens, states and platforms. First working flows for the core paths take days; a robust suite across a grown app then keeps growing step by step. We only give a serious estimate after we have seen your app.

Does this work with React Native and Flutter?

Yes. Maestro tests black-box at the UI level and does not care what the app was built with — React Native, Flutter or native. The only requirement is that the elements under test are addressable via test IDs or visible text.

Terms on request. Effort and scope differ too much per app for a list price — we look at where you stand and then name a concrete range.

Mobile E2E Testing

Mobile E2E testing with Maestro

Reproducible release quality for iOS and Android — instead of clicking through half the app by hand before every store release. Maestro describes test cases as YAML flows that check the same interface on both platforms.

Book an intro call Read the Maestro tutorial on our blog

Why mobile E2E is different

What works on the web does not translate one-to-one to a device. Three differences that drive the effort.

Device diversity & OS versions

The same app behaves differently on a current iPhone than on a three-year-old Android device: screen sizes, permission dialogs, system font scaling and OS versions produce combinations nobody covers by hand any more.

Flakiness from animations & timing

Transitions, loading states and network latency make naively written tests unreliable. Stable flows wait for states, not for seconds — otherwise the suite fails every other run and gets ignored.

Store release cycles with no hotfix path

A bug on the web is deployed in minutes. An app has to pass store review — days go by before the fix reaches users. Whatever was not tested before the release stays visible.

The tools we work with

Maestro for the interface, Jest for the logic, our own open-source tools for test data and time-dependent flows — all anchored in CI.

Maestro

Open-source framework for mobile UI testing. Test cases are YAML flows instead of test code — the same file runs against iOS and Android, and wait conditions are built in rather than sprinkled in afterwards.

Jest

For everything that needs no screen: calculations, state machines, data models. Logic bugs surface in milliseconds there instead of slowing down an E2E suite later.

nanook & bitdiver — our own open source

nanook generates test data from equivalence classes instead of hand-maintained sample values. bitdiver covers time-dependent end-to-end testing through a YAML configuration. Both grew out of our own testing work and are freely available.

Visit nanook.xhub.io Visit bitdiver.xhub.io

CI/CD integration

Flows run automatically on every pull request and before every store submission. Results and screenshots land in the build — not on one person’s machine.

How we know this

We run Maestro flow suites not only for client projects, but for our own apps in the store.

Our own apps in the store

TankKosten and LadeKosten are our own mobile apps. Their release flows — app launch, onboarding, creating records, export — are maintained as Maestro suites and run before every submission. What we recommend, we carry through store review ourselves.

See app development

QA lead

Torsten Link

CTO & co-founder

Experienced software architect focused on quality assurance, test automation and CI/CD pipelines. Among other things he owned the QA strategy for Deutsche Bahn’s passenger information system and architected test automation across hundreds of microservices. More than 11 years of Node.js and TypeScript development.

What a flow looks like

A simplified example in the structure we also use in our own suites.

vehicle/add-vehicle.yaml

# Smoke flow: add a vehicle
appId: com.example.app
tags:
  - smoke
  - regression
name: "Add vehicle"
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow

# Wait for a state, not for seconds
- extendedWaitUntil:
    visible: "Dashboard|Welcome"
    timeout: 15000

- tapOn:
    id: "add-vehicle-button"
- assertVisible: "New vehicle"

- tapOn:
    id: "manufacturer-input"
- inputText: "Example Motors"
- pressKey: enter

- tapOn:
    id: "model-input"
- inputText: "Example Model"
- pressKey: enter

- tapOn:
    text: "Save vehicle"

# Assert the result — not just "it did not crash"
- assertVisible:
    text: "Example Motors Example Model"
    timeout: 10000

- takeScreenshot: vehicle-created

The flow launches the app with cleared state so every run starts identically. Instead of fixed sleeps, "extendedWaitUntil" holds until an expected screen is visible — that is the main lever against flakiness. Elements are addressed through stable test IDs rather than positions, and the run ends with a real assertion plus a screenshot as evidence in the build.

What we take on

From deciding what belongs in automation at all to a suite that runs inside your pipeline.

E2E strategy & flow design — which paths get automated and which stay deliberately manual
Building the flow suite — reusable sub-flows, stable test IDs, reliable wait conditions
CI integration — flows run on every pull request and before every store submission
Test data strategy — reproducible starting states instead of whatever happens to be on the device

Terms on request

Scope and effort depend on how many flows your app actually needs. We look at your app and tell you where a sensible start is.

Book an intro call

30 minutes, no strings attached.

Frequently asked questions

What teams usually want to know before getting into mobile E2E testing.

What is Maestro?: Maestro is an open-source framework for mobile UI testing. Test cases are described as YAML flows instead of written as test code, and the same file can run against iOS and Android. Wait conditions for animations and loading states are part of the tool rather than manual work inside each test.
Maestro vs. Appium or Detox — when to use which?: Maestro plays to its strength when flows should be written quickly and stay readable — including for people who do not write test code. Appium is the broader, older standard with very far-reaching control and correspondingly more setup. Detox is tightly tailored to React Native and works very close to the app process in return. We choose based on your team, your platforms and what stays maintainable in your CI.
How long does it take to build a flow suite?: That depends on scope — on the number of screens, states and platforms. First working flows for the core paths take days; a robust suite across a grown app then keeps growing step by step. We only give a serious estimate after we have seen your app.
Does this work with React Native and Flutter?: Yes. Maestro tests black-box at the UI level and does not care what the app was built with — React Native, Flutter or native. The only requirement is that the elements under test are addressable via test IDs or visible text.
What does it cost?: Terms on request. Effort and scope differ too much per app for a list price — we look at where you stand and then name a concrete range.

Let’s talk about your test coverage

Tell us how your app is checked before a release today — we’ll tell you what of that can be automated.

Book an intro call See app development

30 minutes, no strings attached. Reply within 24 hours.

# Smoke flow: add a vehicle appId: com.example.app tags: - smoke - regression name: "Add vehicle" --- - launchApp: clearState: true permissions: notifications: allow # Wait for a state, not for seconds - extendedWaitUntil: visible: "Dashboard|Welcome" timeout: 15000 - tapOn: id: "add-vehicle-button" - assertVisible: "New vehicle" - tapOn: id: "manufacturer-input" - inputText: "Example Motors" - pressKey: enter - tapOn: id: "model-input" - inputText: "Example Model" - pressKey: enter - tapOn: text: "Save vehicle" # Assert the result — not just "it did not crash" - assertVisible: text: "Example Motors Example Model" timeout: 10000 - takeScreenshot: vehicle-created