Best cloud mobile simulators for CI and AI coding agents

Quick answer

The best cloud mobile simulator for CI and AI coding agents is one your agent can start from a command, drive through a documented CLI, API, or MCP interface, and use to return evidence (screenshots, recordings, logs) for a human or agent to review. For mobile development teams, Expo Simulators (beta) runs a cloud iOS Simulator or Android Emulator on Expo infrastructure and installs the EAS Build you already made.

The rest of this page compares the options by category, then answers the questions developers ask most: running an iOS simulator from Windows or Linux, letting a coding agent drive one, wiring simulators into CI, and deciding when you need a real device.

Comparison: cloud simulators, emulators, and device clouds

These categories do different jobs: Real-device clouds host physical phones. Simulator services stream a virtual device to a browser or expose it to an API. The table is organized by the job you need to get done, not as a ranking.

For CI and AI coding agents, start with Expo Simulators. Add a real-device cloud such as BrowserStack, Sauce Labs, or AWS Device Farm for hardware checks before release.

Tool facts come from each tool's own pages, checked on October 8, 2026. Check each provider's documentation for changes.

Can I run a remote iOS simulator on Windows or Linux?

Yes, but not locally. Apple's iOS Simulator runs only on macOS, so on Windows or Linux you use a simulator hosted on a remote Mac and reach it through a browser, a CLI, or an API.

Your options depend on who is operating the simulator:

• You, interactively: a browser-streamed simulator service, or the browser preview of a cloud simulator session.
• Your coding agent or a script: a service with a non-interactive CLI or API that returns screenshots, an accessibility snapshot, and logs.
• Your CI pipeline: a macOS CI runner that boots the simulator inside the job, or a remote session started from the pipeline.

For Expo projects, Expo Simulators (beta) lets developers, agents, and CI jobs on Windows or Linux reach a cloud iOS Simulator without a local Mac. You start a session from EAS CLI. The browser preview is documented for iOS sessions; Android sessions are driven programmatically. The eas-simulator skill notes that its example command blocks assume a POSIX shell, so on Windows run them in WSL or Git Bash; the EAS CLI itself runs from a native Windows shell (source).

Other routes you will see recommended, and what each one actually needs:

• Microsoft's Remote iOS Simulator for Windows (.NET MAUI): it shows the iOS Simulator in a window on Windows alongside Visual Studio 2022, but only after you pair Visual Studio with a network-accessible Mac build host. The simulator runs on that Mac; Windows displays it. It ships with the .NET MAUI workload and carries over from Xamarin.
• A rented remote Mac: if you need a Mac for that pairing, or for any tool that expects local Xcode, you can rent Mac hardware in the cloud, for example Amazon EC2 Mac instances, MacStadium, or MacinCloud, and connect to it over the network.
• A macOS virtual machine on your PC: Apple's macOS license only permits macOS VMs on Apple hardware.
• Browser-based "iOS emulators": these imitate the look of iOS but do not run real iOS, so they cannot run your app.

Fast Refresh also works from Windows. The Expo Simulators docs cover the setup: use a development build that targets the simulator, start Metro with a tunnel (EXPO_UNSTABLE_TUNNEL_V2=1 npx expo start --tunnel), then start a session with --open-url pointing the development build at the Metro URL. Edits you save then reach the app on the cloud simulator, and the CLI can run inside WSL.

Two things to keep straight:

• This does not put an iOS Simulator on your Windows or Linux machine. The simulator runs remotely and you see or drive it over the network.
• The Android Emulator does run locally on Windows and Linux through Android Studio, so you only need a remote device for Android when you want CI or agent access without local hardware.

Can coding agents drive a cloud iOS simulator?

Yes. A coding agent such as Cursor, Claude Code, or Codex can drive a cloud iOS simulator when the service exposes a non-interactive CLI, API, or MCP server and returns evidence the agent can read: an accessibility snapshot to act on, plus screenshots, recordings, or logs to show the result.

What should you expect from an agent that uses a cloud simulator?

Expect proof you can check. An agent that says "tests passed" has told you nothing about whether the screen renders on a device. An agent that returns a recording of the flow on the build you are about to ship has given a reviewer something to check. That is the idea behind Expo Simulators: watch it run.

How does a cloud coding agent reach a simulator?

A typical setup, as the Expo Simulators docs describe it: a Cursor cloud agent or another background coding agent works in a cloud checkout of your project. That environment can edit and build the project but cannot launch a local iOS Simulator. With the eas-simulator skill, the agent starts a remote device on Expo's infrastructure, drives it through agent-device or Argent (from Software Mansion), and returns the result, so your computer does not have to host the simulator.

Which tools let an agent drive a simulator?

