Limrun vs Run CloudCloud iOS simulators and Android emulators, compared.

What Limrun is

Limrun sells three instance types: an iOS simulator running on a real Mac, an Android emulator with an ADB tunnel, and an Xcode build sandbox. A single call can provision a simulator with an Xcode sandbox attached, so a build lands straight onto the device that streams back to your browser. Instances are created from the lim CLI, from the @limrun/api SDKs in TypeScript, Python, or Go, or from a per-instance MCP server that a coding agent can call directly.

The device-control surface is the part worth studying. Limrun documents reading the accessibility element tree, tapping by label, typing, screenshots, recordings, app lifecycle, keychain state, logs, and reverse tunnels. On top of that it documents Appium — a forked XCUITest driver on iOS, upstream Appium over ADB on Android — and Playwright against Chrome on the Android emulator over CDP. Its build story goes further than most: remote xcodebuild, Bazel remote build execution for Apple actions, signed IPAs, StoreKit in-app-purchase testing, and a GitHub Action that posts a live preview link on every pull request.

Limrun is a Y Combinator company (Spring 2026) and cites Replit, Rork, Momentic, and other agent products as users. It does not publish a rate card, so pricing is a conversation rather than a page.

What Run Cloud is

Run Cloud is one API for the computers an agent needs: Linux microVM sandboxes on Firecracker, iOS simulator sessions, Android emulator sessions, and Xcode sandboxes that archive, sign, and export a signed IPA straight to TestFlight. Mobile sessions are created with runcloud ios create or runcloud android create, or with the @run-cloud/sdk TypeScript client, and return a signed browser URL for the live stream along with labels, inactivity timeouts, hard timeouts, and a capacity queue that waits for a free device instead of failing the call.

The distinguishing capability is input. A browser webcam can be carried into the remote simulator's camera pipeline, so a QR scanner, a document-capture flow, or a video-calling screen sees live frames instead of a static placeholder. Uploaded video and images can be imported into Photos for repeatable runs, and audio can be looped through the app's microphone input. Sessions run in parallel, which is what makes broadcaster-and-receiver or multi-device demos practical.

The other half is embedding. The signed session URL takes an embed mode and an optional loading guard, emits streaming, app-launch, authentication, inactivity, and completion events to the parent page, and accepts commands for reload, Home, rotation, screenshots, and the accessibility inspector. That is the difference between showing a device in a demo and shipping one inside your product.

Device control: scripted versus streamed

This is the clearest split, and it is worth being blunt about. If your workflow is a loop of read the screen, tap a control, assert on the result, Limrun documents that loop end to end — element tree, tap by accessibility label, typing, screenshot — and exposes it to agents through MCP. Run Cloud's SDK today covers session lifecycle, app install, open URL, screenshot, media upload, and release; the tapping happens through the live stream, the embed command channel, or a test harness you already run inside the app. First-party test-framework support is planned for Run Cloud, so treat this as a description of today rather than a permanent boundary.

Which one is right depends on who is holding the phone. Automated regression suites want the scripted API. Products where a human, or a human watching an agent, drives a real device in the browser want the streamed session and the embed contract. Teams doing both should test the exact flows they care about before picking.

Builds and the Apple problem

Neither platform expects you to own a Mac, and both cover the same core loop. Both run Xcode sandboxes that build your source in the cloud and hand back an artifact, and both produce signed IPAs for real devices and TestFlight. On Run Cloud that sits on the same account as your simulators and sandboxes — archive, sign, export, upload — and it is free during beta. On Limrun the build sandbox can be provisioned together with a simulator so the result installs onto the paired device as soon as xcodebuild finishes.

The remaining differences are around the edges of the build, not the build itself. Limrun additionally documents Bazel remote build execution for Apple actions, which matters for large repositories already on Bazel, StoreKit in-app-purchase testing, and a GitHub Action that posts a live preview link on every pull request. If any of those is the reason you are shopping, weigh it. If you need source in and a signed artifact out, both platforms do that today.

Pricing and how to compare it

Run Cloud publishes its rates: simulator sessions cost $0.02 per active minute, Linux sandbox CPU is metered per core-second and memory per GiB-second, and Xcode builds are free during beta. Sign-up, API keys, and billing are self-serve in the dashboard. Limrun does not publish a rate card as of July 2026, so getting a firm number means contacting them; the figures typically quoted are around $0.06 per minute for Android and $0.12 per minute for iOS, three to six times the Run Cloud rate for the same active minute.

When you do compare, normalize on the same unit. Ask what counts as billable time — active minutes, wall-clock instance life, idle time before an inactivity timeout fires, build minutes — and price the workload you actually run: a 40-second smoke test on every pull request bills very differently from a session a customer keeps open for twenty minutes.