Glonce

HackiOS runs iOS 16.5 on a POCO X5 Pro Android phone and in QEMU

researchThe Glonce editorsHacker News🔥80Glonce rating80Impact55Novelty75Relevance100Surprise80Players15Credibility70
HackiOS runs iOS 16.5 on a POCO X5 Pro Android phone and in QEMU

HackiOS is a GitHub project by OOSEX GANG that boots Apple's open-source XNU kernel (xnu-8796.121.2, the kernel of iOS 16.5) on Android phone hardware and runs the unmodified iOS 16.5 user space on top of it. The boot chain goes launchd, then backboardd, then SpringBoard, then apps. Four pieces make this possible: the team's own EFI loader, its own replacements for Apple's closed drivers, a UEFI port, and a Linux Wi-Fi driver running on a compatibility layer.

It runs in two places. One is the POCO X5 Pro 5G (codename redwood, Snapdragon 778G). Nothing is flashed there: the UEFI is started with fastboot boot, the whole system lives in RAM, and after a reboot the phone is back in Android. The other is QEMU (virt, aarch64), which does the same thing on any Linux computer with no phone needed. The README shows a photograph from the phone of the Adreno GPU drawing. The project calls itself a research bench, not a ROM: a session lasts a set number of seconds, then the kernel returns to the loader and hands over its log.

No Apple files are in either of the two repositories. The script ios165/fetch.sh downloads the iOS 16.5 IPSW (7.4 GB, 5 to 15 minutes) from Apple's own CDN to the user's machine and extracts what is needed there. The README states that HackiOS is an independent research project by OOSEX GANG and is not affiliated with, authorised or endorsed by Apple Inc.

The design, as the README lays it out: the kernel starts from a BCM2837 configuration plus the team's own platform code. It adds GICv3, a timer, a video console and a return path to the loader, with APFS (images in RAM, the iOS volume on flash) and a RAM-based /private/var and /tmp. Stand-ins replace several Apple components: minicrypto instead of corecrypto, AMFI and Sandbox stand-ins as MAC policies, and driver replacements for IOSurface, IOMobileFramebuffer, AppleKeyStore and the network stack. Touch input comes from a Goodix GT9916 on the phone or virtio-input in QEMU. The listed hardware support covers the Adreno 642L GPU, Wi-Fi on the WCN6750 chip (ath11k via LinuxKPI), and sound through the phone's ADSP or virtio-sound in QEMU. The iOS programs, frameworks and dyld shared cache are not changed by a single byte. What they lack is supplied by kernel driver replacements or by libraries the kernel injects with DYLD_INSERT_LIBRARIES. Those libraries go into backboardd, SpringBoard and mediaserverd and provide virtual HID services and a few Objective-C method swaps, in memory only. mediaserverd also gets the project's own CoreAudio output device.

To try it in QEMU, the host needs Linux x86-64, about 12 GB of free disk and 4 GB of free RAM, plus packages including 7-Zip 23 or newer because it must read APFS. The steps are common/setup.sh, ios165/fetch.sh, common/build.sh qemu-virt and common/run.sh qemu-virt, which opens a 20-minute QEMU session. The lock screen appears after two to three minutes, and the system needs another 30 to 40 seconds after SpringBoard appears to register apps. A mouse with the left button held acts as a finger.

On the phone you need a POCO X5 Pro 5G with an unlocked bootloader, adb and fastboot. The phone's vendor firmware for GPU, Wi-Fi, audio and haptics is not in the repository; it is pulled with adb from the same phone's Android. common/run.sh redwood 900 loads the loader and the 2.5 GB system image into RAM (about 80 seconds, once per loader session) and starts a 15-minute session. Each release also carries hackios-redwood-boot.img, the redwood UEFI with the loader inside, ready for fastboot boot, with no Apple files in it.

The repository is licensed under the Apple Public Source License 2.0, because the XNU changes are a derivative of XNU. Third-party code keeps its own licence: ath11k (BSD-3-Clause-Clear), FreeBSD LinuxKPI code (BSD-2-Clause), libzbitmap (MIT) and libdeflate 1.24 (MIT).

Key facts

  • HackiOS boots Apple's open-source XNU kernel (xnu-8796.121.2, the kernel of iOS 16.5) and runs the unmodified iOS 16.5 user space: launchd, backboardd, SpringBoard, apps.
  • It runs on a POCO X5 Pro 5G (Snapdragon 778G) via fastboot boot with nothing flashed and the system in RAM, and in QEMU (virt, aarch64) on Linux.
  • No Apple files are in the repositories; ios165/fetch.sh pulls the 7.4 GB iOS 16.5 IPSW from Apple's CDN to the user's machine.
  • Apple's closed drivers are replaced by the team's own code, including GPU (Adreno 642L), Wi-Fi (ath11k via LinuxKPI) and sound; iOS binaries and the dyld shared cache stay untouched.
  • The project calls itself a research bench, not a ROM, is not affiliated with Apple, and is licensed under APSL 2.0.

Why it matters

Running Apple's iOS user space on non-Apple phone hardware, with the iOS binaries left byte-for-byte unchanged, is the notable claim here. The project builds on the fact that XNU is open source: its own loader, driver replacements and UEFI port fill in what Apple's closed drivers would normally do. The README shows the Adreno GPU drawing on the phone and a boot all the way to SpringBoard and apps.

Who it affects

The audience is people who do low-level systems research: kernel, bootloader and driver developers, and those interested in porting. The README points to common/new-device.sh and docs/PORTING.md for other devices, but the only phone it claims to run on is the POCO X5 Pro 5G. It is not aimed at ordinary phone owners looking for an operating system.

How to use it

In QEMU: on a Linux x86-64 machine with about 12 GB of free disk and 4 GB of free RAM, clone the repository, then run common/setup.sh, ios165/fetch.sh (downloads 7.4 GB, 5 to 15 minutes), common/build.sh qemu-virt and common/run.sh qemu-virt. On the phone: use a POCO X5 Pro 5G with an unlocked bootloader, pull the vendor firmware with adb from that same phone, then run common/build.sh redwood GL=1 and common/run.sh redwood 900. Nothing is written to the phone's storage, and a reboot returns it to Android. The code is under APSL 2.0.

How solid is it

The primary source is the project's own README, which describes the work and includes a photograph from the phone. The claims are the authors' own, and the source gives no benchmarks or performance figures. It also gives no release date and reports no response from Apple.

Risks and caveats

The authors call it a research bench, not a ROM: sessions last a fixed number of seconds (15 minutes on the phone, 20 in QEMU), then the kernel returns to the loader. The source does not say whether the system is usable day to day. The phone route needs an unlocked bootloader, and the phone's own vendor firmware has to be pulled from the device. The project states it is not affiliated with, authorised or endorsed by Apple Inc., and the iOS image has to be downloaded from Apple's CDN by the user.

“It is a research bench, not a ROM: a session lasts a given number of seconds, then the kernel returns to the loader and hands over its log.”

— HackiOS README, OOSEX GANG