Snapintosh: macOS 27 Boots on a Snapdragon X2 Laptop With Its Own Adreno Metal Driver

By Indie Kings | October 22, 2026

Updated October 22, 2026: Snapintosh is a hypervisor that boots Apple's stock macOS 27 on an ASUS Zenbook A16 with a Snapdragon X2 Elite, and its own Adreno GPU driver renders the desktop through Metal. The repository was created at 01:40 UTC today and had 314 stars by 07:51 ET, with a critical security fix already open as a pull request.

Image: Snapintosh project artwork, ASCII hands reaching toward a red chip. Credit: Acelogic/Snapintosh.

What Snapintosh actually is

Per the README, Snapintosh boots Apple's macOS 27, build 26A428, on an ASUS Zenbook A16 laptop with a Qualcomm Snapdragon X2 Elite, specifically the X2E-96-100. It is an EL2 monitor, which is to say a hypervisor, and the toolchain around it.

The mechanism is worth stating plainly because it is the part that distinguishes this from emulation. The monitor runs Apple's stock kernelcache, the J700 and T8140 kernel, unmodified by default. It does not translate the operating system or the CPU. What it supplies is the platform contracts that the kernel expects from Apple silicon: the SPTM and TXM monitor calls, translation of the kernel's 16 KiB page tables, and the Apple devices the kernel looks for.

That device list is long and specific. SPTM owns the page tables and page types on Apple silicon, and TXM owns address-space and trust bookkeeping. The X2 Elite has neither, and it has no Apple devices either, so the monitor implements the call endpoints the 26A428 kernel uses, covering page retyping, mapping, unmapping, nesting, region updates, and address-space creation and destruction, along with DART mappings.

The page-table problem is the sharpest piece of the design. XNU writes page tables at a 16 KiB granule, while the X2 Elite's cores support 4 KiB and 64 KiB and not 16 KiB. The shadow directory walks the guest's tables and maintains 4 KiB shadow tables that the hardware actually uses.

Booting is a chain. The A16's UEFI firmware hands over to q1n1, a UEFI EL2 proxy forked from Asahi Linux's m1n1, which keeps the CPU at EL2 and brings up a USB network interface to a Mac. The Snapintosh monitor then runs at EL2, the stock XNU kernel runs at EL1 with an auxiliary kernel collection, and macOS userspace runs at EL0 with WindowServer and the Metal plug-in. The architecture document draws it as a single line: A16 UEFI, then q1n1, then the Snapintosh monitor, then XNU plus AuxKC, then userspace.

The repository in numbers

This is a very young project, and the numbers reflect that. The repository was created at 01:40 UTC on 22 October 2026, and its first commit is titled Snapintosh public release. That commit carries an author timestamp of 01:26 UTC, which is 14 minutes before the repository itself existed, so it is a clock skew on the commit rather than a public release time.

That is a lot of work to land in a day. The GitHub language breakdown puts Python first at 8,135,528 bytes and C second at 7,904,317 bytes, with Objective-C at 1,199,646 bytes, C++ at 1,122,373 bytes, assembly at 112,275 bytes and Swift at 31,547 bytes. The tree splits into the GPU stack at 1,724 entries, the tools at 1,044, the monitor at 169, the drivers at 114, the probes at 66, the shadow page-table walker at 26 and the documentation at 20.

The commit log reads like a release rather than a development history, because it is one. After the initial public commit come a rules file for coding agents, a README banner, ASCII artwork, a document defining coding-agent contribution standards, and two refactors that pull the DVFS governor glue and the ID register forging out of the boot loader. Three of the commits are merged pull requests from a second account, Cam396, and the newest commit is a direct change to display scanout alignment.

That second account is also the source of the repository's most important open item, which is covered below.

The part nobody else has written: an Adreno Metal driver

Asahi Linux brought macOS to Apple silicon. This project is doing the opposite, bringing macOS to a Qualcomm chip, and the obstacle that makes it hard is the graphics stack rather than the kernel.

