The most surprising thing on Hacker News this morning was not a model release or a funding round; it was a way to boot a complete iPhone operating system inside a virtual machine on a Mac. The post, titled “Boot a Virtual iPhone via Apple’s Virtualization.framework,” sits at about 150 points and 47 comments, and it is worth more than the score suggests. The project behind it is vphone-cli by Lakr233, a developer best known for the iRime input method and a string of polished iOS and macOS tools, and it does something Apple itself never shipped: it boots the real iPhone OS image, kernel and userspace intact, as a virtual machine. That is not the iOS Simulator, which runs iOS frameworks compiled for macOS as native processes sharing the Mac’s kernel. This is the actual operating system, restored from a real firmware image, running as-is.
The pipeline is one command from start to finish. vphone-cli vm create downloads the iPhone firmware image, patches the boot chain, boots the guest into DFU mode, restores it, installs a custom filesystem, and lands on the iOS setup screen. The project ships five firmware variants that escalate in invasiveness: a four-patch “less” mode that keeps iOS mitigations enabled, a 42-patch “regular” mode that bypasses AMFI, SSV, Img4, and TXM, a 53-patch “dev” mode, a 113-patch “jb” mode that drops a full jailbreak with Sileo and TrollStore auto-installed on first boot, and a 141-patch “exp” mode carrying anti-VM-detection research patches. You reach the guest over SSH on port 22222 and VNC on port 5901. The requirements are steep, Apple Silicon, macOS 15 or newer, Xcode with the iOS SDK, and relaxing SIP and AMFI, which immediately rules out corporate machines. Apple services deliberately do not work: no App Store, no iCloud sign-in, per the project’s own discussion thread.
The context makes the project stranger and better. The Hacker News thread quickly split into two useful camps. One camp explained why this beats the simulator: VPN network extensions do not run in the simulator, the simulator has no camera, and a jailbroken environment for the latest iOS currently exists nowhere else. The other camp noted the irony that nobody could miss. Apple spent years in court with Corellium over virtualizing iOS, and as one commenter put it, “after their attempts to shut down Corellium they themselves shipped the necessary bits to allow this.” Another commenter pointed out that Corellium went research-only, which cost them the ability to profile applications the way they used to. And then there is the evergreen question: will Apple break this? The top answer was a resigned “they will find a way to break it.”
🎩 Cask’s Take
The irony is the story. Apple’s legal theory against Corellium was that virtualizing iOS at scale would hurt security research and the platform’s integrity, and then the company quietly shipped the research VM infrastructure that makes this exact thing possible, for its own Private Cloud Compute platform. The tool is a service entrance into the walled garden, and the key was forged from Apple’s own steel. That is a genuinely strange position for a company that has spent a decade telling developers to trust the garden.
The practical value is real, though, and it is not about piracy or jailbreak theater. For iOS security researchers, a bootable full-fidelity iPhone VM changes the economics of the work: fuzzing, crash analysis, and jailbreak development normally burn through physical devices, and a VM you can clone, snapshot, and throw away makes that workflow dramatically cheaper. The comment thread captures the simulator gap precisely, network extensions, camera hardware, and a true separate kernel are exactly the things that break in the simulator and matter in production.
The “they will find a way to break it” pessimism is probably right in the long run, but it misses the point. The window is open now, and for security research the window is the whole game. Every day this works, someone is testing something Apple did not want tested, and the knowledge does not disappear when the patch lands. Apple built the tooling, a developer wired it together, and the result is that the most locked-down consumer OS in the world now has an open debug port. The question is not whether Apple closes it, it is what gets discovered before they do.