What the project claims
The repository describes a full Windows 11 24H2 ARM64 desktop, build 26100, running on a non-jailbroken iPhone Duo. The device is identified as iPhone19,4, with an Apple A20 Pro chip and iOS 27 with Apple's Trusted Execution Monitor (TXM). The project says it does this without Apple's Hypervisor.framework.
The project's screenshots show two things running inside the guest:
- Microsoft Edge loading live HTTPS pages.
- Antigravity 2.31.0 running as a native ARM64 Windows app.
The project says x86-64 programs run through Windows 11's built-in Prism emulation layer. All of this is the developer's own demonstration. I found no independent compatibility testing.
Translation, not virtualization
WindowsiOS is not a conventional hardware-virtualized guest. The engine translates ARM64 code from Windows into ARM64 code the iPhone can run. It uses a JIT compiler and a software memory-management unit (MMU).
The repository credits Henge, an earlier open-source project that ran macOS on iPhones, as the foundation. It also credits Husk, StikDebug/StikJIT, libslirp, TianoCore EDK2 and Red Hat's virtio-win. It does not present the stack as wholly original.
The README says Windows needs several things that earlier iPhone emulation work did not handle:
- 4 KB memory pages. Henge targeted macOS guests with 16 KB pages.
- Windows-specific ASID handling. Windows places the process address-space ID differently from Linux and macOS.
- Prism's memory-ordering behavior. Prism uses unaligned memory-ordering instructions that the iPhone host would otherwise fault on, so the engine routes them through software helpers.
- A PC-class platform. Windows refuses device-tree boot, so the project presents UEFI, ACPI, NVMe, USB 3.0 xHCI, Intel HD Audio and VirtIO networking.
Those are README claims about the implementation. They have not been independently verified.
The JIT is also why the project needs a debugger. The README says iOS 26 and 27 devices with TXM enforce strict rules on JIT execution. It says interpreter-only emulators such as UTM SE can take tens of minutes to reach the Windows 11 desktop. That comparison comes from the project itself, not from a benchmark.
The guest hardware
The documented virtual machine looks like this:
| Component | Reported implementation |
|---|---|
| CPU and RAM | 4 virtual CPUs, 4,608 MiB (4.5 GiB) |
| Firmware | EDK2 ArmVirtQemu UEFI with persistent variables |
| Storage | NVMe 1.4 controller |
| Input | USB 3.0 xHCI with a boot keyboard and an absolute tablet |
| Network | VirtIO Ethernet (Red Hat NetKVM driver) over libslirp user-mode NAT |
| Audio | Emulated Intel ICH6 HD Audio, 48 kHz speaker and microphone |
| Display | Metal presentation at 120 Hz |
Folding and sign-in
The app changes layout with the hinge. Folded like a laptop, the top half of the screen shows Windows and the bottom half acts as a keyboard and trackpad. Unfolded, it switches to a full-screen "Open Studio" mode.
Google sign-in in Antigravity goes through a small helper, WinIOSBrowser.exe. It hands the login to an iOS Safari sign-in sheet. The README says this gives access to existing Safari sessions, passkeys and Face ID. A toggle lets you use Edge instead.
Setup: a Mac and a debugger
This is not consumer-friendly. The documented requirements are:
- An Apple Silicon Mac (M1 or newer) with Xcode, xcodegen, meson, ninja, pkg-config, libslirp, LLVM/LLD and Python 3. The developer says he used an M5 Pro.
- Your own Windows 11 24H2 ARM64 retail installer, EDK2 firmware and WHQL VirtIO NetKVM drivers. None of these are in the repository.
- The project's Python scripts to provision the Windows image. An offline optimizer then removes more than 35 background components, including Defender, telemetry and indexing-related ones.
- Packaging the image, building the iOS app in Xcode and installing it with Apple's devicectl.
- Running scripts/launch_on_duo.sh. It starts the app, attaches LLDB, enables a 384 MiB dual-mapped JIT region, allocates the 4,608 MiB of guest RAM, then detaches.
"Without a jailbreak" is accurate, but it still means a developer toolchain and a debugger attached at launch. I found no release or installer on the repository page.
Note the optimizer. It strips Defender and telemetry services from the guest image. That may suit a resource-limited phone experiment, but it is not a configuration to copy onto a real work machine.
Performance claims
The developer calls the speed "near-native." The evidence offered is an idle desktop using 1.46 GB of the 4.5 GB of guest RAM, with the virtual CPUs about 89 percent idle. That shows the idle footprint, not responsiveness under load. The project has not published boot times, app launch times or battery figures. Treat "near-native" as unverified.
Limits and caveats
- One device. The iPhone Duo is the only phone it has been verified on. The code targets iPhones on iOS 26 or 27 with TXM. The same engine also runs on Apple Silicon Macs.
- Early stage. At the time of reporting, the repository had six commits. The first was on November 8 and the latest on November 11, which added a Paint launcher.
- Licensing. The code is GPL-2.0-or-later. Windows itself is not distributed. You supply your own retail media, so normal Microsoft licensing still applies to that installation.
- AI-assisted. The developer says the whole bring-up was built with the Gemini 4 Carbon model. The repository makes the same claim. It is a marketing-flavored detail from someone who works at Google AI Studio, so weigh it accordingly. It also shows what AI-assisted low-level engineering is now attempting.
- No Microsoft involvement. This is not an official Microsoft effort. A Microsoft Q&A thread from early November notes that Microsoft has not announced a date for adapting its Windows App for iPhone Duo. That app is a remote-desktop client and a different thing from running Windows locally.
Why Windows users should care
Windows 11 on ARM64 has long been a niche. A project running it locally on a phone chip shows how much of the platform can be emulated: UEFI, ACPI, Prism and Chromium-based apps. For IT pros, the practical takeaways are modest:
- Don't expect a supported way to run Windows on iPhones.
- The reliance on a debugger and TXM-specific behavior suggests Apple could close the approach off, though I found no reporting that it intends to.
- Remote access through Windows App or Remote Desktop remains the supported route for Windows on a phone.
It is a clever, well-documented hack with real engineering behind it. For now it is a curiosity for developers, not a pocket PC for everyone.