The README says graphics run on the laptop's own Adreno X2-90 GPU through a driver stack written for this project, and that there is no software, CPU or paravirtual rendering path. Three pieces make it work.

• AdrenoMetal.bundle, a Metal driver plug-in that IOGPU loads for the AdrenoX2 accelerator, implementing the device, resource, render, blit and compute encoders and pipelines, and encoding Adreno a8xx command streams.
• AdrenoX2, an IOGPU kernel extension for the accelerator, which stages and relocates each indirect buffer, validates it against the resource list, maps the memory into the GPU's address space, cleans the CPU caches only for the bytes the GPU will touch, and asks the monitor to run it. AdrenoDisplay, an IOMobileFramebuffer driver, drives the internal panel.
• air2ir3, a shader compiler that translates Apple's AIR, which is Metal's LLVM-based intermediate representation, into Mesa's ir3 for the Adreno.

air2ir3 is the piece that has no precedent. Its README describes a four-stage pipeline: parsing the AIR module with LLVM, specialising function constants and evaluating the static initialiser that decides which arguments are present, then lowering pixel formats the Adreno render back end cannot store, then running Mesa's NIR passes and the ir3 back end for a8xx, and finally emitting a JSON sidecar describing the variant that the command stream needs besides the code.

Two details in that document set the project's tone. The compiler refuses, with an explicit unsupported error message, anything it cannot reproduce exactly, and there is no silent fallback. And the current interface versions are published as binding ABI 6, cache format 5 and C API 2, which is the kind of versioning discipline you normally see in a project that has been running for years.

The size of the effort shows in the tree. The air2ir3 directory alone holds 1,578 files, and most of them are test scenes: 834 xr5scenes, 281 xrscenes and 262 vscenes, with 33 more in a plain scenes directory and 97 under tests. Those are shader fixtures, and having 1,377 of them in the three largest scene sets is what a compiler that refuses to guess looks like.

The display path is described in similar detail. The internal 2880x1800 panel runs at 60 Hz, and with the present-beam option the presentation is locked to the panel's vertical blank so it is tear-free. The GPU gets a 15 GiB address window through a flag that widens it from 3 GiB, asynchronous indirect buffer execution, pipelined WindowServer submissions so the CPU work for the next frame overlaps the GPU work for the current one, and recovery after an overrunning buffer. Sessions have run at a 1185 MHz ceiling with no GPU errors, below 72 degrees Celsius.

The stock kernel and the five patches it allows

The kernel is Apple's stock J700 and T8140 kernelcache from the 26A428 restore image, and by default it is not modified at all. A separate document sets out the rules for the handful of patches that do exist, and the rules are strict enough to be worth quoting.

Per that document the goal is to run stock kernels unmodified wherever possible. A trap cost is fixed in the monitor first, and a kernel patch is considered only when the trap is hot enough to matter in the trap census and the monitor cannot make it cheap on its own. Patch sites are found by decoding instructions, anchored on symbols, strings or operands, and never by fixed address. A patch is opt-in, so without its flag the loaded image, page tables and parameters are byte-identical to a build without the patch code. A patch is admitted only for the reviewed kernel, meaning the image digest must match a pinned value, every site must still hold its stock instruction, and the decoded site list must hash to a reviewed closure value. Its effect is then measured against the stock kernel under the same monitor. The kernelcache file on disk is never rewritten, because each patch rewrites words in the loader's in-memory copy, and every patch flag must be given to every mode of a boot attempt so the checked image is the booted image.

The measured effect on the SPTM call path is the number worth keeping. Trapping a monitor call into an undefined instruction and then vectoring it costs 13% of the call, and on a workload that leans on the monitor that is not a rounding error.

What it does not do

The status document is unusually blunt about the remaining work, and its known issues are the honest measure of where this stands.

