vphone-cli 1.0.14 Runs Virtual iPhones on Apple Silicon: Requirements, iOS 27 Support and Automation

By AiCybr Editorial · Published September 16, 2026

vphone-cli is an open-source tool for running virtual iPhones on Apple Silicon Macs through Apple’s Virtualization.framework and infrastructure derived from Apple’s Private Cloud Compute (PCC) research virtual machines. The project’s current release, v1.0.14, shipped on September 10, 2026 and adds validated firmware pairings for iOS 26.6.2 and the iOS 27.0 release candidate, alongside stricter validation when importing virtual-machine bundles.

The project has grown to roughly 13,100 GitHub stars and 1,570 forks and is licensed under MIT. Its current README documents tested iPhone 17,3 firmware from iOS 18.6.2 through iOS 27.0 builds, with several cloudOS 26.x pairings. The host requirement is an Apple Silicon Mac running macOS 15 or newer, plus Xcode and the iOS SDK.

The main deployment constraint is host security configuration. vphone-cli uses private virtualization capabilities and unsigned-binary workflows, so the host must permit Apple’s research-guest virtualization path and relax some System Integrity Protection or AMFI restrictions. The project documents both a highly permissive configuration and a narrower debug-only path. That makes it primarily a research, reverse-engineering and automated-testing tool instead of a normal production virtualization layer.

vphone-cli 1.0.14 at a glance

Version 1.0.14 is a small release by line count. It matters operationally because the firmware catalogue determines which iPhone and cloudOS combinations the automated setup can assemble. The release adds an iOS 26.6.2 pairing and an iOS 27.0 RC pairing, and it validates imported VM manifests before moving them into the local VM library.

How the virtualization stack works

Apple publishes source code and research tooling around Private Cloud Compute so researchers can inspect security and privacy characteristics of PCC. That research environment includes virtual-machine infrastructure built around Apple’s virtualization stack.

vphone-cli repurposes that research path to boot iPhone firmware as a guest on Apple Silicon. Its VM manifest format is compatible with the VMBundle.Config structure used by Apple’s PCC research tooling, while the project provides its own orchestration around firmware preparation, patching, restore, custom firmware installation and subsequent guest launch.

The result is closer to a virtualized iPhone firmware environment than to an application simulator. The guest uses iPhone firmware, can expose SSH and VNC access, and supports multiple firmware patch profiles. The project currently offers five variants:

Those profiles change the guest security model substantially. Researchers should treat each VM as a controlled lab environment and keep host-side security exposure separate from daily-use workflows.

Host requirements

The current project documentation lists four principal host requirements:

• Apple Silicon
• macOS 15 Sequoia or newer
• Xcode plus an iOS SDK, used to cross-compile the guest daemon
• Research virtualization entitlement access, which requires relaxing host debug/security restrictions

The project also depends on a collection of firmware and binary-analysis tools, including Python 3.13, aria2, OpenSSL, Keystone, libusb, ipsw, zstd and signing utilities. A Homebrew installation path is available through the project’s tap.

Nested virtualization is currently outside the supported host path. The project explicitly checks for a Mac that is itself running as an Apple virtual machine and stops before attempting a PV=3 guest boot.

Security impact of the host configuration

The largest practical trade-off is the host configuration needed to load the private virtualization path. The project documents two approaches: a fully permissive SIP/AMFI configuration and a narrower option that keeps most SIP protections enabled while relaxing debug restrictions and allowlisting the vphone binary.

For a dedicated research Mac, the narrower path provides a more contained starting point. Either configuration changes normal macOS security assumptions, so a primary personal or production workstation is a poor fit for experimentation unless the operator has explicitly accepted that exposure.

Creating and managing virtual iPhones

The current CLI consolidates the complete setup pipeline into a single VM command. At a high level, the workflow performs these stages:

1. Create a VM bundle.
2. Download or ingest iPhone and cloudOS firmware.
3. Prepare and patch the firmware for the selected profile.
4. Boot the guest into DFU mode.
5. Obtain the restore ticket and restore the firmware.
6. Install the selected custom firmware layer.
7. Launch the VM for normal use.

The project also exposes each stage as a separate command for debugging or research.

