Mobilewright: Playwright for Mobile App Test Automation

Web test automation has had a clear winner for a while now — Playwright's auto-waiting, clean API, and accessibility-first locators quietly made a lot of flaky Selenium suites obsolete. Mobile automation never had that moment. Appium is powerful and battle-tested, but anyone who has set it up knows the ceremony: drivers, capabilities, platform-specific selectors, and a fair amount of Thread.sleep() scattered around to fight flakiness.

Mobilewright is the first tool I've used that feels like it's trying to give mobile the "Playwright moment."

What it is

Mobilewright is an open-source (Apache 2.0) mobile automation framework from Mobile Next HQ — the same team behind mobile-mcp. Its pitch is refreshingly direct: one deterministic API for both iOS and Android, with the developer experience Playwright users already know. It's installed from npm, written in TypeScript, and is actually built on top of Playwright.

npm install mobilewright

Crucially, it drives real devices, simulators, and emulators, and supports the frameworks teams actually build with — UIKit, SwiftUI, Jetpack Compose, Android Views, React Native, Expo, Cordova/Capacitor, and more. You're not locked into one UI stack.

The API will look familiar

Here's a login flow on iOS. If you've written Playwright, you already know how to read this:

import { ios, expect } from 'mobilewright';

const device = await ios.launch({ bundleId: 'com.example.myapp' });
const { screen } = device;

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();
await device.close();

No capabilities object, no driver setup, no explicit waits. That getByLabel / getByRole vocabulary is the same semantic-locator philosophy that made Playwright reliable on the web, now pointed at a mobile accessibility tree.

The three things that matter for flakiness

Flaky mobile tests almost always trace back to timing and brittle selectors. Mobilewright attacks both:

• Auto-waiting — every action waits for the element to be visible, enabled, and to have stable bounds before interacting. That last part matters on mobile, where animations and layout shifts cause half of all flakes.
• Chainable, semantic locators — you compose intent, e.g. screen.getByType('Cell').getByLabel('Item 1'), instead of hard-coding fragile XPaths.
• Retry assertions — expect(locator).toBeVisible() polls until it's satisfied or times out (5s by default), and supports negation with .not. No more sprinkling sleeps to "give the screen a second."

There's also a zero-config CLI that auto-discovers booted simulators and can scaffold a project, run tests, and verify your environment — so the first-run experience is minutes, not an afternoon.

The part that makes it a 2026 tool: AI agents

This is where Mobilewright gets genuinely interesting for where QA is heading. It's explicitly built for AI agents. It exposes the device's accessibility tree deterministically — no vision model required — and ships with mobile-mcp integration so an AI coding agent (Claude, Cursor, and friends) can drive a real device or simulator through the Model Context Protocol.

That mirrors exactly what Playwright's MCP server did for the web: give an agent a structured, reliable view of the UI so it can act on meaning rather than pixels. Mobilewright is doing the same thing for mobile, and it's from the team that built the MCP piece — so the two are designed to fit together.

Appium isn't going away — its ecosystem and device-cloud support are enormous. But for greenfield mobile suites, Mobilewright's ergonomics are hard to argue with.

Should you adopt it yet?

An honest caveat: Mobilewright is young. At the time of writing it's around v0.0.49 (released mid-July 2026), moving fast, with ~4,500 GitHub stars and growing. For a mission-critical release pipeline today, I'd pilot it alongside an existing Appium suite rather than rip-and-replace. But the direction is clearly right, and the API is stable enough to start learning now.

For QA engineers, the takeaway is simple: the skills you built on Playwright — semantic locators, auto-waiting, web-first assertions — transfer almost directly to mobile through Mobilewright. That's a rare and valuable kind of leverage.