• Smoothness is in progress. Interaction is usable but not yet smooth, with recent sessions showing a median of about 46 to 60 presents per second in busy periods and 1.7% to 5% of frame intervals longer than 34 ms. The causes listed are present-gate deferrals where WindowServer swaps a surface whose GPU work is still running, occasional stalls of 100 to 350 ms that coincide with heavy console output, and contention on the monitor's global lock for some SPTM calls.
• The CPU governor's requests above a certain performance level are not granted by the firmware, so the clusters do not reach their top clocks.
• The System Settings Displays pane redraws badly, and icons inside some Settings panes are missing.
• The native QCC2072 Wi-Fi controller loads in the guest, but the macOS Wi-Fi menu cannot join a network. Scanning, a WPA2 connection, DHCP and ping all work through a host-proxy harness driven from the Mac.
• A single 4 MiB copy operation hung the GPU once. The plug-in now splits blits into chunks of at most 1 MiB, and GPU recovery handles other overruns.
• Audio, cameras, Bluetooth, sleep and wake, external displays and the panel's 120 Hz mode are not supported, and no other machine or macOS build works.
• A host is required. Every boot is driven from a Mac over USB-C through q1n1, and there is no standalone boot path.

The roadmap is six items in a rough order, starting with frame pacing to a steady 60 Hz through event-driven GPU completion rather than a polling timer, then the Settings and display modes, then moving the remaining hot SPTM endpoints off the global lock and finding out why the CPU performance requests are capped, then Wi-Fi from the macOS menu, then higher GPU clocks, and finally the panel's native 120 Hz.

The legal and the destructive warnings

Two warnings in the README need to be reproduced rather than paraphrased, because both carry real consequences.

The first is legal. The project states that running macOS on non-Apple hardware may conflict with Apple's macOS software licence agreement, and that the user is responsible for making sure their use complies with the licences that apply. It ships no Apple, Qualcomm or ASUS binaries or firmware at all. The user supplies the macOS 27 restore image, the Kernel Debug Kit, the Adreno GPU's GMU and SQE microcode, the QCC2072 Wi-Fi firmware and the Wi-Fi board file, and the tools check each file against a pinned SHA-256. The microcode and the Wi-Fi firmware come from the linux-firmware project, while the board file comes from the ASUS Windows WLAN driver package for this model. The project is independent, and not affiliated with, endorsed by or sponsored by Apple, Qualcomm, ASUS or Asahi Linux.

The second is about hardware. The README describes Snapintosh as an experimental hypervisor that runs with full control of the machine, and it writes to the internal NVMe SSD. Installing macOS changes the partition table, and the guest writes its own volumes, so a bug can corrupt or destroy data on the SSD, including the Windows installation. The README says to back up everything and keep a way to restore Windows. It also programs clocks, voltages, the GPU and memory-bandwidth votes directly, and while the tools refuse to run on a low battery and stop the run when the SoC gets too hot, it says plainly that those guards are not a guarantee. The verdict in the README is that this is not a supported or stable way to run macOS, and that panics, hangs and cold reboots should be expected.

On the licensing of the code itself, the project's own code is MIT, generated Mesa register tables keep Mesa's MIT notice, and the QEMU tracer patch is GPL-2.0-or-later. The credits section names the work it builds on: Asahi Linux and m1n1, Mesa and freedreno, the Linux driver authors whose code was read as a hardware reference, jprx for the QEMU and Darwin tools used to observe Apple's real SPTM and TXM as ground truth, and XNU sources from Apple Open Source.

One open pull request deserves specific mention, because it is the kind of thing a new hypervisor needs and rarely gets. Pull request 7 is titled as a fix for an arbitrary host memory write, an SPTM fine-lock bypass and a hypervisor privilege escalation, and its body describes a phased audit across the monitor, the SPTM memory management, the GPU command pipeline and the HID input drivers. It reports an arbitrary host memory write in the page-map path where intermediate table descriptors during kernel walks and target leaf slots were unvalidated, an exception frame buffer overflow on secondary CPUs, a multi-byte MMIO overflow, and a fine-lock fast-path sibling bypass that could let a guest walk read or corrupt EL2 memory. It is open and unmerged as of this check, and this is a project where that is expected, since the code went public hours ago.

