Ilia Bukin

"Boot a virtual iPhone via Apple's Virtualization.framework using PCC research VM infrastructure."

That one-liner is the whole pitch of vphone-cli, and it reads like a typo. A full iPhone image, booted in a VM on a Mac, using components Apple shipped itself: the firmware for a virtual-phone research platform that started showing up inside Private Cloud Compute (PCC) images with cloudOS 26. No Corellium-style emulation involved. ¹ ² ³

There is no emulator here. Apple publishes an iOS kernel built to run in a VM; vphone-cli pairs it with the iOS user space, patches the boot chain, and boots the result through Apple's own Virtualization.framework. Within a day it was on the Hacker News front page, where the thread had 399 points and over a hundred comments; the repo carries about 9.3k stars on an MIT license. ¹ ⁴ ²

Where the virtual iPhone came from

Around late 2025, researchers noticed that Apple had added vphone600ap-related components to PCC firmware, starting with cloudOS 26. ³ The writeup by researcher wh1te4ever documents the find: the PCC research stack includes a hardware platform Apple calls vresearch101, with a bootrom (AVPBooter.vresearch1.bin) sitting in Virtualization.framework's own Resources directory, plus a SEPROM and a separate SEP storage file. ³ None of this appears in Apple's public docs, which describe the framework as a way to run macOS and Linux guests. ⁵

Apple publishes the source for the research VM's launcher binary, vrevm, in its security-pcc repo, which Apple describes as code for researchers to independently verify PCC's security and privacy characteristics. ³ ⁶ The launcher sets up a hardware model with a 1290x2796 display, the resolution shared by the iPhone 14 Pro Max, 15 Plus, 15 Pro Max, and 16 Plus, and it reaches into private Virtualization.framework methods to do it. ³

wh1te4ever built a working virtual iPhone in January 2026 by mixing cloudOS 26.1 and iOS 26.1 IPSW components, patching the boot chain (iBSS, iBEC, LLB), bypassing Signed System Volume verification, and neutering trustcache enforcement in the TXM. ³ Compared with the QEMU-based Inferno project, it ran much snappier, and it appeared to support Metal acceleration. ³ vphone-cli turned that manual process into commands.

Not emulation, and not the Simulator

This distinction came up constantly in the HN thread. The iOS Simulator is a build of iOS user-space frameworks compiled to run natively on macOS, sharing the Mac's kernel. ² A virtual iPhone runs the actual iOS kernel and user space from an IPSW inside a VM. One commenter:

Note that, unlike Corellium, this isn't about emulating an iPhone. Apple is providing an iOS kernel for Virtualization.framework in PCC/cloudOS images and this project pairs it with the iOS user-space and patches to make everything run. ²

That difference matters for security work: a real kernel to debug, real crash semantics, and on the jb variant, a real jailbreak. It is not a perfect stand-in for hardware. One commenter noted applications can fairly easily tell the VM apart from the real thing, and saagarjha said it is not a super accurate performance simulator. ² But it covers what the Simulator cannot: network extensions and hardware-dependent paths (GPU work, AR, hardware decoding) refuse to run in the simulator, and the class of bug where an app runs fine in the Simulator but crashes on real hardware gets a place to reproduce. ²

What you do with it

The requirements are specific: Apple Silicon, macOS 15 or newer, Xcode with the iOS SDK, and a SIP/AMFI relaxation step, because running the private PV=3 entitlements and unsigned binaries demands it. ¹ The README offers two routes: fully disable SIP and set an AMFI boot-arg, or keep SIP on with a debug-relaxed config and allowlist the signed app with vphone-amfidont. ¹

Then:

brew install zqxwce/tap/vphone-cli
vphone-cli vm create myphone -V jb
vphone-cli vm launch myphone

brew install zqxwce/tap/vphone-cli
vphone-cli vm create myphone -V jb
vphone-cli vm launch myphone

vm create runs the whole journey in one command: download and merge the IPSWs, patch the boot chain, boot into DFU, restore, install the custom firmware, and first boot. ¹ Five firmware variants apply progressively more patches:

less: patchless, keeps iOS mitigations enabled
regular: AMFI/SSV/Img4/TXM bypass
dev: adds the TXM entitlement and debug bypass
jb: full jailbreak, Sileo and TrollStore auto-install on first boot
exp: the jailbreak set plus anti-VM-detection research patches ¹

Once running, you reach it over SSH (ssh -p 22222 mobile@<vm-ip>, password alpine) or VNC (vnc://<vm-ip>:5901). ¹ The VM tooling is more than a launcher: vm list, vm clone (fast APFS clone, fresh device identity), vm export/import with zstd, a --headless boot for scripted runs, and per-VM network config. ¹ ⁴ Recent releases added opt-in Frida Stalker support on cloudOS 26.4+ and made the jailbreak variant add build.frida.re as a Sileo source at first boot, both aimed at the security-research crowd. ⁴

One FAQ note: during setup, avoid Japan or the EU as your region. The regulatory checks those regions add (alternative app marketplaces and such) are checks a VM cannot satisfy. ¹

The automation angle

The tool exposes a host control socket (<bundle>/vphone.sock) for programmatic control: screenshots, touch, swipes, hardware keys, clipboard. ¹ Community project vphone-mcp wraps that socket as an MCP server, so an agent can tap, swipe, and read the screen, with each action returning an inline grayscale screenshot of roughly 20-30 KB, no extra round trip to see the result. ⁷ Its README shows an agent driving Settings to General and About. That is the trajectory: a headless virtual iPhone as an E2E test target that agents can drive. ⁷

The thing that doesn't work: Apple services

Once you have a booting iPhone VM, the obvious question is whether it signs into iCloud, installs from the App Store, or uses iMessage. Currently it cannot. Apple services check the kern.hv_vmm_present sysctl on the device, and when it reports a VM they refuse to contact Apple's servers at all. ⁸ The repo's discussion thread digs further: patching that sysctl out of the kernel lets you log in and get listed as a trusted device, but finishing the handshake needs a UCRT signed by Apple whose private key lives in the SEP. A VM has no SEP. Apple's server rejects the request. ⁸ A project collaborator has an experimental kernel-patch variant in a draft PR, not ready to merge. ⁸ The thread is a good tour of how deep device attestation goes.

The cat and mouse

People in the HN thread could not help noting the arc: after Apple's attempts to shut down Corellium's virtual iPhones, components Apple ships itself make a local virtual iPhone possible. ² Nobody expects that to stay friction-free. Firmware gates move, and Apple could close the window in a future cloudOS. One user reported Apple services had worked on an earlier build of theirs and now do not; others suspect Apple has started blocking these VMs. ⁸

For now the project is moving fast, with releases landing through August and the latest, 1.0.12, published on August 29, 2026. ⁴ If you have an Apple Silicon Mac you can afford to relax SIP on, this is the quickest route I have seen to a real iOS kernel on your desk for testing and kernel work. The repo's FAQ covers the setup gotchas, and the discussions cover the sharp edges. ¹