Quick Answer: You can run iOS on Android with HackiOS, a research project that boots Apple's open-source XNU kernel (xnu-8796.121.2, the kernel of iOS 16.5) and the unmodified iOS 16.5 user space on a POCO X5 Pro 5G or in QEMU on a Linux PC. Nothing is flashed to the phone. The whole system lives in RAM, and a reboot returns you to Android.
Most people assume running iOS on a phone means flashing it, rebuilding a kernel, or waiting for a vendor to ship support. HackiOS skips all three. It starts a custom loader from your Android phone's bootloader, loads Apple's kernel into memory, and hands control to the same user space an iPhone runs. The result is rough around the edges, but it's real, and you can test it on a laptop before you touch a phone.
What HackiOS Actually Boots
The project sits on a chain of components, each replacing or wrapping a piece of the stock stack. XNU is Apple's hybrid kernel, and Apple publishes its source through the Apple open-source releases. HackiOS builds from that published source, applies its own patches, and runs it on hardware Apple never shipped it on.
The boot chain looks like this:
fastboot bootloads a UEFI firmware image, a Mu-Silicium port of the Project Silicium work.- The EFI loader (
xnuloader) starts as an EFI application. It doesn't use EDK2, and it stays resident so it can keep a USB link open for control. - The loader hands the patched XNU kernel the device description it needs.
- The kernel starts
launchd, which brings upbackboardd, then SpringBoard, then apps.
Apple's closed drivers are the hard part. HackiOS ships its own replacements for them, plus a Linux Wi-Fi driver (ath11k) running behind a compatibility layer. That's why Wi-Fi works on the phone while Bluetooth and cellular don't yet. Here's the detail most write-ups miss: the kernel isn't a fork you have to compile before you can try anything. The repository ships a prebuilt kernel, loader, and UEFI image, so the only large piece you generate yourself is the system image.
Why the Phone Beats the Emulator on Boot Time
Here's the counter-intuitive part. You'd expect an emulator to be the slow option, and you'd expect the phone to be the one that needs patience. The numbers say the opposite. On the POCO X5 Pro, the project reports roughly 20 seconds to the lock screen. In QEMU's virt machine, the lock screen appears after 2–3 minutes.
The cause is hardware. QEMU runs an aarch64 guest on an x86-64 host, and unless you're on a matching host with hardware acceleration, every guest instruction is translated in software. The phone runs the kernel on its own Snapdragon 778G cores, with the big core at 2.4 GHz. The Adreno 642L GPU work is also a different story: on the phone it goes through Mesa's freedreno driver, while the emulator has no equivalent path for that GPU.
Don't read this as "QEMU is useless." It's the best place to find out whether your build works, because you can wipe and retry without touching a device. Treat the phone as the place where the system actually feels like a phone.
QEMU or Phone: Choosing Your Path
The two targets have very different requirements, and the choice mostly comes down to what hardware you own and how much risk you're willing to accept on your daily driver.
| Factor | QEMU (qemu-virt) | POCO X5 Pro 5G (redwood) |
|---|---|---|
| Hardware needed | Any Linux x86-64 PC, ~12 GB free disk, 4 GB free RAM | POCO X5 Pro 5G with unlocked bootloader, adb, fastboot |
| Time to lock screen | 2–3 minutes | About 20 seconds |
| Storage writes | Work happens in disk images on your PC | Nothing written to phone storage; system image loaded into 2.5 GB of RAM |
| Session model | Example: a 20-minute session in a QEMU window | Example: run.sh redwood 900, a 15-minute session |
| Wi-Fi and sound | Not covered in the README | Wi-Fi (WCN6750, 55–90 Mbit/s), speakers, main microphone |
The phone path asks more of you. You have to pull vendor firmware from your own device, and a bootloader unlock on a Xiaomi-family phone usually wipes user data. Back up first, and check the unlock process for your region before you start. The QEMU path asks almost nothing of your hardware beyond disk space and memory, which makes it the sensible first step.
Running It in QEMU Step by Step
Start with the emulator. The steps below come straight from the project's quick start, and they're the shortest route to a working lock screen on Arch or Debian/Ubuntu.
- Install the packages. On Arch, that's
git python 7zip lz4 gcc qemu-system-aarch64 qemu-ui-gtk edk2-aarch64. Note that 7-Zip must be version 23 or newer, because it reads APFS. - Clone the repository and run
common/setup.shto bring inhackios-xnu-userlandand check your host. - Run
ios165/fetch.sh. It downloads 7.4 GB from Apple's CDN to your machine and extracts only what's needed. Plan for 5–15 minutes. - Build the images with
common/build.sh qemu-virt, then start the session withcommon/run.sh qemu-virt.
Once the window opens, expect 2–3 minutes before the lock screen. Right after SpringBoard appears, give the system another 30–40 seconds, because it's still registering apps. On Debian and Ubuntu, you'll need to point QEMU at the AAVMF firmware with QEMU_EFI and QEMU_VARS. If you want a more detailed walkthrough of the image build, see our QEMU virt setup guide.
Input works like this. Hold the left mouse button to act as a finger. Swipe up from the bottom edge to unlock or leave an app, and swipe from the left edge to go back. The H key goes home, L locks, and the arrow keys adjust volume. For scripting, qemu/touch.py handles swipes and taps, and qemu/screendump.sh grabs a screenshot.
What Works, What Breaks, and Why
The honest answer is that HackiOS works well for the parts of iOS that run on the kernel and its drivers, and poorly for everything that depends on Apple's account and security infrastructure.
What works:
- Lock screen, home screen with two pages of icons, and system gestures
- Settings, Photos, Notes, Safari, and Camera.app, with front and rear cameras
- Wi-Fi join from Settings, and Safari over Wi-Fi
- Sound from the speakers and main microphone
- Data that iOS writes survives a reboot when you enable the
var_store=1 ufs_write=1options - Sileo and Procursus, which give you dpkg, apt, tweaks, and SSH
What doesn't work yet:
- Charging under the custom kernel. The phone only discharges.
- Cellular and Bluetooth
- App Store content and Apple ID sign-in. There's no Secure Enclave, and the FairPlay daemon exits.
- Video and Live Photo recording
Here's where it gets interesting for anyone planning a longer session. The bench model is deliberate. A session lasts a set number of seconds, after which the kernel returns to the loader and hands over its log. That's a feature for research, because every run ends in a known state, but it means you're not daily-driving this. Think of it as an instrument, not a ROM.
Metal support is further along than you might expect but still incomplete. The project reports that 293 of 456 system shaders already run on the Adreno GPU. That's real progress, and it also means a large fraction of the graphics path still isn't done.
Firmware and Legal Boundaries
Legal and firmware questions come up quickly, so here's the actual setup. Neither repository contains Apple files. The fetch.sh script downloads the iOS 16.5 IPSW from Apple's own CDN to your machine and extracts only the pieces it needs, so you're handling Apple's software the same way you would for any other restore.
The phone's own firmware follows the same logic. It isn't in the repository and can't be, because it belongs to the vendor. You pull it from the phone itself with adb pull from paths such as /vendor/firmware/ and /vendor/firmware_mnt/image/. The project's userland/build.sh prints which firmware files it used, which helps you audit the build.
HackiOS is an independent research project by OOSEX GANG. It isn't affiliated with, authorised, or endorsed by Apple Inc. iOS, iPhone, and Apple are trademarks of Apple Inc. Treat the project as research code with known limits, and don't rely on it for anything you can't afford to lose.
Frequently Asked Questions
What is HackiOS and how does it run iOS on Android?
HackiOS is a research project that boots Apple's open-source XNU kernel and the unmodified iOS 16.5 user space on a POCO X5 Pro 5G. A custom EFI loader is started with fastboot boot, and the whole system runs from RAM. Nothing is flashed, and a reboot returns the phone to Android.
How do I run iOS in QEMU without a phone?
Install QEMU and EDK2 firmware on a Linux x86-64 PC, clone the repository, and run ios165/fetch.sh to download the iOS 16.5 IPSW from Apple's CDN. Then run common/build.sh qemu-virt and common/run.sh qemu-virt. Expect the lock screen after 2–3 minutes.
Why does the phone only discharge instead of charging?
Charging isn't supported under HackiOS's custom kernel yet, so the battery drains while the system runs. The project lists it among the features that don't work yet, and the reason is that the charging path depends on drivers the project hasn't finished replacing.
Does running iOS on Android require flashing the phone?
No. The phone is started with fastboot boot, and the system image loads into RAM. The phone's storage stays untouched, though unlocking the bootloader can wipe user data, so back up first.
Run iOS on Android is an achievable goal for a patient researcher, but it's a bench, not a replacement phone. Start with QEMU, get the lock screen working, and note how long each step takes before you touch the POCO. Then try the phone path with a session timer and a backup in place. Read our guide to building an iOS 16.5 system image next, or check out porting HackiOS to another Android device if your phone isn't a POCO X5 Pro.