FAQ

Does Snapintosh emulate macOS or run it?
It runs it. The README says the monitor runs Apple's stock kernelcache, the J700 and T8140 kernel, unmodified by default. The CPU is not translated, because the Snapdragon X2 Elite is already ARM64 like Apple silicon. What the monitor supplies is the platform layer the kernel expects, namely the SPTM and TXM monitor calls, the page-table translation and the Apple devices.

Which hardware does it support?
One machine. The README says the ASUS Zenbook A16 with the Snapdragon X2 Elite X2E-96-100, model UX3607OA, and that nothing else is supported, because the monitor, device tables, clocks and register addresses are specific to it. A Mac host running macOS 27 connected over USB-C is also required.

How does it get graphics working without a Metal driver for Adreno?
By writing one. AdrenoMetal.bundle is a Metal plug-in that encodes Adreno a8xx command streams, AdrenoX2 is the IOGPU kernel extension that validates and submits them, and air2ir3 translates Apple's AIR shaders into Mesa's ir3. The README says there is no software, CPU or paravirtual rendering path.

Is the macOS kernel modified?
Not by default. It is Apple's stock J700 kernelcache from the 26A428 image. Five opt-in patches exist for hot traps the monitor cannot make cheap, and the patch document requires that patch sites be found by decoding instructions rather than by fixed address, that a patch be admitted only for a kernel whose digest matches a pinned value, and that the file on disk never be rewritten.

What happens if it goes wrong?
The README is explicit that it writes to the internal NVMe SSD, that installing macOS changes the partition table, and that a bug can corrupt or destroy data including the Windows installation. It programs clocks, voltages and memory bandwidth votes directly, and expects panics, hangs and cold reboots.

Is it legal to run macOS on it?
The project says it may conflict with Apple's macOS software licence agreement and that the user is responsible for compliance. It ships no Apple, Qualcomm or ASUS binaries, and the user supplies the restore image, the Kernel Debug Kit and the device firmware themselves.

Bottom Line

Snapintosh does the thing Asahi Linux did in the other direction, and does it with a stock Apple kernel rather than a translated one. The monitor supplies the SPTM and TXM contracts, shadows the kernel's 16 KiB page tables down to 4 KiB, and hands the guest a set of Apple devices the X2 Elite does not have. The genuinely hard part is the graphics, and the answer is a from-scratch Metal plug-in for Adreno plus a kernel extension plus a shader compiler that translates Apple's AIR into Mesa's ir3, with 1,377 shader test scenes backing a compiler that refuses to guess. The desktop renders, the panel is tear-free, and the gap between this and usable is honestly stated as frame pacing, missing Wi-Fi, absent audio and a machine that will not take a 4 MiB copy. The legal footing is explicit and the hardware warning is severe, and the repository already has the kind of security audit that most projects of this age never get, with an open pull request describing an arbitrary host memory write and a privilege escalation in the monitor. It was created about ten hours ago. That is what a credible first day looks like.

Sources

• Acelogic/Snapintosh repository README, docs/STATUS.md, docs/ARCHITECTURE.md, docs/KERNEL-PATCHES.md and gpu/air2ir3/README.md, accessed October 22, 2026
• Repository metadata, language breakdown, tree, commit list, contributor list, open pull requests and open issues via the GitHub API, accessed October 22, 2026
• Commit feed for the default branch, accessed October 22, 2026

Related: Qualcomm Linux on Snapdragon X2 Early Developer Preview Targets November | Why Windows on ARM Can’t Match Apple Silicon’s Success | Asus Zenbook Duo 2026 Review