ios-sweet: iOS 16 booted on a Redmi Note 10 Pro

A real iPhone X userland on Snapdragon 732G silicon

The premise of ios-sweet is unusual. It is not a launcher, a theme or a jailbreak. The project ports Apple's open source XNU kernel, specifically xnu-8796 which is the iOS 16 generation, to the Xiaomi Redmi Note 10 Pro, a board known as sweet with the Qualcomm SM7150, better known as the Snapdragon 732G. On top of that kernel runs the unmodified iOS 16.7.16 (20H392) userland taken from the iPhone X: launchd, the system daemons, backboardd, SpringBoard and the stock apps. The device presents itself to that software as an iPhone X, iPhone10,3 or D22AP, which is why the gesture user interface appears without a Home button. The state of the project as of 2026-10-18 is that the phone boots to the iOS home screen. You can open the lock screen and then Settings, pull down Control Center and the notification center, and use the touchscreen and the hardware buttons. The documentation is explicit that this is an experimental bring-up and not a usable phone OS.

The boot chain starts from the stock Xiaomi bootloader and flashes nothing

Nothing is written to the boot partitions. The chain begins with the stock Xiaomi bootloader with its signature check bypassed, which loads a shim through fastboot, and the shim sets up its own MMU, reads the live flattened device tree and pulls the payload out of the ramdisk:

ABL (stock Xiaomi bootloader, unlocked)
  -> fastboot boot shim-boot.img              (temporary; nothing is flashed to boot)
     -> shim: own MMU setup, reads the live FDT, loads the payload from the ramdisk
        -> XNU Mach-O + generated Apple Device Tree (ADT) + boot-args
           -> XNU -> UFS driver -> HFS+ root in the userdata partition
              -> dyld + shared cache -> launchd -> daemons -> backboardd + SpringBoard

The Apple Device Tree is generated rather than taken from an iPhone, except for one part, and the details matter later. There is no serial port on this board, since the debug UART is wired as SPI, so the kernel draws its console into the framebuffer the bootloader leaves at 0x9c000000 and keeps a persistent 4 MiB log ring at the end of the userdata partition. You read that log from OrangeFox recovery with tools/sweet-log-pull.sh, which saves you from filming the screen with a camera.

Six Cortex-A55 cores, a hand written UFS driver and a journaled HFS+ root

The hardware support is the part that took the work. The kernel runs on 6 of the 8 cores, the six Cortex-A55s, using PSCI, with 16K pages, GICv3 interrupts and timers. The two Cortex-A76 cores are not used yet. Memory comes from the upper DDR bank, of which about 3.95 GiB is available. Storage is handled by an own UFS host driver, and the iOS root is a journaled HFS+ volume living in the userdata partition, mounted read/write. Writing a UFS host driver and a HFS+ stack that Apple did not publish is the substantial part of the port, and it is why the boot takes about four minutes on the Apple logo. The size of the image is also set by the build: the root image is created with a 16G argument to mkiosroot.sh, which copies the OS volume and both cryptexes into a single case-sensitive journaled HFS+ volume.

Touch, buttons and battery are driven through the vendor peripherals

The input path is the part that makes the phone feel like a phone. The Goodix GT9896 touchscreen is read over I2C through the GENI controller, its rail is enabled through RPMh, and the events are delivered to iOS as HID digitizer events, which the documentation rates as good. Power and volume buttons are handled by the PMIC over SPMI and surfaced as HID consumer keys, with lock and wake working. Battery information comes from an IOPMPowerSource service, and here the documentation is candid: the reading is a static 100 percent with a charging icon, while a real fuel gauge readout is described as prepared but not in place. Activation follows the native Hactivation path of mobileactivationd, selected through the device tree security status, and no Apple servers are involved.

Rendering is software only, and the frame rate shows it

