Mobilewright - Playwright for iOS and Android. Free and open source
byβ’
Playwright for iOS and Android. One unified API to automate real devices, simulators, and emulators β deterministic, auto-waiting, zero-config. Built for developers and AI agents.
Replies
Best
Hunter
π
Hi PH π
I'm Leor, co-founder of Mobile Next. We build tooling for the agentic era of mobile development.
Mobile testing has been painful for a long time. The frameworks were built for a world where humans write tests by hand, on one platform at a time. None of them were designed for AI agents writing code, and most don't work cleanly across iOS and Android.
Mobilewright is our take. A Playwright-based automation framework for iOS and Android β chainable locators, auto-waiting on every action, and tests that read like English. Zero-config CLI, free and open source.
If you've been wrestling with mobile testing, what's been hardest? I am in the comments.
@leor_sternΒ The cross-platform angle with Playwright's syntax is smartβmost teams are tired of maintaining separate test suites for iOS and Android. Curious how you're handling the platform-specific quirks under the hood, especially around native gesture recognition and timing issues that usually trip up automation frameworks.
Report
Hunter
@osakasaulΒ Thanks Saul β that's exactly the pain point we built against. Two things under the hood:
Auto-waiting eliminates the timing problem. Every action (tap(), fill(), assertions) polls the device for the element before acting. No sleeps, no arbitrary timeouts. This is architecturally different from Appium, where the HTTP round-trip model forces you into manual waits that cause most of the flakiness people associate with mobile automation.
One engine, platform-aware mapping. Under the hood, Mobilewright talks to mobilecli β our single Go binary that replaces simctl, adb, etc. When you write screen.getByRole('button'), it maps to Button on iOS and Button/ImageButton/ReactViewGroup (with clickable=true) on Android. Same for gestures β swipe('up') translates to the right coordinate math per platform. You write one test, the framework handles the translation.
The result is you get deterministic execution without platform-specific test code. Happy to go deeper on any of this, or show you a demo.
Report
@leor_sternΒ thanks for this, a great tool that im using as we speek :-)
Report
This is directly related to what Iβm working on and it works.
It is very promising, I did wright few script with mobilewright, simple configuration, easy setup and better execution. my final thought is, for sure it is going to be a game changing for mobile automation.
Super useful for mobile devs, especially in the age of AI. Love this product.β₯οΈ
Report
What is the difference between Mobilewright and Maestro? I am using Maestro for iOS and Android testing, though Maestro doesn't handle real iOS device well.
@mate_ajdukovicΒ Good question β and you're hitting on a real gap with Maestro's iOS real device support.
A few key differences:
TypeScript vs YAML. Rather than declarative YAML flows, Mobilewright gives you a full TypeScript API β screen.getByRole('button').tap(). That means conditionals, loops, data-driven tests, type safety, and full IDE support out of the box. If you've used Playwright for web, you already know the patterns.
Real device support. This is where it sounds like you're feeling the pain. Mobilewright runs on real iOS devices, real Android devices, simulators, and emulators β same API across all of them. Point your tests at a cloud device on Mobile Use and it's a one-line config change.
Auto-waiting architecture. Every action polls the accessibility tree until the element is visible, enabled, and stable β then acts. No manual sleeps or retry wrappers. This is what makes tests deterministic rather than flaky.
Ecosystem. Mobilewright plugs into Mobile Use (real cloud devices on demand) and Mobile MCP (AI agent access). So you can write a test locally, run it on a real iPhone in the cloud, and have your AI agent trigger it β same framework throughout.
If Maestro's iOS real device handling is giving you trouble, I'd genuinely suggest giving Mobilewright a spin β npx mobilewright init gets you a config and example test in seconds, and npx mobilewright doctor will tell you if your environment is ready.
Replies
Hi PH π
I'm Leor, co-founder of Mobile Next. We build tooling for the agentic era of mobile development.
Mobile testing has been painful for a long time. The frameworks were built for a world where humans write tests by hand, on one platform at a time. None of them were designed for AI agents writing code, and most don't work cleanly across iOS and Android.
Mobilewright is our take. A Playwright-based automation framework for iOS and Android β chainable locators, auto-waiting on every action, and tests that read like English. Zero-config CLI, free and open source.
If you've been wrestling with mobile testing, what's been hardest? I am in the comments.
RiteKit Company Logo API
@leor_sternΒ The cross-platform angle with Playwright's syntax is smartβmost teams are tired of maintaining separate test suites for iOS and Android. Curious how you're handling the platform-specific quirks under the hood, especially around native gesture recognition and timing issues that usually trip up automation frameworks.
@osakasaulΒ Thanks Saul β that's exactly the pain point we built against. Two things under the hood:
Auto-waiting eliminates the timing problem. Every action (tap(), fill(), assertions) polls the device for the element before acting. No sleeps, no arbitrary timeouts. This is architecturally different from Appium, where the HTTP round-trip model forces you into manual waits that cause most of the flakiness people associate with mobile automation.
One engine, platform-aware mapping. Under the hood, Mobilewright talks to mobilecli β our single Go binary that replaces simctl, adb, etc. When you write screen.getByRole('button'), it maps to Button on iOS and Button/ImageButton/ReactViewGroup (with clickable=true) on Android. Same for gestures β swipe('up') translates to the right coordinate math per platform. You write one test, the framework handles the translation.
The result is you get deterministic execution without platform-specific test code. Happy to go deeper on any of this, or show you a demo.
@leor_sternΒ thanks for this, a great tool that im using as we speek :-)
This is directly related to what Iβm working on and it works.
Recast
So great for getting things over the line!
It is very promising, I did wright few script with mobilewright, simple configuration, easy setup and better execution. my final thought is, for sure it is going to be a game changing for mobile automation.
Workplan
What is the difference between Mobilewright and Maestro? I am using Maestro for iOS and Android testing, though Maestro doesn't handle real iOS device well.
NoteThisDown
@mate_ajdukovicΒ what device are you using Maestro on?
@mate_ajdukovicΒ Good question β and you're hitting on a real gap with Maestro's iOS real device support.
A few key differences:
TypeScript vs YAML. Rather than declarative YAML flows, Mobilewright gives you a full TypeScript API β screen.getByRole('button').tap(). That means conditionals, loops, data-driven tests, type safety, and full IDE support out of the box. If you've used Playwright for web, you already know the patterns.
Real device support. This is where it sounds like you're feeling the pain. Mobilewright runs on real iOS devices, real Android devices, simulators, and emulators β same API across all of them. Point your tests at a cloud device on Mobile Use and it's a one-line config change.
Auto-waiting architecture. Every action polls the accessibility tree until the element is visible, enabled, and stable β then acts. No manual sleeps or retry wrappers. This is what makes tests deterministic rather than flaky.
Ecosystem. Mobilewright plugs into Mobile Use (real cloud devices on demand) and Mobile MCP (AI agent access). So you can write a test locally, run it on a real iPhone in the cloud, and have your AI agent trigger it β same framework throughout.
If Maestro's iOS real device handling is giving you trouble, I'd genuinely suggest giving Mobilewright a spin β npx mobilewright init gets you a config and example test in seconds, and npx mobilewright doctor will tell you if your environment is ready.