By ByteBot
An open-source tool called vphone-cli landed on Hacker News’ front page this morning (August 29) with 238 points. Built by indie developer Lakr233, it boots a full virtual iPhone running iOS 26 on any Apple Silicon Mac — using infrastructure Apple shipped for Private Cloud Compute security research. The project has grown to 8.9K GitHub stars since its March launch, and today’s surge suggests developers are finally paying attention.
Why the Xcode Simulator Isn’t Enough
The Xcode iOS Simulator doesn’t run a real iOS kernel. It ports iOS frameworks to execute as native macOS processes — fast and convenient, but fundamentally different from running actual iOS. That distinction is invisible for most apps, and catastrophically visible for a specific class of them. Network Extensions, VPN stacks, and entitlement-gated APIs all require a real kernel. The simulator simply doesn’t expose those subsystems.
One Hacker News commenter put it precisely: “Running on ported userspace components…isn’t the same as running on the OS itself. This really matters, sometimes.” If you’ve ever shipped a feature that worked perfectly in the simulator, then broke on every physical device, you’ve run into this wall. However, vphone-cli runs the actual iOS 26 kernel on your Mac using Apple’s Virtualization.framework with PV=3 paravirtualization support added in macOS Sequoia. No emulation. The real thing.
How Apple’s Virtualization Framework Makes This Possible
When Apple introduced Private Cloud Compute for Apple Intelligence processing, they needed a way for security researchers to audit PCC nodes. Their solution: a Virtual Research Environment that boots PCC software in a virtualized macOS environment for dynamic security analysis. To make it work, Apple added PV=3 paravirtualization support to Virtualization.framework in macOS 15 Sequoia. Moreover, PV=3 lets a guest OS communicate directly with the hypervisor instead of emulating hardware — which is what makes genuine iOS kernel boot possible.
Lakr233 reverse-engineered those components and applied between 41 and 112 firmware patches to boot standard iOS 26 firmware on an M-series chip. The irony isn’t subtle: Apple spent years litigating against Corellium for providing commercial iOS virtualization to security researchers. They eventually settled. Furthermore, Apple then shipped the very building blocks that enable it themselves, wrapped in a “PCC research” label. vphone-cli connected the dots.
Three vphone-cli Variants and When to Use Each
vphone-cli ships three firmware configurations. Regular applies core security bypasses (AMFI, SSV, Img4, TXM) for a basic bootable iOS environment. Development adds TXM entitlement and debug bypasses for general developer testing. Jailbreak applies 112 patches with Sileo and TrollStore auto-installed, giving full root access via SSH. For security research requiring Frida hooks or deep filesystem inspection, jb is the right variant.
In fact, setup is straightforward with Homebrew. SSH access drops you into a standard jailbreak shell with the familiar default password:
# Install
brew install zqxwce/tap/vphone-cli
# Create a jailbroken VM
vphone-cli vm create myphone -V jb
# Boot it
vphone-cli vm launch myphone
# Forward USB port and connect via SSH (second terminal)
python3 -m pymobiledevice3 usbmux forward 2222 22
ssh root@127.0.0.1 -p 2222 # password: alpineSnapshot and restore work cleanly. vphone-cli vm backup captures VM state in seconds, and restoring from a known-clean baseline is instant. For malware analysis or exploit testing, that workflow beats wiping a physical device every time.
What to Know Before You Set It Up
The limitations are real. SIP (System Integrity Protection) must be disabled — a non-starter on corporate or MDM-managed Macs. Additionally, Apple Services won’t work at all: the App Store, iCloud, and iMessage require hardware attestation that a VM can’t provide. The tool is Apple Silicon only (M1 through M5), Intel Macs aren’t supported, and the initial setup takes 30–60 minutes including firmware download and the restore workflow. Allocate at least 8GB RAM and 4 CPU cores, or you’ll hit timeouts during the automation phases.
The bigger risk is longevity. Apple’s Corellium litigation established they’re willing to act against unauthorized iOS virtualization. They settled, but the precedent exists. Consequently, if Apple patches PV=3 or adds kernel attestation checks that detect virtual environments, vphone-cli breaks overnight. Whether that happens depends on how seriously Apple takes this — and right now, the answer appears to be “not very.” Plan for it, but don’t let it stop you from using what works today.
Key Takeaways
- vphone-cli boots a real iOS 26 kernel on Apple Silicon Macs using Apple’s own Virtualization.framework — not emulation, not Xcode’s userspace simulator tricks
- Use the jailbreak variant for security research, the development variant for general testing, and regular for basic compatibility checks
- SIP must be disabled and Apple Services (App Store, iCloud) don’t work — know these limits before investing time in setup
- Apple shipped the underlying PV=3 infrastructure for PCC research; Lakr233 reverse-engineered it for standard iOS — the tool’s longevity depends on Apple not caring enough to block it
- Snapshot and restore make iterative security testing fast in a way physical devices never were: break something, restore from baseline in seconds
