Booting an Android Phone Straight into iOS 16.5
Pick up a Xiaomi POCO X5 Pro 5G: the lock screen, system gestures, and Control Center all behave identically to iOS 16.5. Open Settings > General > About, and the model name reads iPhone X. Yet the phone hasn’t been flashed, nor have its partitions been altered. The entire system boots directly from RAM via fastboot boot. A quick reboot, and it’s back to Android.
This is the work of HackiOS, an open-source project that ported Apple’s open-source XNU kernel (xnu-8796.121.2, corresponding to iOS 16.5) to the Snapdragon platform. It boots an unmodified iOS 16.5 userspace extracted from an official IPSW: launchd, backboardd, and SpringBoard all initialize properly, and apps launch as expected. Open-sourced on October 22, the repository gained 489 stars and 93 forks within twenty-four hours.
What this experiment actually measures is far more compelling than whether iOS can merely be ported: the true barrier between mobile operating systems doesn’t lie in the kernel—it sits squarely in proprietary drivers and firmware.
Figure: iOS home screen running on an Android phone. Source: HackiOS repository
The Kernel Was Always Open Source; The Wall Lies Elsewhere
Apple has publicly published the source code for the XNU kernel since 2000. The macOS and iOS kernels have been readable by anyone under the Apple Public Source License (APSL), which allows modifications and redistribution. In fact, HackiOS’s repository contains zero lines of proprietary Apple code; users extract the userspace themselves from official firmware restore packages, neatly sidestepping distribution issues.
If the barrier between mobile ecosystems were the kernel, someone would have pulled this off twenty years ago. The reason it took so long is straightforward: once the kernel boots, it must talk to the hardware, and hardware communication requires drivers. Drivers for Apple Silicon and proprietary peripherals are closed binaries strictly guarded by Apple—neither visible nor licensed for outside use.
HackiOS worked around this by replacing the entire layer: they wrote an EFI loader from scratch to handle boot orchestration, developed custom drivers to substitute for Apple’s closed binaries, ported UEFI to the device, and built a compatibility layer to run Linux Wi-Fi drivers. Since the Linux community had already developed working Snapdragon drivers, the compatibility layer allows the iOS environment to borrow them. The boot chain is clean: fastboot boot loads a ported UEFI environment (via Project Silicium), UEFI launches the xnuloader EFI application, and control is then passed to the custom kernel.
The kernel can be pulled straight from open source; the drivers have to be rewritten layer by layer. That is how the true thickness of the wall is measured.
Figure: Settings > General page showing the model name as iPhone X. Source: HackiOS repository
What Works, What Doesn’t, and One Telling Detail
The list of working features exceeds expectations: the lock screen, system gestures, Control Center, Settings, and built-in apps all launch. The README’s screenshots showcase the home screen, Clock, Calendar, Music, Wallet, Maps, and Messages. Even App Store tabs render properly—though actual content loading and Apple ID sign-ins fail because the device lacks Apple’s Secure Enclave.
The broken features are even more revealing: cellular connectivity and Bluetooth do not work. As explained earlier, baseband and Bluetooth firmware handshakes sit at the deepest layers of closed-source chains, and compatibility wrappers cannot bypass them. These two features happen to mark the exact boundary between an actual phone and a development board running a nice UI.
There is another fascinating detail: under their kernel, battery charging is completely non-functional—the phone only discharges. USB power delivery management relies on another closed firmware protocol that custom drivers haven’t yet unlocked. A smartphone that drains battery even while plugged in illustrates where the driver gap remains more vividly than any architectural diagram.
Figure: Control Center. Source: HackiOS repository
Camera Support Cleared the Hurdle Too
Many in the comments were particularly curious about camera functionality. In the mobile Linux ecosystem, camera hardware has notoriously been one of the toughest nuts to crack. Yet in the README’s feature matrix, Camera.app lists front and rear cameras, live preview, autofocus, and HEIC photo capture as fully operational—once the GPU display pipeline was conquered, camera support followed suit.
Another group of observers noticed the commit metadata: commits carry Co-Authored-By: Claude Opus 5.5. The README is explicit about the project’s scope: this is a research test bench, not an everyday ROM. Each test session lasts only a specified number of seconds before the kernel resets to a clean state with tidy logs, enabling automated agents to iterate within clear boundaries. The public timeline reflects this workflow: prior to the October 22 release, only demo videos existed without code or build instructions, drawing skepticism over independent verifiability. Once the code dropped, the doubts vanished.
The team behind OOSEX GANG consists of four developers: started by @oodze, joined by @netusd, @wannqn, and @hxfuxyyXD. Four engineers paired with AI coding tools accomplished what once required an entire reverse engineering team.
The Vendor Narrative Wall, Measured to Scale
For years, smartphone vendors have cultivated narratives suggesting iOS and Android are fundamentally alien at their very roots. HackiOS demonstrates the actual reality: swap in the open-source XNU build, extract the userspace from an official restore image, and the system runs. The only real barrier exists in the proprietary driver and firmware tier—and that barrier is built on engineering volume, legal risk, and closed-source licenses, rather than fundamental architecture.
This also explains why the project requires no ROM flashing: the system lives entirely in volatile RAM without altering a single storage partition. It poses zero risk to the user’s hardware and presents no genuine threat to vendor ecosystem lock-in—a phone without cellular data cannot replace anyone’s daily driver, leaving commercial moats untouched. What cracked open was the technological narrative; the business model didn’t lose a single brick.
That is the true significance of HackiOS: it is an extended research workbench, not a consumer product. It makes visible for the first time that the contest between mobile operating systems was never decided at the kernel layer, but in the proprietary drivers and firmware nobody is willing to open. Now, there is only one milestone left to watch: when cellular connectivity comes online. When it does, this POCO phone that only discharges will finally become an iPhone.
Reference Links:
- HackiOS Repository (README, commit logs, and screenshots)
- Hacker News Discussion (item?id=50196718)