There is no GPU driver. The display path uses kernel IOSurface and IOMobileFramebuffer services under the name AppleCLCD, CoreAnimation renders in software, and frames are copied into the framebuffer the bootloader left behind. To iOS the panel is presented as an iPhone X display at 1125 by 2436 pixels. The result runs at roughly 20 to 30 frames per second, everything drawn by the CPU. That is the single biggest quality-of-life difference between this build and a real device, and no amount of configuration changes it. The absence of a GPU also constrains what can be attempted next, since the two unused Cortex-A76 cores are idle for the same reason: there is no driver to feed them.

Building the kernel on GitHub runners and the root image on Linux

The build path is documented in enough detail to reproduce. You need the phone with a bootloader that accepts fastboot commands, a Linux PC and a GitHub account. The kernel builds on GitHub's macOS runners using blacktop/darwin-xnu-build, and the workflow fetches xnu-8796, applies the patches in xnu/patches/ in order, and stages the pinned libpthread, HFS and BearSSL sources. You fork the repository and trigger it:

gh workflow run xnu.yml -R YOU/ios-sweet
gh run download RUN_ID -R YOU/ios-sweet -n xnu-kernel -D xnu/out

To check a patch before spending a CI run, tools/xnu-cc.py replays the compile commands from a previous CI log for single files. The root image is built on Linux with apfs-fuse, hfsprogs and sudo:

tools/mkiosroot.sh OS.dmg SystemOS.dmg AppOS.dmg ios16-root.img 16G
sudo fsck.hfsplus -fy ios16-root.img
sudo mount -t hfsplus -o loop,force ios16-root.img /mnt/iosroot
sudo python3 tools/sweet-root-tweaks.py /mnt/iosroot
sudo umount /mnt/iosroot
img2simg ios16-root.img ios16-root.simg

The tweaks script is where the bring-up compromises live. It skips Setup, seeds the activation state, removes the baseband daemon, and disables the watchdogs that kill slow applications and the crash-looping media paths. The device tree builder copies the /product directory from the real iPhone X device tree, which MobileGestalt needs, and the extraction is done without downloading the whole IPSW:

python3 tools/remotezip.py IPSW_URL DeviceTree.d22ap.im4p research/ipsw-x/dt
ipsw img4 im4p extract research/ipsw-x/dt/Firmware/all_flash/DeviceTree.d22ap.im4p -o research/ipsw-x/d22ap.adt

The boot image stage needs aarch64-linux-gnu-gcc and mkbootimg, and tools/mkadt.py and tools/mkpayload.py produce the device tree and the payload from it.

What is missing, and what the project warns you about

The list of what does not work is long and specific. Navigation is absent, so you cannot leave an app: the home gesture and AssistiveTouch Home do nothing. There is no Wi-Fi, Bluetooth, cellular, audio, camera, sensor, GPS or SEP and Face ID support, and the daemons for those start and then fail or keep relaunching. The image has only what is on the system volume, with no App Store, no Apple ID, and some Settings pages empty. Security is switched off: code signing through AMFI is permissive, sandbox policies are permissive, the AppleKeyStore is a stub and there is no data protection, which is why the documentation says not to put anything personal on the device. The install writes into the userdata partition and erases Android user data, and the mitigation is to back up first: pull persist, modemst1, modemst2, fsg, fsc, boot, dtbo and vbmeta from a recovery with adb root, because they hold per-device calibration data, and keep them out of git, which .gitignore already handles for backup/, dtb/ and recovery/. Bootloaders, recovery, modem and persist partitions are never touched by the project. The repository has no GitHub releases, the licence is not identified in the repository metadata, and the last push was on 2026-10-19.

Editorial conclusion

ios-sweet is worth studying if you are interested in how far a real iOS userland can be carried on non-Apple hardware, and it is the wrong project for daily use, since you cannot leave an app, there is no Wi-Fi or cellular radio, and code signing and sandboxing are permissive by design. Before you try it, read the backup step, because the install writes into the userdata partition and erases Android user data. If your goal is a usable phone, the hardware in this repository will not deliver one today, and the licence is not identified in the repository metadata.

Frequently asked questions

Official sources

1. dipa-studio/ios-sweet on GitHub
2. Issues
3. Project website
4. README