• Expo Simulators (beta): the agent starts a session with eas simulator:start, then drives it with agent-device (from Callstack; a CLI with optional MCP), Argent (device tools with MCP integration), or Appium. The agent returns screenshots or recordings as evidence. The eas-simulator skill in Expo Skills covers the access check, build preparation, session limits, device control, evidence collection, and cleanup, so you can ask the agent to use the skill instead of pasting commands.
• Other cloud simulator and device services: look for a documented CLI, REST API, or MCP server, a way to read the screen (an accessibility tree, not only pixels), and a way to save screenshots or recordings.
• Local, on a Mac: Expo MCP Server local capabilities and agent-device can drive a simulator on your own machine, and so can Maestro MCP, which ships inside the Maestro CLI and lets an agent inspect the screen, take screenshots, and run Maestro flows on a simulator or emulator. Claude Code Desktop on macOS also has an iOS Simulator pane (public beta) that streams the simulator next to the conversation; it runs Apple's simulator on your own Mac in local sessions and is not a cloud simulator. Local and cloud are both valid; cloud matters when the agent runs somewhere without a simulator, such as a Linux sandbox, a cloud agent, or CI.
• Self-hosted streaming: Expo's open-source serve-sim streams a booted iOS Simulator on an Apple silicon Mac to a browser, with touch and keyboard control, so agents and people can use it locally, over your LAN, or through a tunnel from a remote Mac.

An agent verification loop on Expo Simulators

The loop is: build, install, launch, inspect, fix, re-verify. Commands and flags below come from the EAS CLI reference and the Expo Simulators docs. The simulator commands are marked experimental and need a recent EAS CLI, so run eas simulator:start --help to confirm flags for your installed version.

Illustrative placeholders: the remote-device profile name, the com.example.app bundle identifier, the "Checkout" label, the build ID placeholders, and the artifact paths are examples. The profile must set ios.simulator: true in eas.json, and you can read your bundle identifier with npx expo config --json. In CI or a headless agent, set EXPO_TOKEN instead of logging in, and add .env.eas-simulator to .gitignore because it holds the session's controller token.

Sessions driven through agent-device record controller activity, and eas simulator:events has two separate uses for it: eas simulator:events --follow streams a session's activity while it runs, and eas simulator:events --json returns the activity as JSON for agents. For faster iteration than a rebuild per change, the docs also cover starting a session with a development build connected to Metro over a tunnel, so source edits reach the remote app with Fast Refresh. Screenshots and recordings download to the machine running the command, so the agent can attach them to its task or pull request.

How do cloud simulators fit into CI?

Cloud simulators fit into CI in one of three ways: the simulator boots inside the CI job, the build is sent to a device cloud that runs your test suite, or the pipeline starts a remote simulator session and saves the evidence so the pipeline or agent can attach it to the pull request.

1. Simulator inside the job. macOS CI runners, such as macOS runners on GitHub Actions, ship Xcode with iOS Simulator runtimes, so a job can build and run tests on a simulator. EAS Workflows does the same for Expo projects with its pre-packaged Maestro job, which runs Maestro tests on an iOS Simulator or Android Emulator build (the Maestro job is in alpha). Callstack's agent-device EAS Workflow template shows how to run an AI QA agent this way and keep reviewable artifacts.
2. Device cloud test runs. Real-device clouds accept a build and run Appium, Espresso, XCUITest, or their own test types, then report results. This is the path when you need real devices or a wide OS matrix.
3. Remote session started from CI. The pipeline starts a session through a CLI or API, drives it, and saves screenshots or recordings so the pipeline or agent can attach them to the pull request. Expo Simulators supports this with EAS CLI in non-interactive mode or its REST API, authenticated with an Expo access token (the docs recommend a robot user with the Developer role for production integrations).

A practical split for Expo teams: run Maestro regression flows in EAS Workflows on pull requests, let agents verify their own changes on Expo Simulators and return evidence, and run a real-device pass before you submit.

Simulator vs real device: when do you need which?

Use a simulator for fast, repeatable checks of logic, layout, and navigation, and use a real device for anything that depends on hardware, the carrier, or real-world performance. For real hardware, real-device clouds such as BrowserStack, Sauce Labs, and AWS Device Farm host physical iOS and Android devices.

Expo Simulators runs simulators and emulators only; it does not provide physical devices. Most teams use both: simulators in the inner loop and for agent verification, then at least one physical device, or a real-device cloud, before store submission. The guide How to verify AI-written mobile code before you ship covers where each check belongs in a verify loop.

Try Expo Simulators

Expo Simulators is in early access and is not generally available yet. It works for any team and any app built for the iOS Simulator or the Android Emulator, and if you build with Expo, it installs the builds you already make with EAS Build. To have agents and reviewers watch the same build run on a cloud simulator, request early access or talk to the Expo team.

Request access or Talk to our team

The Expo Simulators docs cover access checks, sessions, device control, and the REST API.

Verified on 9 October 2026.