VM configuration can set CPU, memory and disk allocation. The local library lives under ~/.vphone/VMs/ by default, with separate caches for IPSWs, tools, packages and the Python environment. VMs can be cloned, exported, imported, renamed and deleted from the CLI.

An APFS-aware clone path gives each cloned VM a fresh device identity while avoiding a full byte-for-byte duplicate where the filesystem can use copy-on-write semantics.

iOS 27 support

The v1.0.14 catalogue adds an iOS 27.0 release-candidate pairing and the current README lists several tested iOS 27 builds. This support represents project-tested firmware compatibility and is outside Apple’s normal application-development virtualization path.

Firmware compatibility depends on a suitable iPhone IPSW and matching cloudOS/PCC components. The tool can also accept explicit local firmware sources, which gives researchers a way to test newer combinations after the project’s patch pipeline is updated.

The tested-environment table currently includes iPhone 17,3 configurations across macOS 26.x and macOS 27 beta hosts, with cloudOS 26.1, 26.3 and 26.4 builds.

SSH, VNC and guest access

Running guests expose several developer-oriented access paths.

The jailbreak profile can provide SSH through the mobile user environment, while regular and development profiles expose root-oriented SSH access. VNC provides the interactive display path. These interfaces make the VM useful for filesystem inspection, debugging and automated application testing.

Researchers should change any default guest credentials before attaching a VM to a network beyond the local test host. The documented default credentials are designed for a lab workflow and should not be treated as hardened service configuration.

Automation and AI-driven mobile testing

One of the project’s more useful developer features is its host control socket. A running VM can accept programmatic actions for:

• screenshots;
• touch input;
• swipe gestures;
• hardware-key events;
• clipboard operations.

Each action can return a compact screenshot, allowing an external controller to observe the result and continue the interaction loop.

The project points to vphone-mcp, an MCP server that wraps this socket with higher-level controls such as opening applications, navigating, scrolling and typing. That creates a direct path for Claude Code, Claude Desktop or another MCP-capable agent to drive a virtual iPhone during end-to-end testing.

For mobile CI and agent testing, this is more consequential than the ability to display iOS in a window. A scriptable guest can reproduce device state, capture screens, exercise UI flows and reset from exported or cloned VM bundles.

Current limitations

Several constraints define where vphone-cli fits today.

Apple Silicon only. The implementation depends on Apple’s virtualization stack and research-guest infrastructure.

Host security changes are required. Private entitlements and unsigned components require a deliberate macOS security configuration.

Firmware compatibility is project-maintained. The tested matrix changes as Apple ships iOS and cloudOS builds.

Some Apple services can behave differently in a VM. The project documents setup-region combinations and guest behaviors that can affect system-app installation.

The environment is research-oriented. Guest jailbreak and experimental variants intentionally alter iOS security controls and should remain isolated from production credentials and sensitive data.

These constraints still leave a substantial use case for security research, firmware analysis, mobile automation and repeatable iOS test environments.

Why vphone-cli is notable

Apple’s official Simulator remains the straightforward tool for ordinary iOS application development. vphone-cli targets a different layer: researchers who need to work with iPhone firmware, boot behavior, system services, jailbroken environments or automation that reaches below a normal app-simulation stack.

The project’s current momentum is also significant. At roughly 13,100 stars, about 1,570 forks and a sequence of releases through September 2026, it has moved beyond a small proof of concept into an actively maintained open-source research tool.

Version 1.0.14 keeps the existing architecture and extends its practical coverage. Its iOS 27 RC catalogue update, import validation and current firmware matrix make the project materially more useful for researchers testing Apple’s newest software generation.

Bottom line

vphone-cli provides one of the most complete open-source workflows currently available for virtualizing iPhone firmware on Apple Silicon. It combines Apple’s PCC research virtualization path with firmware preparation, restore tooling, multiple guest-security profiles, VM lifecycle management and an automation socket suitable for scripted or agent-driven testing.

Its main cost is the host trust model: running it requires deliberate changes to normal macOS security controls. For a dedicated Apple Silicon research machine, that trade-off can be reasonable. For routine application development, Apple’s standard Simulator remains the lower-friction option.

Sources

• Lakr233/vphone-cli repository
• vphone-cli v1.0.14 release
• Apple Private Cloud Compute source repository