Releaseworthy
Start a pilot
Menu

Mobile testing

Maestro vs Appium vs Mobilewright: choosing a mobile test framework in 2026

Maestro vs Appium vs Mobilewright, compared from their official docs: how tests are written, iOS and Android support, setup, CI, device clouds and licenses.

Published 9 min read

Maestro vs Appium is mostly a question of how your team wants to write tests and which devices they must run on. Appium is the established option built on a standard: a server that speaks the W3C WebDriver protocol, a driver per platform, clients in Java, Python, Ruby, C# and JavaScript, and support for simulators, emulators and real devices. Maestro trades that flexibility for simplicity: tests are short YAML flows run by one CLI that treats your app as a black box, and its docs list iOS support for simulators only. Mobilewright, the newest, brings Playwright’s API to iOS and Android in TypeScript, but its first release was in March 2026 and it is still at version 0.0.67.

Every fact below comes from each project’s own documentation, checked on October 18, 2026, with Detox and the native frameworks added for context.

Maestro vs Appium vs Mobilewright: how tests are written

The quickest way to see the difference is the same sign-in test in each tool.

Appium: WebDriver clients in your language

Appium is a Node.js server. Your test is a client that sends WebDriver commands over HTTP, and a driver turns them into platform automation: the XCUITest driver converts them into calls to Apple’s XCUITest library, and the UiAutomator2 or Espresso driver does the same on Android. The Appium team maintains clients for Java, Python, Ruby and C#, and its quickstart recommends WebdriverIO for JavaScript and TypeScript.

import { remote } from 'webdriverio';

const driver = await remote({
  hostname: 'localhost',
  port: 4723,
  capabilities: {
    platformName: 'Android',
    'appium:automationName': 'UiAutomator2',
    'appium:appPackage': 'com.example.shop',
    'appium:appActivity': '.MainActivity',
  },
});

try {
  await driver.$('~email').setValue('user@example.com');
  await driver.$('~password').setValue('password123');
  await driver.$('~sign_in').click();
  await driver.$('~welcome_banner').waitForDisplayed();
} finally {
  await driver.deleteSession();
}

The ~ selector is an accessibility id: the accessibility identifier on iOS and the content description on Android, so one test can drive both apps if they share ids. Appium 3 came out in August 2025 with small breaking changes, mainly a newer minimum Node.js and removed deprecated endpoints.

Maestro: YAML flows

Maestro tests, called flows, are YAML files that read like instructions. The open-source CLI drives the device from outside the app through a small companion driver app, so you add nothing to your build.

appId: com.example.shop
---
- launchApp
- tapOn:
    id: 'email'
- inputText: 'user@example.com'
- tapOn:
    id: 'password'
- inputText: 'password123'
- tapOn: 'Sign in'
- assertVisible: 'Welcome back'

Run it with maestro test signin.yaml, or maestro test -c to rerun it every time you save. When YAML is not enough, a flow can run JavaScript in a restricted environment without access to the local file system. Maestro Studio, a desktop app, builds flows as you click elements on a mirrored device screen.

Mobilewright: Playwright’s API on a phone

Mobilewright comes from Mobile Next, the makers of Mobile MCP, and runs on their mobilecli tool. Its @mobilewright/test package extends Playwright Test with screen and device fixtures, so locators, expect, reporters, workers and retries follow Playwright Test.

import { test, expect } from '@mobilewright/test';

test('can sign in', async ({ screen }) => {
  await screen.getByLabel('Email').fill('user@example.com');
  await screen.getByLabel('Password').fill('password123');
  await screen.getByRole('button', { name: 'Sign In' }).tap();
  await expect(screen.getByText('Welcome back')).toBeVisible();
});

getByRole maps roles to each platform’s native element types. A team that already writes Playwright tests (see agentic testing with Playwright) will recognize every line.

Tool Tests are Languages
Appium Client code sending WebDriver commands Java, Python, Ruby, C#, JavaScript and more
Maestro YAML flows, with optional JavaScript YAML
Mobilewright Playwright style test files TypeScript or JavaScript

Platforms and devices

Tool iOS Android
Appium Simulators and real devices Emulators and real devices
Maestro Simulators Emulators and physical devices
Mobilewright Simulators and real devices Emulators and real devices

