Quick answer
A local simulator is the iOS Simulator or Android Emulator on your own computer. A cloud simulator runs the same runtime on a server, and you reach it through a browser or an API. Use a local simulator when you are in a tight edit and debug loop. Use a cloud simulator when an agent, a CI job, a reviewer, or someone without a Mac needs to run the build.
You have four iOS Simulators open because you are testing a layout change across four screen sizes. Your agent has a fifth one open in the background, verifying a fix it just wrote. Your laptop fans have been at full speed for twenty minutes. On the team call, the designer asks to see the change and you start screen sharing, because she is on a Windows machine and cannot run the simulator herself.
None of this is broken, exactly. It is just the local simulator being asked to do jobs it was never designed for: be a shared review surface, be a fleet, be available to someone who does not have a Mac, be awake at 3 AM for an agent.
This post is about which jobs belong on the simulator on your machine and which belong on one running somewhere else. By the end you will have a rule of thumb for splitting them, and the questions to ask before you move any workload to the cloud.
Definitions, quickly
A local simulator is the iOS Simulator or Android Emulator running on your own computer, booted from Xcode, Android Studio, or a command line tool. It uses your CPU and memory. You interact with it through a window on your desktop.
A cloud simulator is the same iOS or Android runtime running on a server. You reach it over the network, either through a browser tab that streams the screen or through an API that lets a script or an agent drive it without a screen at all. Sessions are usually metered by time.
A self-hosted simulator fleet is the in-between: your company rents or buys Macs, runs simulators on them, and builds the scheduling and streaming layer itself. It behaves like a cloud simulator to the people using it and like a local simulator to whoever maintains it.
The comparison
| Local simulator | Cloud simulator | |
|---|---|---|
| Cost to start | Free with Xcode or Android Studio | Metered per minute or per slot |
| Time to first boot | Seconds if a runtime is installed, minutes if not | Seconds to a minute depending on cold or warm start |
| Latency when interacting | None you can perceive | Network round trip; varies by vendor and distance |
| Frame rate | Native | Streamed; often below native, sometimes well below |
| Runs on Windows or Linux | Android yes, iOS no | Yes, through a browser |
| Parallel sessions | Limited by your RAM and CPU | Limited by your plan |
| Available to an agent at 3 AM | Only if your laptop is open | Yes |
| Shareable with a reviewer | Screen share or a recording you export | A link |
| Debugger attach | Direct: Xcode, LLDB, React DevTools, Chrome DevTools | Sometimes, over a tunnel; often awkward |
| Hot reload during development | Yes | Possible, with a dev server tunneled in |
| Isolation | Your machine, your account | Depends on vendor: shared host or one VM per session |
| Camera, location, network shaping | Yes, with desktop tooling | Varies by vendor |
| Evidence artifacts | Whatever you screenshot manually | Screenshots, recordings, logs, and action timelines produced automatically |
Read the table with one question in mind: who is operating this simulator, and where are they?
When the local simulator wins
The local simulator is the right tool when the operator is you and the work is a tight edit-and-look loop.
Building a new screen is the clearest case. You edit, the app reloads, you look, you edit again. Fifty times an hour. Any latency in that loop compounds. A cloud simulator with a 200 millisecond round trip turns a two-second loop into a noticeably slower one, and streaming compression makes it hard to judge a one-pixel misalignment.
Debugging is the second case. When you need a breakpoint in native code, a memory graph, or a React profiler attached to a live session, the local simulator is where those tools live. Xcode attaches to the Simulator process directly. Chrome DevTools attaches to Metro directly. Doing either through a cloud service means tunneling a debugger over the network, which some vendors support and none make pleasant.
The third case is anything that touches hardware simulation you already have tooling for. Desktop utilities like RocketSim and Radon give you location spoofing, network conditions, camera injection, and design overlays in the local simulator today. Cloud vendors are adding these features but the desktop is ahead.
And the fourth is cost when your usage is high and steady. If you personally run a simulator eight hours a day, a metered cloud session for that work is a bill with no upside. The Mac is already paid for.
When the cloud simulator wins
The cloud simulator wins when the operator is not you, or not a person at all, or not in the same place as the machine.
Coding agents are the case that is driving most of the growth in this category. An agent that just wrote a fix needs to install the build and run it. It does not need 60 frames per second. It needs a session it can start from a command, a way to read the screen (an accessibility snapshot, not pixels), and a way to produce a screenshot or recording as proof. It also needs to do this at any hour, in parallel with other agents, without competing with a human for a laptop's memory. Tools like agent-device are built for this loop and work the same way against a local device or a remote one, so the agent's workflow does not change when the simulator moves.
Continuous integration is the older version of the same case. Your test suite needs devices for eleven minutes after each merge and zero minutes the rest of the time. Buying Macs for a peak that lasts eleven minutes is the reason device clouds exist.
Sharing is the third. A reviewer, a designer, a product manager, or a customer wants to see the build. Today the options are: install it on their phone (which means device registration on iOS, a build for their device, and a beta distribution channel), record a video (which does not let them tap), or screen share (which requires you to be present). A cloud session that produces a link solves all three, and it works for the person on Windows.
Fourth is anyone without a Mac. iOS Simulator only runs on macOS. A cloud simulator streamed to a browser is the only way a Linux or Windows developer runs an iOS build without borrowing hardware.
Fifth is isolation. An agent working against an unreleased build with production credentials in it should not share a machine with anything else. A cloud simulator that runs one virtual machine per session and destroys it afterward gives you that without maintaining a clean-room Mac yourself. Ask the vendor how they do this; "one VM per session" and "separate user accounts on a shared host" are different answers with different security properties.
The rule of thumb
Build locally. Verify in the cloud.
The local simulator is for the part of the work where a human is in a tight loop with the code. The cloud simulator is for the part where the code is done and something needs to run it and show the result to someone else: an agent proving its fix, a CI job running the suite, a reviewer opening a link, a designer checking spacing.
Most teams that adopt cloud simulators do not stop using local ones. They stop using local ones for the jobs local ones were bad at. Engineers keep their laptop simulators and stop getting asked to screen share. Agents get devices of their own and stop asking for someone's Mac.
Should you build your own instead
Some teams look at cloud simulator pricing and reach for a spreadsheet. The Mac is a known cost. Hosting is a known cost. Why pay a vendor?
Two things decide this, and neither is the hardware price.
The first is utilization. A fleet is sized for peak concurrency and paid for around the clock. If your peak is sixteen parallel devices for a daily regression suite, you need eight Macs, and they sit idle most of the day. A single team in a single time zone cannot keep a Mac fleet busy at night or on weekends. A vendor pooling many customers across time zones, plus agent traffic that does not sleep, can. Below a fairly high utilization threshold, buying the fleet means buying capacity for a peak you touch briefly.
The second is the software above the Mac. Booting a simulator on a machine is easy. Building the scheduler that picks which machine a session lands on, the warm pool that makes sessions start in seconds, the streaming layer that gets the screen into a browser, the snapshot and restore that makes a session reproducible, and the API that an agent can call: that is the product. It is quarters of engineering and then it is yours to maintain forever, including every time Xcode ships a new version.
If you already have the fleet and the people, your marginal cost is near zero and no vendor beats that on price. If you do not, the honest comparison is not "Mac rental vs. per-minute rate." It is "building and running the orchestration layer vs. renting it." A hybrid is a legitimate answer: self-host your steady regression load, meter the bursty agent and review sessions.
Questions to ask before you move a workload
Before you move anything from local to cloud, make sure you can answer these questions:
Who operates this session, a person or an agent? If a person, latency and frame rate matter. If an agent, they mostly do not, and headless API access matters instead.
How does the build get there? If your CI already produces it, count the steps between "build done" and "app open." Every manual step is a place the agent has to stop.
What comes out? You are moving to the cloud partly for evidence. Confirm a recording and an action log come out of every session and can be attached to the PR.
What is the isolation model, and does access follow your existing project permissions or a new login?
What does a runaway session cost? Agents loop. Confirm spend caps, idle suspend, and a kill switch exist before the first agent gets a key.
Where to start
Pick the workload that hurts most today. For most teams that is one of two things: agents that claim to have verified something with nothing to show for it, or reviewers who cannot see a build without installing it. Move that one workload to a cloud simulator, keep everything else local, and measure two things: the time from "PR opened" to "someone watched it run," and how often the recording gets opened.
Expo Simulators is built for the verify-in-the-cloud half of this split. It runs any app built for the iOS Simulator or the Android Emulator, including native, Flutter, React Native, and Unity apps. A session starts from one command and installs a build, and the screenshots and recordings it produces are what the agent hands to a reviewer. Teams that build with Expo also get installs by EAS Build ID and React Native tools such as Fast Refresh and component inspection. Expo Simulators is in early access, so check the current limitations before you plan around it. Try Expo Simulators.
Next in this series: once the agent has a device, who should be checking its work, the agent or a person?
Verified on 9 October 2026.