The web has Playwright. Mobile has Appium — and a long list of half-broken alternatives, each tied to a single platform, framework, or vendor. We built Mobilewright to modernize mobile automation, which is no longer just a problem for human developers. AI agents need to drive mobile devices too.
The state of mobile automation
Mobile automation is fragmented — by platform (iOS vs Android), by framework (UIKit, SwiftUI, Jetpack Compose, React Native, Expo, Flutter, MAUI), by vendor (each cloud provider with its own driver and quirks). Appium has been the default for over a decade. Developers tolerate it more than they like it. Tests are flaky. Setup takes hours. Locators are brittle. Auto-waiting is something you cobble together, not something you get out of the box.
For human developers, this is an ergonomics problem. For AI agents, it's a structural one.
Why scripts, in the age of agents
It's a fair question. AI coding assistants are generating more native mobile code than ever — and Mobile MCP, our open-source MCP server, already lets agents drive a device directly: see the screen, list elements, tap, type. So why write a test framework at all?
Because agents driving devices in real time isn't a substitute for a deterministic scripting layer. It's a complement to one.
When something needs to run on every commit, in CI, on a schedule, across a fleet of devices, you want code that behaves the same way every time. Agent loops don't. They're slower, they're more expensive — every step burns tokens — and when they fail, you get a transcript instead of a stack trace. Scripts give you reproducibility, speed, and clean failure modes. That doesn't go away because LLMs got better at clicking buttons.
The more important point: agents shouldn't replace test scripts. They should write them. An agent generating a Mobilewright test once, and then running it deterministically a thousand times in CI, is dramatically cheaper and more reliable than an agent re-driving the same flow on every run. The scripting layer is what makes agent-authored tests useful. Writing code was never the bottleneck. Reviewing it, validating it, and testing it on real devices was. AI made that bottleneck worse.
Why Playwright is the right model
Playwright didn't reinvent web automation. It took everything painful about the previous generation of tooling — implicit waits, brittle selectors, async chaos — and fixed it. Auto-waiting became default. Locators became chainable. The CLI became zero-config. The result is a framework developers actively enjoy using, which in test tooling is rare enough to be remarkable.
Mobile deserves the same treatment.
There's also a quieter advantage to following Playwright's shape: every LLM already knows it. Playwright is one of the most heavily documented testing frameworks on the internet. That means agents can write Mobilewright tests without learning a new API — they're already fluent in the patterns.
What Mobilewright is
Mobilewright is a Playwright-based automation and testing framework for iOS and Android. One API for both platforms. Auto-waiting actions, retry assertions, chainable locators, zero-config CLI. It runs on simulators, emulators, and real devices — including real cloud devices through Mobile Use, with one config change.
Code looks like 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();If you've used Playwright, you can read that without reading the docs. That's the point.
Mobilewright supports the major mobile UI stacks today: native iOS (UIKit, SwiftUI), native Android (Jetpack Compose, Android Views), and the cross-platform frameworks people actually ship in production — React Native, Expo, .NET MAUI, Capacitor, and NativeScript. Flutter and Kotlin Multiplatform are coming.
Where it fits
Mobilewright is the scripting layer of the Mobile Next stack. You — or your agent — write Mobilewright scripts. You run them on real cloud devices through Mobile Use with one config change. And the same primitives that power those scripts — find element, tap, type, screenshot — are the ones AI agents call directly. Whether the caller is a developer, a CI pipeline, or an agent driving a live session, the underlying surface is the same.
Early, on purpose
We're publishing this at v0.0.27. That number is honest. Mobilewright is early. The core works, but there still are sharp edges.
We'd rather ship early, hear what's broken, and have you help fix it than polish in private and guess. Everything is on GitHub. Every release is in the changelog.
To make it easier to participate, we're publishing two things alongside the framework:
- A CONTRIBUTING.md. Explains how to actually contribute — how to set up the dev environment, structure a pull request, run the tests, file a useful bug report, and what kinds of changes to submit.
- A ROADMAP.md. Where we're going, what we're working on, and what's open for community contributions. If you want to know what's next, or you want to pick something up yourself, start there.
Mobilewright is free and open source, under Apache 2.0, and it will stay that way.
Try it
Here's Gil with a quick walkthrough of what Mobilewright does and how it works:
Then install:
npx mobilewright initStar us on GitHub. Join us on Slack. File issues. Open PRs. Tell us what's missing. The mobile development stack has needed a Playwright for a long time. Help us build it.