---
title: "Agents with iPhones: Why the Simulator Market is Blowing Up"
date: 2026-09-15T14:02:38Z
modified: 2026-09-15T14:02:38Z
permalink: "https://redmonk.com/kholterhoff/2026/09/15/agents-with-iphones-simulator/"
type: post
status: publish
excerpt: ""
wpid: 580
categories:
  - AI
  - iOS
  - mobile
timestamp: 2026-09-15T14:02:38Z
tags:
  - AI
  - iOS
  - mobile
---

![](http://redmonk.com/kholterhoff/files/2026/09/kudzublooming-scaled.jpeg)

Back when I was a web developer and QA engineer, I regularly tested the mobile experience of the sites my team built using real device testing, namely on BrowserStack, and I “[simulated mobile devices](https://developer.chrome.com/docs/devtools/device-mode)” with Chrome’s Device Mode. So when I learned about recent moves in the iOS simulator space—a sibling technology—I had some questions about the state of native mobile app development, and, specifically, why simulators are blowing up.

Simulators and emulators themselves are not new, and they have not historically been devtools you had to buy. Google ships the Android Emulator with Android Studio. Apple has shipped one with Xcode since the first iPhone SDK in 2008. Both are free, and both run on the machine already on your desk. But, for reasons I will get into, there has been movement in the simulator space in particular.

Not only did Apple replace its simulator with Device Hub in Xcode 27 earlier this year, but the number of third party vendors in the simulator space is growing. A few important players in this market include Sauce Labs, which was founded in 2008 as a cloud testing company, and native app testing arrived via [Appium on Sauce in 2013](https://www.globenewswire.com/news-release/2013/05/14/1187076/0/en/Sauce-Labs-Opens-Up-Native-Hybrid-Mobile-App-Test-Cloud-to-All-With-Added-Android-Support.html). Appetize, founded in 2015, has servers containing [iOS simulator and Android emulator functionality](https://appetize.io/blog/posts/loookit-and-appetize-transform-customer-support-for-mobile-apps#:~:text=iOS%20simulator%20and%20Android%20emulator%20functionality). Expo, founded in 2016, has a simulator service [in early access](https://expo.dev/services/simulators#:~:text=Join%20the%20waitlist), and two Y Combinator startups, Revyl (2024) and Limrun (2025), are selling cloud simulators as agent infrastructure.

So, a commercial market has grown up around something every iOS mobile developer already gets for free. That only looks strange if you haven’t been paying attention to Apple’s grip on the platform, which is a long-running story. I got into a version of it with Alex Russell on a recent [MonkCast episode](https://redmonk.com/blog/2025/11/24/alex-russell/), where his argument is that Apple’s refusal to allow real browser engine competition on iOS keeps the web from ever becoming a serious alternative to native. More on Apple and developer experience below. What I wanted to know is why there is so much interest in simulators today.

[It’s the agents, stupid](https://en.wikipedia.org/wiki/It%27s_the_economy,_stupid). Agents have changed the volume and the customer for iOS development, and agents run in Linux sandboxes with no Xcode and no simulator. Moreover, agents don’t want one simulator for eight hours a day, they want a dozen for ninety seconds each, all afternoon, potentially while a developer works on something else. All of this means that mobile app developers are grappling with issues of parallelism and developer velocity (code is cheap) that didn’t affect them before.

## Simulators v. Emulators v. Real Device

But before I dig into specifics of the simulator market in 2026, lets define terms. A simulator recreates the software environment an app will run in; an emulator mimics the hardware as well as the software; real device testing spins up an app on a physical smartphone or tablet. Hence the industry shorthand: simulators (Revyl, Limrun, Expo EAS Simulator, Sauce Labs) are for iOS; emulators (Android Studio Emulator, Genymotion, Anbox, Archon) are for Android; and real device testing (BrowserStack, Sauce Labs, Perforce Perfecto, Firebase Test Lab, AWS Device Farm, pCloudy) are for both, and occupy the end of the delivery pipeline, after the virtual layers have caught everything they can.

The two dominant mobile platforms take an active part in maintaining the simulator/ emulator distinction. Apple ships the iOS Simulator with Xcode: your app compiles for the Mac’s own processor and runs as a macOS process as if it were an iPhone. Google ships the Android Emulator, which presents the virtual hardware of a real device—sensors, cameras, and radios included—and boots the same system images that ship on phones.

Frontend engineers, whose mobile chops are often limited to Progressive Web App (PWA) APIs, rarely have to internalize any of this emulator/simulator stuff because the browser abstracts it away. Same goes for test engineers, who can usually leave the distinction to their tooling. A React Native app’s JavaScript will happily run in a browser tab. The problem comes when testing needs to include native code. Navigation transitions, platform controls, the type rendering and gesture handling that make an app feel like an app: none of it exists until the code runs on something that speaks iOS or Android.

But here’s where they diverge. Apple’s simulator has [no camera, no microphone, and no accelerometer or gyroscope](https://developer.apple.com/library/archive/documentation/IDEs/Conceptual/iOS_Simulator_Guide/TestingontheiOSSimulator/TestingontheiOSSimulator.html#:~:text=Audio%20and%20video%20input). If you ask it for a capture device, [AVCaptureDevice returns nil](https://github.com/dautovri/SimulatorCamera#:~:text=AVCaptureDevice%20returns%20nil), an inconvenience Ruslan Dautov, a senior site reliability engineer at ZEDEDA who [ships iOS apps on the side](https://dautovri.com/), has been working to address. What it does give you is everything drawn on screen, plus flows you might assume need hardware but don’t, like walking through Apple Pay flows. An emulator reaches further precisely because it mimics the hardware, which is why Android developers can [give the virtual device a working camera](https://developer.android.com/studio/run/emulator-use-camera#:~:text=basic%20camera%20functionality), including pointing it at the webcam on their development machine. Meanwhile, iOS developers have spent a decade working around a gap that third parties now fill. RocketSim, for instance, which [Antoine van der Lee](https://www.linkedin.com/in/ajvanderlee/), founder of SwiftLee, started as a side project in 2019 and brought to the App Store in [March 2020](https://launchedfm.com/episode/88-swiftlee-antoine-van-der-lee#:~:text=I%20think%20March%202020), now streams a Mac camera into the simulator so QR scanners and document capture can be tested without deploying to a phone. And a real device is still the only place to check things like [LiDAR and biometric accuracy](https://geniusee.com/single-blog/xcode-simulators-advanced-features#:~:text=LiDAR%20scanner%2C%20TrueDepth%20camera%2C%20or%20Optic%20ID).

## The Mac tax, or why this is a market and not a feature

Android emulators run on Linux, Windows, or macOS; iOS simulators run only on macOS, on Apple hardware. The consequence of this is that developers must buy or rent Apple hardware if they want iOS testing. Mobile developers can’t ship a native iOS app without a Mac somewhere in their pipeline, but that Mac increasingly doesn’t have to be on their desk.

Historically, Apple’s software license has complicated renting. In 2020,[ woachk](https://github.com/woachk), a kernel/hypervisor engineer for Amazon EC2, wrote that the macOS EULA permits[ only two additional virtualized macOS instances per Mac](https://threedots.ovh/blog/2020/12/macos-eula-licensing-restrictions-affecting-virtualisation/#:~:text=two%20%282%29%20additional%20copies%20or%20instances), and its leasing terms are[ why AWS rents Mac instances with a 24-hour minimum](https://threedots.ovh/blog/2020/12/macos-eula-licensing-restrictions-affecting-virtualisation/#:~:text=minimal%20use%20time%20of%2024%20hours). In 2026, the current agreement hasn’t been altered, and is available in the[ macOS Tahoe SLA](https://www.apple.com/legal/sla/docs/macOSTahoe.pdf) (Section 2B(iii) and Section 3)—if you enjoy that sort of reading. So every vendor in this post is, underneath the API, racking Apple silicon and streaming sessions off of it: scarcity + licensing friction + sudden demand = a robust market for simulators.

Which means the hosted services sell you Apple’s simulator, running on Apple hardware, somewhere that isn’t your machine. Expo’s documentation describes the EAS Simulator as remote iOS Simulators and Android Emulators on Expo’s infrastructure, reachable [from the CLI, an AI agent, or a browser](https://docs.expo.dev/preview/eas-simulator/introduction/). MacStadium and AWS EC2 Mac rent the underlying hardware for teams that want the whole Mac, and Cognition recently demoed [Devin building an iOS game on a Namespace cloud Mac](https://www.youtube.com/watch?v=p20jZmHBu8E). The only meaningful escape from this arrangement is Corellium, which virtualizes iOS itself on its own ARM hardware rather than running Apple’s simulator, and which sells to security researchers rather than app teams.

It’s worth mentioning the driver layer, which actually operates the simulator once one exists. At the bottom are Apple’s own simctl and Meta’s idb, the iOS Development Bridge, which attaches [a companion process to each simulator](https://github.com/facebook/idb#:~:text=companion%20process%20attached) so it can be driven remotely. Recently, with hte rise of agentic software development, this capability has become extremely important because it allows for fanning test shards out across a large pool of simulators. Above that sits the test automation frameworks (Appium, Maestro, Detox), then the agent-specific drivers: Callstack’s agent-device, which lets a coding agent “[verify its changes in the running app](https://github.com/callstack/agent-device#:~:text=verify%20its%20changes%20in%20the%20running%20app),” and Software Mansion’s Argent, which gives agents “[direct access to the iOS Simulator and Android emulator](https://swmansion.com/blog/control-your-i-os-simulator-with-an-ai-agent-on-a-local-llm/#:~:text=direct%20access%20to%20the%20iOS%20Simulator).”

Then the MCP servers, which is where the space is most crowded and least governed. In [Blake Crosley](https://www.linkedin.com/in/blakecrosley/)’s writeup on developing iOS apps with agents, he explains that he used [XcodeBuildMCP, with its 82 tools, next to Apple’s own xcrun mcpbridge](https://blakecrosley.com/guides/ios-agent-development#:~:text=XcodeBuildMCP%20with%2082%20tools). Community projects like ios-simulator-mcp, created by [Joshua Yoes](https://www.linkedin.com/in/joshua-yoes/), Staff Software Engineer at Infinite Red. Finally, the indie utilities, RocketSim, Wix’s [applesimutils](https://github.com/wix/applesimulatorutils), and [simslim](https://github.com/MobAI-App/simslim).

## Why Agents Need Simulators

None of the things third party simulator vendors or projects offer are things the simulator on your Mac can’t do. Instead, these devtools offer improved developer and agent experience. I have divided the most significant DevX/ AX advantages vendors tout in their marketing into 5 categories:

1. **Capacity.** Simulators are resource hogs. According to the simslim project, a freshly booted simulator starts around [180 background services](https://github.com/MobAI-App/simslim#:~:text=180%20background%20services), from Spotlight indexing to photo analysis. But developers don’t need all of them all the time. The ceiling to how many services a machine can run comfortably is shared with your compiler, your browser, and the development work done by humans and their agents, which is the part the vendors are really selling against.
2. **Reachability.** Cloud coding agents, powered by models like ChatGPT and Claude, don’t live on a Mac. This is Limrun’s founding pitch: [cloud agents have Linux-based sandboxes](https://www.ycombinator.com/companies/limrun#:~:text=cloud%20agents%20have%20Linux%2Dbased%20sandboxes) with no Xcode and no emulator, so a remote simulator is what lets developers [build, validate, and share their work](https://limrun.com/#:~:text=so%20your%20cloud%20agent%20can%20build). The same wall stands in front of Linux CI runners, and in front of the Windows and Linux developers sitting on React Native teams. It is also why a browser preview isn’t a substitute: JavaScript renders there, native code does not.
3. **Shareability.** A local simulator is visible to only one person, but software development is a team effort. Hosted sessions have a URL, so a designer, PM, or support rep can open the running app without installing Xcode or owning a Mac. The pull of shareability is strong enough that developers now want it for local simulators too: [Evan Bacon](https://evanbacon.dev/blog/expo), who led AI at Expo before leaving for SpaceXAI this spring, built serve-sim to “[host your simulator for use with Agent tools like Codex, Cursor, or Claude Desktop — locally, over your LAN, or host on a remote mac and tunnel anywhere](https://github.com/EvanBacon/serve-sim#:~:text=Host%20your%20simulator%20for%20use%20with%20Agent%20tools%20like%20Codex%2C%20Cursor%2C%20or%20Claude%20Desktop%20%E2%80%94%20locally%2C%20over%20your%20LAN%2C%20or%20host%20on%20a%20remote%20mac%20and%20tunnel%20anywhere.).”
4. **Provability.** [According](https://x.com/anamhira/status/2085440679220851025) to [Anam Hira](https://www.linkedin.com/in/anam-h-5b37a2125/), co-founder and CTO of Revyl:
    > cloud agents run on linux boxes, and linux boxes can’t run iOS sims. so instead of showing you the change, the agent gives you a diff. now it can prove its own work.
    
    Anam frames the shift as agents graduating from description to demonstration. The pattern that follows is an agent building a change, running it on a cloud device, and [attaching the recording to its pull request](https://www.futureofios.com/#:~:text=running%20it%20on%20a%20cloud%20device), so a reviewer watches the fix instead of reading a diff and hoping. Expo’s EAS simulator also now offers [session recordings](https://expo.dev/services/simulators#:~:text=A-,session%20recording,-lands%20on%20the) on the PR.
5. **Repeatability.** Agent loops need a simulator in a known state, and a simulator on a laptop is the opposite: it accumulates granted permissions, keychain entries, and stale builds until a failure stops reproducing. Hosted fleets erase between runs. Revyl’s engineering write-up is useful on this subject. When it comes to [device provisioning](https://revyl.com/blog/mobile-infra-for-coding-agents/#:~:text=02-,Device%20Provisioning,-Android%20emulators%20cold), iOS simulators have to be erased between runs for hermetic isolation, then booted, then connected to a companion daemon, while Android emulators cold-boot in one to five minutes, so capacity gets pre-warmed to cut the wait. Incidentally, this is the oldest version of the simulator pitch (see this [2017 customer review](https://www.trustradius.com/reviews/sauce-labs-2017-05-16-12-15-05#:~:text=clean%20virtual%20machines) of Sauce Labs), predating agents entirely, but it matters more now: a human runs one suite at a time, while an agent fleet needs a clean, isolated environment for every session, thousands of them at once.

The counterpoint is that for a solo developer with one app and one Mac, the built-in simulator remains free, faster than any network round trip, and mostly sufficient. The bill only starts making sense when concurrency or non-Mac access becomes the binding constraint, which is exactly what agents did to a lot of teams over the past year.

## Why Developers Need Simulators

I framed the 5 reasons agents need simulators around the issue of developer experience deliberately, and as any mobile dev will tell you, mobile DevX can never be separated from Apple. Apple is the landlord of this entire market and, increasingly, a competitor within it, and the mobile devs’ relationship with their landlord is, let’s say, fraught (see my [MonkCast conversation](https://redmonk.com/videos/alex-moore-open-web-advocacy/) with [Alex Moore](https://www.linkedin.com/in/alexlmoore/)). So, to close out this discussion of the simulator market, let’s look at how Apple has approached DevX in agentic mobile development.

Apple’s developer tooling around agents has come in stages. [Xcode 26.3 put coding agents into the IDE](https://www.apple.com/newsroom/2026/02/xcode-26-point-3-unlocks-the-power-of-agentic-coding/), but some developers, like Hacker News user Osama Jaber, point out “[MCP support is the real story here](https://news.ycombinator.com/item?id=46874619#:~:text=MCP%20support%20is%20the%20real%20story).” By supporting this open protocol, developers are not locked into any one vendor’s agent—no small thing in an era when agent experience is becoming as important as developer experience. Then at WWDC in June, Xcode 27 introduced Device Hub, a standalone app through which Apple says agents can [validate their own work](https://www.apple.com/newsroom/2026/06/apple-aids-app-development-with-new-intelligence-frameworks-and-advanced-tools/): writing and running tests, checking visual changes with previews, and driving the simulator directly.

Reception has been rocky. [Léo Natan](https://www.linkedin.com/in/leo-natan/), a senior macOS and iOS software engineer at CrowdStrike, called Device Hub [“a broken shitshow,”](https://mastodon.social/@LeoNatan/116816562237855032) and [Craig Hockenberry](https://furbo.org/), principal at the Iconfactory, [reports](https://mastodon.social/@chockenberry/116835140290102064) that it sometimes leaves CoreSimulator processes running after quit, at a cost of several hundred processes per device. (See reason #1, Capacity, for why this is a problem). The complaint predates Device Hub, too: Hacker News user Aloisius described iOS simulators as “[quite slow to start/update/run](https://news.ycombinator.com/item?id=46874619#:~:text=quite%20slow%20to%20start),” prone to eating memory when Xcode fails to shut them down, and missing basics like background processes and Spotlight. Social media does select for grievance, so it is worth noting that [Steve Troughton-Smith](https://www.linkedin.com/in/steventroughtonsmith/), founder of High Caffeine Content, [professes to enjoy](https://mastodon.social/@stroughtonsmith/116795076450982914) remote-controlling physical devices through Device Hub.

Devs have been willing to jump through Apple’s hoops for many reasons, but agentic software development acts as a forcing factor in markets that touch the SDLC. Thus, for example, the rise of markdown, or the current industry paroxysm around application and infrastructure security post Fable, and the Hugging Face hack by OpenAI’s agents. As agents become more capable it’s harder than ever to justify jumping through hoops. Agents are pretty good at jumping through hoops to be fair, but it’s hard to scale the kind of verification that goes with Apple control and restrictions. Naturally, the industry is trying to find ways to make it easier than ever to build capable iOS applications, using agents that are often running on Linux. So this burst of innovation is not unexpected, and MCP is an important part of the story.

Looking to the future of this space, today we have emulators, simulators and real devices, but what agents want is full access to our machines. Computer control seems to be the direction all of this is heading, so the current simulator boom may end up being just a stopover, rather than the final destination.

**Disclaimer:** Google, AWS, and Expo are all RedMonk clients.