vphone-cli is a Swift command-line tool that boots a virtual iPhone on an Apple Silicon Mac, using Apple's Virtualization framework together with the research VM infrastructure behind Private Cloud Compute. It is aimed at iOS developers, tweak authors and security researchers who want a real iOS instance they can patch, poke at and throw away without touching a physical handset. The project is MIT-licensed and has gathered more than 13,000 stars and 1,500 forks since it first appeared.
What it does
The headline is a single command. vphone-cli vm create myphone -V jb runs the whole pipeline end to end: download the firmware, patch it, perform a DFU restore, install the custom firmware, and carry the machine through its first boot. vphone-cli vm launch myphone then starts it, and from there you can SSH straight into a shell on the guest.
Five patch levels are available through the --variant flag, ranging from stock security behaviour up to a full jailbreak. On the jailbroken variant, Sileo and TrollStore are installed automatically during first boot, so the VM is ready for tweak work the moment it comes up rather than after an afternoon of manual setup.
Around that pipeline sits the VM management you would expect from a hypervisor front end:
vm listandvm infoto see what you have, with--jsonfor scriptingvm newto create an empty bundle, andvm configto set CPU count, memory and diskvm clone, which uses a fast APFS clone and gives the copy a fresh device identityvm export, which writes a.tzstarchive — zstd for speed by default,--maxfor xz -9
Because the create pipeline is assembled from those smaller steps, you can also drive it by hand or re-run a single stage when something goes wrong partway through.
How it works
The host side is a Swift program that drives Apple's own Virtualization.framework, so the guest is real iOS running on the Mac's silicon rather than an emulator or a simulator runtime. The guest also needs a companion daemon, vphoned, which the build cross-compiles against the iOS SDK — that is why a working Xcode install with the iOS SDK is a prerequisite rather than an optional extra.
The catch is entitlements. Booting a guest this way relies on private PV=3 entitlements that Apple does not hand out to unsigned binaries, so the README asks you to relax SIP and AMFI on the host machine before anything will launch. That is a deliberate, system-wide lowering of macOS's own protections, and it is the single most important thing to understand before installing.
Getting started
You need an Apple Silicon Mac running macOS 15 (Sequoia) or newer, Xcode with the iOS SDK, and the relaxed SIP/AMFI configuration described above. A row of Homebrew dependencies also has to be present, including Python 3.13, aria2, wget, GNU tar, OpenSSL 3, ldid-procursus, sshpass, keystone, cmake, libusb, ipsw and zstd.
The quickest route is the tap: brew install zqxwce/tap/vphone-cli. To build from source instead, clone with --recurse-submodules, run ./scripts/setup_tools.sh to install dependencies, build the toolchain submodules and create the Python virtual environment, then ./scripts/build.sh to build and sign the binary, bundle the app and cross-compile the guest daemon. The result lands in .build/vphone-cli.app/Contents/MacOS/, where vphone-cli --help will list everything.
When to use it / when not
This is a good fit when you want a disposable iOS environment: developing and testing tweaks, trying package managers and sideloading tools, reading iOS internals, or handing a colleague a cloned VM with a fresh identity instead of shipping a spare device around the office. The export and clone commands make a known-good image easy to snapshot and hand out.
It is a poor fit in several common situations. An Intel Mac or a macOS older than Sequoia is simply out of scope. If the machine is managed by an employer, shared, or holds anything you care about, permanently weakening SIP and AMFI is a price you probably should not pay — use a second Mac instead. And the README itself labels its demo screenshot a proof of concept, so treat the whole pipeline as research tooling: expect rough edges, expect firmware downloads and restores to take real time, and do not plan production workflows around it.
For anyone who works close to iOS — tweak developers, jailbreak enthusiasts, mobile security researchers — this is a genuinely useful piece of infrastructure, because rebuilding a broken test device from scratch stops being an evening's work and becomes one command. For everyone else, it is a fascinating demonstration of what Apple's own virtualization stack can be pointed at, and a tool whose entry requirements — Apple Silicon, a recent macOS, Xcode, and a host with its security guardrails switched off — should be read carefully before the first brew install.