Quick Answer: Yes, with caveats. Running macOS on Snapdragon works today on one laptop only: the ASUS Zenbook A16 with a Snapdragon X2 Elite. Snapintosh, an open-source EL2 hypervisor, boots macOS 27 to a GPU-accelerated desktop there. Wi-Fi joining from the macOS menu, audio, Bluetooth, sleep and external displays are still missing, and the tools write your internal SSD.
Most people who search to run macOS on Snapdragon expect one of two things: a slow virtual machine, or a demo that boots and then falls over. Snapintosh is neither. It takes the ASUS Zenbook A16 at EL2 and presents the platform contracts a stock macOS 27 kernel expects from Apple silicon. The result is a real desktop running on the laptop's own Adreno GPU. "Boots" and "usable" are still different milestones, though, and the gap between them is where most of the interesting engineering sits.
What the EL2 monitor actually does
The core of the project is an EL2 monitor, a hypervisor-level layer that runs below the kernel. By default it boots Apple's stock kernelcache for the J700/T8140 platform without modifying it. The monitor's job is to impersonate the Apple silicon environment that kernel was built for.
That means handling the SPTM and TXM monitor calls, emulating the Apple devices the kernel probes for (AIC interrupt controller, ANS2 NVMe, DART IOMMUs and others), and translating the kernel's memory layout. That last part is the hard one. The kernel uses 16 KiB page tables, but the hardware on the A16 uses 4 KiB granules. The monitor keeps shadow page tables, 4 KiB hardware tables that mirror each 16 KiB guest table.
Here's the cause-and-effect chain. When the kernel changes one 16 KiB mapping, the monitor has to rewrite the matching 4 KiB shadow entries before the change takes effect. Every mapping change therefore costs translation work, and a bug in that mirroring shows up as a crash somewhere far from the code that caused it.
Most people assume a hypervisor like this is hosting macOS as a guest in the usual sense. That's the lazy mental model, and it's incomplete. Snapintosh is closer to a compatibility layer that makes the laptop look like the machine macOS already expects. If you debug it as a VM, you'll chase the wrong symptoms.
That's the architecture. The more pressing question is what happens when you actually look at the screen.
GPU acceleration: correct isn't the same as smooth
The graphics stack is where the project is most ambitious. It runs on the laptop's Adreno X2-90, through a driver set written for this project:
- AdrenoMetal.bundle is a Metal driver plug-in that macOS apps talk to.
- air2ir3 compiles Apple's AIR, Metal's intermediate representation, into Mesa's ir3 for the Adreno.
- AdrenoX2 is an IOGPU kernel extension, and AdrenoDisplay drives the internal panel.
The project states plainly that there is no software, CPU or paravirtual rendering fallback. That's a strength, because you can't mask a broken GPU path with a slow one. It also means every frame depends on the full chain working.
The current status is split in an instructive way. The pixel checks across the desktop test scenes pass, so rendering is correct. Interaction is usable but not yet smooth. The first target is a steady 60 Hz, and the panel's 120 Hz comes later.
Here's the counterintuitive part: a correct frame can still be a bad experience. If a frame is right but arrives late, the desktop feels sticky even though the screenshot looks perfect. So judge this kind of project by frame pacing and input latency, not by screenshots. A lot of early GPU bring-up reports look successful right up until someone scrolls.
That's the performance picture. The rest of the laptop is a mixed story.
Status: what works today
The project's own status table is the most honest summary available. Here it is, reorganised around what it means for you:
| Area | Current state | What it means for you |
|---|---|---|
| Desktop and GPU | Boots to desktop with acceleration; pixel checks pass | You can evaluate the stack, but not yet rely on it for daily work |
| Smoothness | Usable, not smooth; 60 Hz target first, 120 Hz later | Expect hitches during animation and scrolling |
| Built-in input | Keyboard and touchpad, including gestures, Mission Control and app switching | The most mature part of the user experience |
| Wi-Fi (QCC2072) | Scanning, WPA2, DHCP and ping work via a host-proxy harness | Network testing is possible; menu-based joining is not |
| Storage | macOS installs on and boots from the internal NVMe | Real, but carries the highest data risk |
| Audio, cameras, Bluetooth, sleep, external displays | Not supported | Plan on none of these working |
Notice the pattern. The parts that are visually verifiable are further along than the parts that depend on power management and the wider device set. That's typical of a project at this stage, and it's a reasonable order of work. Still, a laptop without sleep or audio is a bench machine, not a daily driver.
The table also shows where to focus your attention. Input is solid enough to type and navigate. Wi-Fi is the next real blocker. The status page has the full known-issues list, and it's the first document to read before you commit time.
Wi-Fi works in the harness, not the menu
Wi-Fi is the clearest example of a feature that is "working" only in one context. The QCC2072 controller can scan for networks, complete a WPA2 connection, get an address over DHCP and answer a ping. But all of that runs through a host-proxy harness driven from the Mac. Joining a network from the macOS Wi-Fi menu does not work yet.
The lazy reading of that status is "Wi-Fi mostly works." The careful reading is that the proven path goes around the normal macOS network stack, so it tells you the radio and firmware path functions, not that you can use Wi-Fi the way you would on a supported Mac. The source doesn't give a root cause for the menu failure, so don't assume one.
The driver also depends on a board file from ASUS's Windows WLAN package, and the tools check it against a pinned SHA-256. That's a good trust signal: the project won't silently run with a file it can't verify.
Treat Wi-Fi as a lab feature for now. If your goal is a laptop you can take to a café, the menu join gap is the thing to watch.
Storage: the real risk is your SSD
This is the section to read twice. Installing macOS writes the internal NVMe SSD. The installer changes the partition table, and the guest writes its own volumes through the emulated Apple storage controller. A bug doesn't just break macOS. It can corrupt or destroy the Windows installation on the same drive.
The project's guidance is clear, and I'd follow it in this order:
- Back up everything on the laptop before you start, including any Windows data you care about.
- Create Windows recovery media and confirm it boots before you touch the SSD.
- Keep the laptop on AC power. The tools refuse to boot or write the SSD below a battery threshold, and a run that dies mid-write is the worst outcome you can get.
- Use the
--thermal-guardoption on boot cycles, because the monitor programs clocks, voltages and memory-bandwidth votes directly.
Here's where people get caught out. They assume "it boots from NVMe" means "it's safe to experiment on the disk." The boot can succeed, and the partition damage can still show up hours later, when you reboot into Windows and find the table wrong. Treat every installation as a destructive operation until you've proven your recovery path works.
The guard rails are helpful, but the source is explicit that they are not a guarantee. Plan for a failed run, not just a successful one.
What you need before you try it, and who should bother
Snapintosh ships no Apple, Qualcomm or ASUS binaries. You supply them yourself, and the project is useless without them. The requirements are:
- The macOS 27 restore image (IPSW), fetched with
python3 tools/fetch-ipsw.py <url> [destination], then the J700 boot set extracted withpython3 tools/extract-firmware.py <ipsw> j700ap. - The Kernel Debug Kit for build 26A428, installed at
/Library/Developer/KDKs/KDK_27.0_26A428.kdk. - Device firmware: the Adreno GMU and SQE microcode from the linux-firmware project, and the Wi-Fi board file from ASUS.
- A Mac host on macOS 27 connected over USB-C, plus a q1n1 checkout at
../q1n1.
The USB-C link matters more than it looks. q1n1 is a UEFI EL2 proxy forked from Asahi Linux's m1n1, and it brings up a USB NCM network link to the Mac. Every boot, upload and log capture goes over that cable. If the link is flaky, your debugging is flaky too.
Who should follow this? Kernel, driver and GPU developers, and people who want to watch an early platform port mature, will get real value from it. People who need a working laptop this month won't. The project's own warning is blunt: expect panics, hangs and cold reboots, and use it at your own risk. Because the repo depends on Apple software, you're also responsible for complying with Apple's macOS licence terms.
Frequently Asked Questions
what is snapintosh?
Snapintosh is an experimental, open-source EL2 hypervisor and toolchain that boots macOS 27 on the ASUS Zenbook A16 with a Snapdragon X2 Elite X2E-96-100. It runs Apple's stock kernelcache unmodified by default and supplies the SPTM and TXM calls and Apple devices the kernel expects. It's written for that one laptop model only.
how can you run macos on snapdragon?
You need the ASUS Zenbook A16 UX3607OA, a Mac host on macOS 27 connected over USB-C, the macOS 27 IPSW, the KDK for build 26A428 and the device firmware. Build the project following docs/BUILDING.md, then run a boot cycle with tools/cycle.py. Back up the internal SSD first, because the install writes it.
why does wi-fi joining fail on snapintosh?
Scanning, WPA2 connection, DHCP and ping work through a host-proxy harness driven from the Mac. Joining from the macOS Wi-Fi menu does not work yet. The source doesn't give a cause for the menu failure, so use the harness for network testing and don't expect everyday Wi-Fi.
will installing macos erase my windows installation?
It can. Installing macOS changes the partition table on the internal NVMe, and the guest writes its own volumes, so a bug can corrupt the Windows install on the same drive. Back up everything and create Windows recovery media before you start, and keep the laptop on AC power.
Start with the status page, not the install
Running macOS on Snapdragon is real today on one laptop, and the desktop, GPU rendering and built-in input are further along than most ports at this stage. The gaps are smoothness, Wi-Fi menu joining, and the missing audio, sleep and display support. Before you commit an afternoon, read docs/STATUS.md and check its known issues against what you actually need. This week, clone the repository with git clone --recurse-submodules, read the status page, and write down the one feature you'd need to use this daily. Then pass the post to someone wrestling with the same question about running macOS on Snapdragon.