vphone-cli boots real iPhone firmware in a VM via Apple's Virtualization.framework

An open-source tool called vphone-cli can boot a working virtual iPhone on an Apple Silicon Mac by repurposing Apple's own Virtualization.framework. The project, hosted on GitHub by the developer known as Lakr233 and currently on the Hacker News front page, automates the entire chain: it downloads Apple's iPhone and CloudOS firmware images, patches the boot chain, performs a DFU-style restore, installs custom firmware and boots the VM, end to end from a single command.

How iOS gets past the hypervisor

Apple's Virtualization.framework officially supports macOS and Linux guests, not iOS. According to the project's README, the gap is bridged by what it calls PCC research VM infrastructure — PCC being Apple's Private Cloud Compute — which involves private PV=3 entitlements applied to an unsigned binary. Because those entitlements are private, the host Mac must relax its own protections first. Two routes are offered: fully disable SIP and set the AMFI boot-arg, or keep SIP on in a debug-relaxed state (via csrutil enable --without debug plus csrutil allow-research-guests) and allowlist the vphone binary with a bundled helper, vphone-amfidont, leaving AMFI active system-wide.

Once booted, a VM is reachable over SSH on port 22222 or VNC on port 5901, and .ipa or .tipa files can be installed through an Install menu. The CLI covers the usual lifecycle management — CPU, memory and disk configuration, fast APFS clones with a fresh device identity, compressed export and import, renaming and deletion. Everything is stored under ~/.vphone/ by default, with downloaded IPSWs and packages cached and reused across VMs.

Five depths of firmware patching

The tool ships five patch variants, described as escalating security bypasses. The "less" variant applies only 4 patches and keeps iOS mitigations enabled; "regular" applies 42 patches across 10 phases to bypass AMFI, SSV, Img4 and TXM checks; "dev" adds 53 patches including entitlement and debug bypasses; "jb" is a full jailbreak of 113 patches that auto-installs Sileo and TrollStore on first boot; and "exp" extends that with 141 patches, including anti-VM-detection research modifications. A per-component breakdown is documented in the repository. The single vm create command runs the whole pipeline, or each stage can be driven manually.

Requirements and rough edges

Prerequisites are an Apple Silicon Mac on macOS 15 or newer, Xcode with the iOS SDK to cross-compile a guest daemon, a long list of Homebrew dependencies, and a host that is not itself a VM — the required PV=3 guest boot cannot nest. The project's tested-environments table covers recent Mac host builds (identifiers Mac16,6 through Mac16,12) against iPhone firmware from iOS 18.6.2 up to 27.0 betas, paired with CloudOS builds from 26.1 through 26.4.

The FAQ documents the expected friction. Region selection during iOS setup must avoid Japan and the EU, whose regulatory checks the VM cannot satisfy. The home button has to be simulated with a right-click over VNC. Apps crashing with EXC_GUARD require a re-patch with a --force-exc-guard flag. One nasty bug sits outside the project: the Homebrew-stable ldid-procursus 2.1.5 hangs with unbounded memory use when re-signing system binaries whose entitlement plists contain an integer 0 — an unsigned loop counter underflow — and needs a rebuild from the fixed upstream source.

Built for automation

Each VM exposes a host control socket, vphone.sock, accepting programmatic actions such as screenshots, touch input, swipes, hardware key presses and clipboard access, with each action returning an inline screenshot. The README explicitly frames this as suited to AI-driven end-to-end testing, and a companion project, vphone-mcp, wraps the socket as an MCP server. The repository credits wh1te4ever's "super-tart-vphone" writeup as its foundation.

Why it matters

iOS has long been the odd platform out in virtualization: Apple offers the Xcode Simulator, which runs a Mac-native simulator runtime rather than real device firmware, or physical devices with all their provisioning limits. A reproducible virtual iPhone — cloneable, snapshot-friendly, scriptable over a socket, and bootable in a jailbroken variant — changes what security researchers, QA teams and app developers can do, and the automation hooks point directly at AI-agent test harnesses.

The trade-offs are equally clear. The deepest firmware variants deliberately strip iOS's security mitigations, and the host itself must run with SIP and AMFI relaxed to boot the guest at all, which makes this research tooling rather than production infrastructure. It also depends on private Apple entitlements that a future macOS release could withdraw. As a demonstration that Apple's own hypervisor can run Apple's phone operating system when handed the right entitlements, however, it is a notable piece of engineering.