serve-sim is a tool that promises to make an Apple simulator accessible from a browser, a bit like npx serve for iOS Simulator. My short verdict: the idea is excellent for mobile teams and test agents, but you have to accept one hard constraint, the real product requires macOS, Xcode and Apple Silicon.
What is serve-sim?
serve-sim is a local server for Apple Simulators. It captures the screen of an iOS, iPadOS or watchOS simulator, exposes an MJPEG or H.264 video stream, then adds a React web interface to control the session.
The value proposition is straightforward: instead of watching the simulator only on the Mac running it, you turn it into a web target. A developer, an AI tool, an automated browser or a remote machine can then interact with the app under test.
The README highlights: touch gestures, keyboard input, hardware buttons, rotation, logs, recent actions, media drag and drop, synthetic camera injection and skill agent support for Claude Code, Cursor, Codex CLI or Gemini CLI.
| Tested point | Observed result |
|---|---|
| Repository | EvanBacon/serve-sim |
| Installed npm package | serve-sim 0.1.44 |
| Required runtime | Node 20+ |
| Required system | macOS with Xcode CLI, Apple Silicon per the README |
| Direct npm dependencies | inspect-webkit, sonner, ws |
| Web interface | Preview HTML served by the middleware |
| Full simulator test | Blocked on Linux, no xcrun simctl |
Installing serve-sim: what I actually ran
I cloned the repo into /tmp, read the README, the scripts and the TypeScript sources. The project is a monorepo with a main package at packages/serve-sim. The dev build uses Bun, but the published package targets Node for everyday use.
To test a standard user installation, I used npm in a temporary directory:
npm init -y
npm install serve-sim@latest
node -e "const p=require('./node_modules/serve-sim/package.json'); console.log(p.version)"
Result: installation succeeded, 8 packages added, 0 npm vulnerabilities reported, installed version 0.1.44.
I also exported the OpenAI and OpenRouter variables mentioned before the tests. serve-sim did not ask for a LLM or an API key in this flow, which makes sense: it is a simulation and control tool, not an autonomous agent.
serve-sim in practice: commands, UI and real output
First positive point: the CLI help is clear. It lists server mode, headless mode, gestures, tap, buttons, text input, rotation, permissions, UI options and camera.
Since my runtime environment is Linux, npx serve-sim first returned a Permission denied, likely related to execution from /tmp inside this container. I worked around that by running the published Node binary directly:
node node_modules/serve-sim/dist/serve-sim.js --help
node node_modules/serve-sim/dist/serve-sim.js --list
node node_modules/serve-sim/dist/serve-sim.js --no-preview
The help command produces the full expected output. The list command returns a minimal JSON:
{"running":false}
That is consistent: no simulator helper is active.
The most important test was the actual launch. There, serve-sim failed cleanly:
/bin/sh: 1: xcrun: not found
/bin/sh: 1: xcrun: not found
No device specified and no available iOS simulator found.
This is not a mysterious bug, it is the product boundary. serve-sim relies on xcrun simctl, and therefore on Xcode. Without a Mac, it cannot create a simulator stream. It does not simulate an iPhone inside Node, it serves a real Apple Simulator.
I still mounted the serve-sim/middleware into a small Node HTTP server to see what the interface produces on the web side. The / endpoint serves a Simulator Preview page of around 422 KB, and /api returns null when no session is available. This is useful for confirming that the preview is bundled inside the npm package, but it is not a replacement for testing on a Mac.
What I like about serve-sim
The concept is very solid. For a mobile team, sharing a simulator through a browser can cut a lot of friction: remote QA, quick demos, internal app reviews, agent-driven testing.
I also appreciate the framework-agnostic stance. The README is explicit that the tool is not tied to Expo or React Native. It talks to Apple Simulator, not to any specific app framework.
Another strong point: the CLI surface covers the actions that actually matter for automated testing. Typing text, sending the Home button, rotating the device, injecting a camera, checking events. These are concrete primitives. For an agent, that kind of small focused command usually beats a large overly abstract API.
On the DevOps security side, I appreciate that the server binds to 127.0.0.1 by default. The code explicitly comments that network exposure must be intentional, because the middleware includes shell execution routes. That is exactly the kind of detail I want to see before recommending a tool to a team.
The limits of serve-sim: what you need to know before adopting it
Limit number one is non-negotiable: you need a compatible Mac, with Xcode and an available simulator. In my Linux test, the product stops before producing any video stream because xcrun is missing.
Second limit: this is not a click-and-go SaaS product. For serious remote use, you need to operate the host Mac, manage the tunnel, secure access, kill helpers, monitor ports and avoid exposing the shell route to the wrong network.
Third limit: the package is still young. The installed version was 0.1.44. That is not necessarily a problem (Evan Bacon knows the Expo ecosystem very well), but I would treat it as a tool to try in a dev environment before putting it in a critical pipeline.
Finally, my test could not validate the most important promise: real 60 FPS streaming from a simulator. I can confirm the npm installation, the CLI, the error behavior, the middleware and the web preview. I cannot claim to have controlled Safari or an iOS app from this Linux container.
Does serve-sim actually work?
Yes, within the scope I was able to verify: the package installs, the CLI responds, the preview web server exists, the API reflects the missing session, and the tool cleanly detects the absence of a simulator.
But the real technical verdict depends on a test on Apple Silicon Mac. Only there can you judge latency, video smoothness, gesture reliability, camera injection and robustness over a long session.
For me, the signal is positive: the architecture fits the actual problem, the README is precise, the commands are usage-oriented, and the observed errors are explainable. This is not an empty shell. It is a specialized tool that requires the right environment.
Should you adopt serve-sim?
My verdict: try it, do not adopt it blindly.
If you develop iOS apps on a Mac and want to give browser access to a simulator, serve-sim clearly deserves a test. It could become very practical for coding agents, exploratory testing, distributed QA or internal demos.
If you are on Linux, Windows, standard CI or infrastructure without a Mac, move on for now. serve-sim does not replace macOS and Xcode. It makes them accessible in a different way.
My security and DevOps freelance recommendation: run it locally first, keep the bind on 127.0.0.1, test with a non-sensitive app, and only then look at tunneling, networking and agent integration.
FAQ
Does serve-sim work on Linux?
Not for real simulator streaming. My Linux test confirms that the tool looks for xcrun simctl, so Xcode and macOS are required.
Is serve-sim useful without Expo?
Yes in theory. The README states that the tool is framework-agnostic and talks to Apple Simulator, not just to Expo or React Native.
Is serve-sim safe to expose on a network?
Not without precautions. The server defaults to 127.0.0.1, and the code mentions a shell execution route, so LAN or tunnel exposure must be protected and intentional.