Imagine this scenario. You ship a build that passed every test on your CI matrix — a dozen Android emulators, a handful of iOS simulators, all green. Then a customer on a Samsung Galaxy S24 reports that the sign-in button doesn't work. Not a crash. Not a timeout. The button just... does nothing. Tapped a thousand times.
The bug is a race condition between a biometric prompt and a JavaScript bridge that only manifests on physical hardware, on one specific Android version, with a specific authentication path. The emulator never triggered it because emulators don't have biometrics in the same way. The simulator never triggered it because iOS doesn't have that bridge at all.
This is not a rare scenario. It's the story of mobile development.
The emulator tells you what you want to hear
Emulators and simulators are approximations. Useful ones — I'm not here to argue they're worthless. They're fast, they're free, and they catch 80% of bugs. But the 20% they miss is not random. It's concentrated in exactly the places your users live: touch latency on older devices, GPU rendering on specific chipsets, biometric flows, camera permissions, push notifications, deep links, network transitions, background behaviors. The failures emulators silently pass are the ones your customers will eventually find for you.
For the last decade, the industry's answer to this has been device farms: BrowserStack, Sauce Labs, AWS Device Farm. We've used all of them. They solve the "real hardware" problem, but they were built for a different era — the era when QA was a human being in a browser window, manually clicking through a release candidate on a Pixel 5. The interface is a web console. The workflow is upload-your-APK-and-wait. The API, where it exists at all, is bolted on.
That worked when the person driving the test was a human. It doesn't work when the person driving the test is an AI agent.
What changed
Over the last eighteen months, something shifted. Gil and I watched developers start letting Claude Code, Codex, and Cursor write entire features end-to-end. The agents are good — really good — at generating mobile app code. But when it came time to actually run that code on a real device, the whole pipeline fell apart. The agent had no way to see what it had built. No way to install the APK. No way to tap a button. No way to know if what it had just written actually worked.
We built Mobile MCP to close part of that gap — giving agents eyes and hands on a device. It blew up faster than we expected. 3.7K+ stars on GitHub. But Mobile MCP assumes you already have a device connected to your machine. That's fine for developers with an iPhone on their desk. It's not fine for agents running in CI, or for QA teams that need to test across 20 device models in parallel, or for a developer who wants to spin up a Pixel 9 for thirty seconds to verify one thing and then throw it away.
What we kept hearing was: I don't want to manage devices. I just want to point my script or my agent at a real phone and have it work.
So we built Mobile Use.
What Mobile Use is
Mobile Use is a cloud of real iOS and Android devices, accessible as an API. You sign up, you get an endpoint, you connect to it — from a script, from a CI pipeline, or from an AI agent via MCP — and you're on real hardware in seconds. Not an emulator. Not a simulator. An actual iOS or Android device of your choice — iPhone, iPad, Pixel, Samsung Galaxy, and more — streaming video and accepting commands.
We built it to work the way developers and agents actually want to work:
- One config change to migrate. If you already use Mobilewright — our open-source Playwright-style automation framework — you point it at our endpoint and you're done. Your existing scripts run on real hardware without modification.
- Native MCP support. Connect Claude Code, Codex, Cursor, or any MCP-compatible agent with a single command. The agent gets a device. It can see the screen, list elements, tap, type, install apps, check results.
- Programmatic from day one. There's no browser recording studio. No waiting minutes on end. You allocate a device, you do your work, you release it. The whole lifecycle is an API call away.
- Pre-allocated sessions. When a device sits idle too long, we cycle it so allocation for a new session is instant. No ten-minute cold-start wait for a Mac host to spin up.
Under the hood, building this took work we didn't initially appreciate. Getting iOS and Android to behave predictably at scale, making session allocation feel instant, streaming video to a developer's browser without ruining responsiveness — none of it is fun, all of it has to be solved. We spent the last year getting the hard parts right so you don't have to think about them.
Who this is for
Three audiences, and I'll be honest that one of them didn't exist two years ago:
Developers using AI coding agents. If you're building mobile apps with Claude Code, Cursor, or any MCP-compatible agent, your agent can now use real devices instead of asking you to plug in your phone. This is the fastest-growing part of our user base and, I suspect, the reason you're reading this.
QA engineers migrating off Appium. Mobilewright is what modern mobile automation should look like — chainable locators, auto-waiting, the Playwright-style API your team already knows from the web. Mobile Use is where it runs. If you've spent any time fighting XPath spaghetti and flaky waits in a legacy Appium suite, this will feel like oxygen.
Automation teams at scale. Screenshot generation across device matrices, regression suites, performance benchmarks, data collection — all of it runs better on an API than in a web console. No more "log into BrowserStack, upload APK, click through the flow." Just scripts. Concurrent sessions. Real devices.
What's free, what's not
There's a free tier: 300 minutes of device time every month, no credit card required, real devices (not a trial of emulators). Paid is pay-as-you-go at $0.15/minute. Enterprise is fixed monthly, per dedicated device, unmetered. No one has to talk to sales to start.
Where this fits in the larger picture
Mobile Use is one piece of a stack we're building for agentic mobile development:
- Mobilewright — the scripting framework
- Mobile Use — the device cloud that runs those scripts (and connects to agents)
- Mobile MCP — the local MCP server that gives agents eyes and hands on any device
Each of these works alone. Together they form a complete loop: write scripts with Mobilewright → run them on real devices through Mobile Use → hand the same devices to AI agents through Mobile MCP. This is what I mean when I say Mobile Next is building the system-of-action for agentic mobile development. The pieces reinforce each other. You don't have to use the whole stack to get value from any one of them, but if you do, they compound.
Try it
Go to mobile-use.com. Sign up. You'll have a real iPhone or Pixel in your browser within a minute, connected to Claude or your Mobilewright scripts or whatever else you want to throw at it. No credit card. No sales call.
If you hit anything weird, or if you want to tell us why this is wrong, email us at contact@mobilenexthq.com. I read everything.
Stop testing on fake devices.