If you must test on physical iOS devices, that settles the Maestro vs Appium question first: Maestro’s docs list only simulators for iOS.

Real iOS devices take work in Appium: the XCUITest driver installs a helper app (WebDriverAgent) that needs a valid provisioning profile, and the device needs Developer Mode and the Enable UI Automation setting turned on. Appium also reaches beyond phones: Apple TV, Apple Watch simulators (since September 2026), Android TV, Wear, XR and Automotive, plus macOS, Windows and desktop browsers.

Tool React Native Flutter
Appium No dedicated driver Two drivers outside the official set
Maestro Supported, including Expo Go and EAS builds Supported through the semantics tree
Mobilewright Supported on iOS and Android Since version 0.0.60, debug builds only

Appium has no React Native driver; its XCUITest driver docs simply note that a React Native testID becomes the element’s name. Maestro does not yet support Flutter desktop apps, and it describes its web support as functional with ongoing development.

Setup effort

Tool You install For iOS you need
Appium Node.js, the server, a driver per platform, a client macOS with Xcode
Maestro Java 17 or newer and one CLI macOS with Xcode
Mobilewright Node.js 22.12 or newer and two npm packages macOS 13 or newer with Xcode
  • Appium has the most moving parts: the server (npm install -g appium), a driver per platform (appium driver install uiautomator2), and each platform’s toolchain, meaning the Android SDK and a JDK, or Xcode. Each official driver ships a doctor command, such as appium driver doctor xcuitest.
  • Maestro installs with curl, Homebrew or a zip on Windows. It expects your app to be installed on the device already, and maestro start-device creates an emulator or simulator for you.
  • Mobilewright scaffolds a project with npm init mobilewright@latest, and npx mobilewright doctor checks Xcode, the Android SDK and devices. Android needs JDK 11 or newer, and on Linux Android tests run through its Docker image. It does not boot a simulator or emulator for you.

Waiting and flakiness: what each tool documents

We leave speed out, because vendor speed claims are not benchmarks we could check, and compare how each tool waits for the app instead.

  • Appium: the drivers wait for the app to go idle before acting. UiAutomator2 waits for the accessibility event stream (the waitForIdleTimeout setting, 10 seconds by default), and the XCUITest driver waits for the app’s main thread, also 10 seconds by default. Waiting for a specific element is up to your test, for example waitForDisplayed() in WebdriverIO.
  • Maestro: assertions poll the screen until the element appears or a timeout passes. extendedWaitUntil covers slow operations, waitForAnimationToEnd waits for movement to stop, and retryTapIfNoChange retries a tap when the screen does not change. clearState resets app data before launch, and Maestro Cloud wipes and recreates each virtual device between tests.
  • Mobilewright: before every action it checks that the element exists, is visible, is enabled and has stable bounds, retrying every 100 ms up to a default timeout of 5 seconds. Assertions retry the same way, and the config has a retries option.

Retries are a safety net, not a fix. A test that passes only on the second attempt still needs its cause found, just like a flaky web test (see flaky tests in Playwright).

CI and device clouds

Tool In CI Device clouds
Appium Start the server in your pipeline BrowserStack, LambdaTest
Maestro maestro test, or Maestro Cloud integrations Maestro Cloud
Mobilewright Documented GitHub Actions setup Mobile Next Cloud, BrowserStack

For iOS, plan on macOS runners with any of the three.

  • Appium is a plain server, so any CI that can start it and reach a device works, and its docs include a guide to Selenium Grid. The Appium blog describes BrowserStack’s and LambdaTest’s clouds as supporting Appium; both, with Sauce Labs, fund the project as strategic partners.
  • Maestro can split a suite across several local devices with --shard-split. Maestro Cloud runs flows in parallel on hosted virtual devices, with integrations for GitHub Actions, Bitrise, Bitbucket Pipelines and CircleCI, and it can block a GitHub pull request when tests fail.
  • Mobilewright supports parallel workers, sharding and merging the reports of sharded CI runs. Its documented clouds are Mobile Next Cloud from the same team, BrowserStack App Automate through @browserstack/mobilewright, and one more provider through @testingbot/mobilewright-driver.

