You Can Now Boot a Real iPhone on Your Mac

Apple's Virtualization.framework is quietly booting full iOS on Apple Silicon. Here's why that changes iOS testing and security research.

Dafallah Ibrahim

— 2 min read
Share

For fifteen years, iOS testing has meant two bad options: the Xcode simulator, which isn't really iOS, or a metered device farm tapping buttons on rented iPhones. This weekend a third path appeared. A tool called vphone-cli, currently near the top of Hacker News, boots a complete virtual iPhone on your Mac using Apple's own Virtualization.framework.

Why this matters

The simulator is a lie we've all agreed to live with. It runs your app as a macOS process linked against iOS frameworks — same kernel, same daemons, your Mac's GPU drivers. Any bug living in the actual iOS stack (networking edge cases, daemon behavior, storage quotas) is invisible to it. That's why builds pass in the simulator and explode on TestFlight.

Real devices mean USB hubs in a closet, or paying a cloud farm by the minute for hardware you don't control. A local iOS VM changes the economics: deterministic, snapshot-able, scriptable, and free once you own the Mac.

How it works

Virtualization.framework — the VZ API — is Apple's native hypervisor, shipping since macOS Big Sur. You configure a VZVirtualMachineConfiguration in Swift: CPU count, memory, devices. The hardware does the rest, at near-native speed on Apple Silicon. Officially, it supports macOS and Linux guests.

vphone-cli wires that same machinery to an iOS image. Same ARM architecture the framework already knows how to host, real kernel, real daemons — no recompiled shim like the simulator. And because VZ supports saving and restoring machine state, you can snapshot a booted iPhone mid-test and rewind to it in seconds. No device farm offers that.

Where this helps

  • CI pipelines: run XCUITest suites against actual iOS on Apple Silicon runners, in parallel, without a device rack.
  • Security research: probe iOS internals without jailbreaking or burning physical phones.
  • Device-only bugs: that crash that "only happens on cellular" is now reproducible, or at least cornerable.
  • OS-level integration: anything depending on iOS daemons rather than your app code.

Watch out

Apple Silicon is effectively mandatory — iOS is ARM, and VZ's ARM guests don't exist on Intel Macs. You also supply the OS image yourself: Apple doesn't distribute iOS for virtualization, so sourcing firmware sits in a legal gray zone. Read the README before building anything commercial on top.

It's unsupported. Any iOS or macOS point release can break the boot, so pin versions everywhere. And graphics remains VZ's weakest area — for fast UI iteration, the simulator is still the right daily tool. This is for OS-level fidelity, not replacing your dev loop.

Try it yourself

git clone https://github.com/Lakr233/vphone-cli
cd vphone-cli
swift build -c release
# Check the README for supported iOS versions and image setup first
.build/release/vphone --help

TL;DR

  • What changed: vphone-cli boots full iOS in a VM via Apple's Virtualization.framework.
  • Why it matters: the simulator isn't iOS and device farms are metered — a local VM is deterministic and snapshot-able.
  • Try today: build it on an Apple Silicon Mac and boot an iOS image for yourself.

Read more