News
Expo Simulators gives coding agents cloud iOS and Android devices to verify their work
Expo Simulators gives coding agents cloud iOS and Android runtimes so they can install builds, drive the app, and return recordings as proof.
Expo did not ship another coding model. On November 12, 2026, it shipped a cloud device runtime so the agents teams already use can see a running mobile app.
Expo Simulators is generally available on all paid plans. Coding agents, CI jobs, and teammates can start a cloud iOS Simulator or Android Emulator with no Mac, no nested virtualization, and no need to spend laptop RAM on the device. The launch announcement states the boundary directly: Expo Simulators adds no AI model of its own. Claude Code, Codex, Cursor, or any agent that can run CLI commands drives the remote session with the same agent-device, Argent, or Appium commands it would use on a local simulator.
The product is a check, not a generator. Expo’s framing is that verification has become the bottleneck: an agent that cannot run the app cannot see what the app does.
Why a laptop simulator does not travel with the agent
Local simulators already let an agent check its own work on one machine. They do not match how that work is moving. Expo’s launch post points to background agents in cloud sandboxes, QA agents in CI, and pipelines that start from a bug report. Those jobs are often not on a Mac, and the iOS Simulator only runs on a Mac. A local session also leaves no device history. If an agent did something strange, the chat log does not show what was on the simulator at the time.
Parallel runs are the other limit. The blog’s example is specific: seven agents at once means the laptop has to run seven simulators or emulators, and agents that share a machine can collide — one reinstalls the app in the middle of another’s test. The press release adds a memory figure for that local case: Android emulators can use 4+ GB of RAM each. Linux machines, Windows via WSL, and cloud sandboxes can reach an iOS Simulator on Expo without a Mac in the loop.
What an isolated session returns
Each session runs on its own virtual machine, so parallel agents do not share a device. The agent installs a build, drives the app, and brings back proof. Expo says a session keeps a full screen recording, screenshots, and logs, and also collects network traffic plus CPU and memory usage. The agent can read logs and screenshots while the session is running and attach them to a pull request. A reviewer can watch the recording instead of pulling the branch, building, and opening a simulator.
A person can stream the same session in a browser, on desktop or mobile, and take over the taps if something looks wrong. A web-preview-only session exposes that live view without the agent controller. Expo says teammates can open a running build from a link, with nothing to install and no TestFlight build.
Sessions end on their own. None runs longer than two hours, and a team can set a shorter maximum duration and an idle timeout, so a CI job that exits early does not leave a simulator billing indefinitely. When a session stops, the simulator and its control endpoints go away. The recording, screenshots, and logs stay on the session page. Expo says each session uses an isolated VM on the same infrastructure layer as EAS Build, Submit, and Workflows.
The docs describe four stages: start a session from the CLI, the REST API, or an authenticated create-session link; install an app; drive it; stop it. Install sources include an EAS build, a build fingerprint, an application archive URL, Expo Go, or a local build sent through the controller after the session starts. With no application source, the session starts on a blank device. The launch post also describes pointing Expo Go or a development build at a Metro server so Fast Refresh can show saved changes without a rebuild.
This does not replace a local device you already have. Expo’s docs say to keep Xcode or Android Studio workflows when the required runtime is already on the machine, and to use local tooling for physical devices. Simulators is for remote or shareable access — including a background agent whose sandbox cannot launch an iOS Simulator.
Which apps, and what Expo is charging
The service is not limited to apps built with Expo’s framework. The launch post says any app built for the iOS Simulator or Android Emulator can run in a session, and names Expo, Exact, SwiftUI, Jetpack Compose, Flutter, and Unity. The docs also point the same service at React Native and native apps. Maestro flows and Appium suites can run on a session from CI, Expo says.
Usage is priced at $0.10 per minute for iOS and for Android. That rate is Expo’s stated price, in both the blog and the November 12 press release, not an outside measurement. Starter, Production, and Enterprise include 60 minutes a month. Only the blog adds a horizon the press release does not: those included minutes run until 2027. Expo points remaining plan detail to its pricing page.
James Ide, co-founder and CTO, put the review handoff this way in the announcement: “The agent was the fast part. Expo Simulators gives every agent a simulator, so a fix arrives for review already tested on several simulators, and the only decision left is whether it’s the right code. Watch it run, then merge.” He also noted that a mobile release still goes through the app store, and that users might be running 10 or 20 versions of an app at once.
Expo said a later product, Agent Sessions, would let enterprises trigger agents from sources such as customer feedback, with protections against prompt injection. Details were expected by the end of November. That layer is not part of this launch. Design partners had used Simulators for a few months before general availability.
Before you point a cloud agent at a device, read the Expo Simulators introduction for what a remote session can install and drive, then the November 12 launch post for the two-hour cap and the $0.10 rate. If the machine already has a local simulator, Expo’s docs say to keep that workflow.