License, maturity and lock-in

Tool License Version on October 18, 2026
Appium Apache 2.0 3.8.0, with Appium 4 in beta
Maestro Apache 2.0 (the CLI) CLI 2.11.0
Mobilewright Apache 2.0 0.0.67
Detox MIT 20.51.3

All are open source, and Maestro and Mobilewright each have a hosted cloud from the same company. Mobilewright is the one to check carefully: its first npm release was on March 24, 2026, it shipped eight releases in the four weeks to October 18, 2026, and its public roadmap still lists push notifications, biometrics, network interception, device logs and tracing as planned. It also collects anonymous usage telemetry by default; set MOBILEWRIGHT_DISABLE_TELEMETRY=1 or DO_NOT_TRACK=1 to turn it off.

The tests never lock you in, since they are files in your repository. They do not translate into each other, though: moving from YAML flows to TypeScript, or from Appium’s Java client to Maestro, means rewriting the suite. Choose for the next few years, not the next sprint.

Detox and the native frameworks, for context

Detox

If you are weighing Maestro vs Appium vs Detox, start from what Detox is built for: React Native apps. It is a gray box framework from Wix: tests are JavaScript, with Jest integration out of the box, and Detox monitors network requests, timers, animations and the React Native threads, then waits for them to finish before the next step. Its site says real devices are not yet supported on iOS. Choose it when React Native developers will own the tests; choose Maestro for black box flows.

Espresso and XCTest

Google’s Espresso (Kotlin or Java) and Apple’s XCTest with the XCUIAutomation framework live inside each app project. Espresso waits until the message queue has nothing it must process, no AsyncTask is running and your idling resources are idle, and Android’s docs aim it at developers who know the codebase. Xcode can record your interactions and write the element queries for you. Appium builds on both: its XCUITest driver runs on XCTest, and it has an Espresso driver.

How to choose by situation

There is no best mobile testing framework in general, only the best fit for one app and one team. Here is how the documented facts map to common situations:

  • You must test on physical iOS devices: Appium or Mobilewright.
  • Your test authors write Java, Python, Ruby or C#: Appium, the only one of the three with clients in those languages.
  • People who do not write code should read and review the tests: Maestro, whose flows are human-readable YAML that Maestro Studio can build by clicking.
  • Your web tests are Playwright and TypeScript: Mobilewright vs Appium then comes down to familiarity against maturity. Mobilewright wins on familiarity; check its roadmap for every device feature your flows need.
  • A hybrid app built on web views (Cordova, Capacitor, Ionic): Mobilewright gives you a Playwright page inside the web view; Appium’s main drivers also have hybrid and web modes.
  • A Flutter app: Maestro, or Mobilewright with a debug build. Appium needs a driver from outside the official set.
  • TV, watch or desktop apps as well as phones: Appium, the only one of the three whose docs cover them.
  • One platform, with developers who own their UI tests: Espresso or XCTest, at the cost of a separate suite per platform.

Whatever you pick, start with the few flows that would hurt most if they broke, as in risk-based testing. A mobile test automation framework is easier to judge on ten real tests than on a feature list.

How we pick a framework for your app

We do not have a house framework. For each app we answer the questions above: which platforms and devices matter, what the app is built with, who on your team will read the tests, and which CI and device cloud you already use. Then we choose Appium, Maestro or Mobilewright with you in the first week. The tests are plain code in your repository and run in your CI on every pull request. Claude agents write and maintain them, a QA engineer reviews every change before it is merged, and a person looks at every failure before it becomes a bug report or a test fix. The mobile app testing page covers the mobile side, and how it works shows a week of the service.

Sources

All checked on October 18, 2026.

Researched and drafted with Claude, Anthropic's AI model, and checked against the sources it links. Spotted an error? Tell us and we will correct it.

Keep reading

Every post

Mobile tests in the framework that fits your app

We pick Appium, Maestro or Mobilewright for each app. Claude agents write and maintain the tests in your repository, and a QA engineer reviews every change and every failure.

Start a pilotMobile app testing, run as a service

Or write to qa@releaseworthy.app. Still deciding after the proposal? We book a Google Meet call for your questions.