LoginGet startedDashboard
Compare · Mobile simulators

Sandal vs Limrun

Limrun is simulators first: real Macs running the iOS Simulator and xcodebuild, scripted tap-and-assert control, Appium and Playwright, PR previews and StoreKit testing. If iOS and Android simulators are the entire job, Limrun is further along that path than we are. Sandal is the same device plus the sandbox and the CI runner around it, on one published, per-second rate card.

Start buildingSee the migration
Reviewed August 2026 · 2 sources
Published rate card
, LimrunYesSandal
Stream
Signed URLLimrun60 fps · signed URLSandal
Test frameworks
Appium · PlaywrightLimrunAppium · XCUITest · ADBSandal
Also on the account
Xcode buildsLimrunSandboxes · CI · XcodeSandal
The honest split

Two good answers. Here is which one is yours.

Pick Limrun if
  • iOS and Android simulators are the whole job and you want the deepest device tooling today.
  • You rely on Bazel remote build execution, StoreKit sandbox testing or their PR-preview action.
  • OIDC SSO and published egress IPs for allowlisting are requirements.
Pick Sandal if
  • The agent that drives the device also needs a sandbox to run code and a runner to build it.
  • You want a published per-second, per-device rate you can budget against.
  • You want the accessibility tree and screenshots as SDK calls the agent can branch on.

Many teams run both. runs-on is per job and a sandbox is per task; nothing here is all or nothing.

Side by side

What each one actually ships.

Documented capability as of August 2026. Where the honest answer is a qualifier rather than yes or no, the qualifier is printed. Scroll sideways on a small screen.

Limrun compared with Sandal, August 2026
AreaLimrunSandalWhy it matters
Runtime
DevicesiOS simulators and Android emulators on real Macs.iOS simulators and Android emulators, booted from a warm pool.Both rent you a phone you never plug in.
StreamSigned stream URLs and a remote-control React component.60 fps H.264 stream, under 50 ms tap to frame, signed URLs, embeddable.Human-in-the-loop needs the pixels live.
Pricing
BillingNo public rate card at review; quotes on request.Per second, per device, published.A rate you can put in a budget.
Surfaces
Buildsxcodebuild on the Mac, Bazel remote execution, StoreKit sandbox, PR previews.Build API on Apple silicon we own; install the result straight onto a device.The build and the device belong together.
Beyond mobileXcode builds.Linux, Windows and macOS sandboxes, GitHub Actions runners, Xcode builds.The agent that taps the app also has to build and test it.
Developer experience
ControlScripted tap, assert, Appium and Playwright, an MCP server.Tap, swipe, type, screenshot and the accessibility tree as SDK calls; Appium, XCUITest and ADB tunnels.Agents need return values they can branch on.
Sources · reviewed August 2026

Capabilities change and rates change. If something here is out of date, tell us and we will fix it the same week.

Price

Same shape. Two meters.

Limrun did not publish a rate card in our August 2026 review. Sandal publishes per-second, per-device simulator rates on the pricing page.

LimrunOne simulator
No public rate card at review, quotes on request
SandalOne simulator · paused = $0
per second
Price your own fleetThe full rate card
How to compare

Normalise both vendors on the same unit before you compare: one device, one hour, the same size. Sandal meters per second and a paused machine costs nothing, so a bill for bursty work is the sum of the seconds it actually ran.

Open the rate card →
Migration

Same shape, native SDK.

The lifecycle maps one to one, create, exec, files, stop, so the port is a small rewrite, not a re-architecture. Keep the vendor-specific glue on your side of the boundary.

test.tsinstall → drive → assert
import { Sandal } from "@sandal/sdk";
const sandal = new Sandal({ apiKey: process.env.SANDAL_API_KEY });
const dev = await sandal.devices.create({ kind: "ios-simulator" });
await dev.install("./build/Store.app");
await dev.launch("dev.example.store");
await dev.tap(120, 640);
const tree = await dev.elementTree();
expect(tree.nodes.map((n) => n.label)).toContain("Order confirmed");
  1. 01≈ 2 min

    Install the SDK

    npm install @sandal/sdk or pip install sandal, one API key.

  2. 02≈ 1 hour

    Point your suite at a device

    Open an Appium, XCUITest or ADB tunnel to the endpoint, or drive it from the SDK.

  3. 03≈ 1 afternoon

    Fan out a matrix

    Boot a device per PR, record the runs that fail, and compare the bill.

Where Limrun is ahead

What we would rather you read here than find later.

A comparison page where the vendor wins every row is a brochure. These are real, and we would rather you land on the right tool than land on us and leave in a month.

  • 01

    Depth on the device.

    Scripted control, Appium and Playwright, Bazel remote execution, StoreKit sandbox testing, PR previews, OIDC SSO, published egress IPs. Limrun is further along the simulator path than we are today.

Before you switch

Questions teams ask before moving off Limrun.

Sandal publishes per-second, per-device rates. Limrun did not publish a rate card in our August 2026 review, so normalise on the same unit with their quote before comparing.

More comparisons

The rest of the field in mobile simulators.

All comparisons and the full matrix →
    Get started

    Run the same job twice.

    Point one workload at Sandal and one at Limrun. The numbers on this page are ours; the ones that matter are yours.

    Start buildingRead the docs
    npm i @sandal/sdk