Your agent writes the change in seconds. DraftVM gives it an iPhone Simulator to check it on.

Teams trust an agent’s change once they see it work. We make that check fast and cheap: iPhone and iPad Simulators on a Mac only your company uses, driven by your own agent and watched live by your team.

Request a pilot

A working name. We run zero VMs: each customer gets a Mac of its own.

An iPhone Simulator showing a login screen with a tap on the Log in button, beside the command that created it Line drawing: an iPhone outline with a login screen, a tap ring on its Log in button, and a terminal card with the draftvm device create command and the live view URL it returns. iPhone 17 Pro · Simulator email •••••••• Log in device_tap · "Log in" in build $ draftvm device create \ --device "iPhone 17 Pro" \ --app ./App.app.zip liveUrl https://…
9 vs ~2

agent sessions at once on a 2020 16 GB Mac mini, DraftVM against stock Simulators

~56 ms

from a tap to the changed screen, watched live: under a tenth of a second

~90×

faster screenshots than Apple's own tool

15

live Simulators at once on a higher-tier Mac, with the same tap time

Measured on our own Macs, November 2026.

01Ask for an iPhone

One command, or one sentence to your agent, gets an iPhone Simulator with your app on it.

The interface we are building. Not yet released.

CLI

$ draftvm device create \
    --device "iPhone 17 Pro" \
    --runtime 27.0 \
    --app ./App.app.zip --wait
liveUrl  https://…
$ draftvm device screen <session>
$ draftvm device share <session>

MCP, in the agent's own words

you, to your agent:
Open the app on an iPhone 17 Pro and check
the login screen.

the tool calls it makes:
device_create  a ready Simulator with your app
device_tap     by element reference or x, y
device_screen  the settled screenshot and tree

02How it works

Your agent stays where it already runs, in a Linux sandbox.

Through the DraftVM CLI or our MCP tools it taps, types or asks for a screenshot, and the command lands on a Mac only your company uses, in an iPhone Simulator started for that session. The screen comes back two ways: to the agent, as a screenshot once the screen has settled; and to anyone on your team, as a live view in the browser, where they can take control.

The loop: your agent, a dedicated Mac, iOS Simulators, a person watching Your agent, in its own sandbox, sends taps, typing and screenshot requests over the CLI or MCP tools, which are in build, to a Mac only you use. DraftVM on that Mac drives iPhone Simulators, one per session. The screen comes back to the agent as a screenshot and to a person on your team as a live view they can take control of. YOUR SANDBOX your agent the customer's own tap, type, screenshot CLI or MCP · in build screenshot A MAC ONLY YOU USE DraftVM drives the Simulators iPhone Simulator iPhone Simulator iPhone Simulator one per session the screen, live built take control LIVE VIEW a person anyone on your team The loop: your agent, a dedicated Mac, iOS Simulators, a person watching Your agent, in its own sandbox, sends taps, typing and screenshot requests over the CLI or MCP tools, which are in build, to a Mac only you use. DraftVM on that Mac drives iPhone Simulators, one per session. The screen comes back to the agent as a screenshot and to a person on your team as a live view they can take control of. YOUR SANDBOX your agent the customer's own tap, type, screenshot CLI or MCP · in build screenshot A MAC ONLY YOU USE DraftVM drives the Simulators iPhone Simulator iPhone Simulator iPhone Simulator one per session the screen, live built take control LIVE VIEW a person anyone on your team
Solid lines: built and measured. Dashed: in build. The coloured path is the screen on its way back.

03Why a Mac per customer

A Linux server is easy to share. A Mac is not.

The kernel caps each customer's memory and CPU, so sandbox companies put many customers on one server and bill by the second.

macOS enforces one limit, a memory cap on a single process, and a Simulator is about 70 processes. The only wall between two customers on one Mac is a virtual machine, and Apple's licence allows two per Mac, hosted only as a lease of 24 hours or more to one customer (our reading).

So we do not slice the Mac. Each customer gets the whole machine, with no VM, and each session gets a memory and CPU budget, so a runaway session can trouble only its own neighbours and is paused before it does. The price follows the shape: one flat price per Mac a month, every session on it included.

Three machines: a Linux server sliced by the kernel, a Mac that cannot be sliced, a DraftVM Mac given whole to one customer Left: a Linux server split into slices for customers A to D, each capped by the kernel. Middle: a Mac, where one Simulator is about 70 processes and macOS can cap only one of them; the only wall is a virtual machine, two per Mac, each leased 24 hours or more to one customer. Right: a DraftVM Mac, one customer and no VM, four sessions each with a dashed memory and CPU budget that is in build. A LINUX SERVER customer Acapped customer Bcapped customer Ccapped customer Dcapped the kernel caps each slice many customers on one server, billed by the second A MAC one Simulator is about 70 processes the one process macOS can cap VM one customer 24 h or more VM one customer 24 h or more the only wall is a VM: two per Mac Apple's licence: leased 24 h or more to one customer, our reading A DRAFTVM MAC one customer, the whole Mac sessionbudget sessionbudget sessionbudget sessionbudget one customer per Mac, no VM dashed: a memory and CPU budget per session, in build Three machines: a Linux server sliced by the kernel, a Mac that cannot be sliced, a DraftVM Mac given whole to one customer Top: a Linux server split into slices for customers A to D, each capped by the kernel. Middle: a Mac, where one Simulator is about 70 processes and macOS can cap only one of them; the only wall is a virtual machine, two per Mac, each leased 24 hours or more to one customer. Bottom: a DraftVM Mac, one customer and no VM, four sessions each with a dashed memory and CPU budget that is in build. A LINUX SERVER customer Acapped customer Bcapped customer Ccapped customer Dcapped the kernel caps each slice many customers on one server, billed by the second A MAC one Simulator is about 70 processes the one process macOS can cap VM one customer 24 h or more VM one customer 24 h or more the only wall is a VM: two per Mac Apple's licence: leased 24 h or more to one customer, our reading A DRAFTVM MAC one customer, the whole Mac sessionbudget sessionbudget sessionbudget sessionbudget one customer per Mac, no VM dashed: a memory and CPU budget per session, in build
The licence terms are our reading of the macOS software licence agreement.

04Benchmarks

A stock iOS Simulator takes about 5.3 GB of a Mac's memory. Optimised by DraftVM, it takes about 1.5 GB.

So a 16 GB Mac mini from 2020 runs nine agent sessions at once, where stock Simulators would fill it after about two. An agent session is one Simulator driven by an agent, with nobody watching.

ResultWhat it means
9 vs about 2agent sessions at once on a six-year-old 16 GB Mac mini: DraftVM against stock Simulators.
about 56 msfrom a tap to the changed screen, watched live: under a tenth of a second.
about 90×faster screenshots than Apple's own tool.
15live Simulators at once on a higher-tier Mac, with the same tap time.

An agent's step took no longer with the Mac full than with a single session running. Data-centre Macs should match or beat all of this; a rented one is the next measurement.

Measured on our own Macs, November 2026. "About two" is our arithmetic, not a measurement.

05Status

Built: the live Simulator view a person can watch and take over, the agent's taps and screenshots, the load test behind the numbers above. In build: the CLI and MCP tools, sign-in, the control plane.

We are starting private pilots. Write to dharin@draftvm.com.

Running agents on iOS all day? Let's talk about a pilot.

dharin@draftvm.comRequest a pilot