Try Omarchy on macOS: an Apple Silicon VM for the Omarchy desktop

What Try Omarchy solves for Apple Silicon users

The upstream Omarchy project is a desktop configuration for Arch Linux, and the usual way to see it is to install Arch on real hardware. That is a commitment: partitioning, a bootloader, driver work, and a machine you may not want to repurpose. Try Omarchy takes the other route. It ships a project-built ARM64 Arch Linux image configured with Omarchy Quattro, a QEMU runtime that uses Apple Hypervisor Framework, and a small Swift/AppKit launcher, all wrapped into one macOS app. The image is built from pinned Arch Linux ARM packages and a pinned revision of the upstream Omarchy source, so what you launch is a fixed combination rather than whatever the mirrors served that morning.

The audience is narrow and specific. You need an Apple Silicon Mac, and you need to want the Omarchy desktop specifically, not Linux in general. The README lists nested KVM virtualization on M3 and newer Apple Silicon running macOS 26 or later, which tells you the project is tracking recent hardware and OS releases rather than supporting a long tail. If you are on an Intel Mac, the ARM64 image and the Hypervisor Framework path are not for you.

How the QEMU and VirGL graphics chain actually works

The guest sees a plain virtio GPU. Nothing in the guest needs an Apple-specific driver, which is the point of the design. Rendering starts in Hyprland, goes through the Mesa virgl driver inside the guest, crosses the VM boundary as a command stream on virtio-gpu-gl-pci, and is replayed on the host by virglrenderer as OpenGL ES. ANGLE then translates that OpenGL ES into Metal. The README gives the full chain and notes that the display is started with gl=es for this reason.

One detail worth knowing, because the naming misleads: the upstream tap this builds from is called homebrew-qemu-virgl-kosmickrisp, but KosmicKrisp, Mesa's Vulkan-to-Metal driver, is not part of the path. The acceleration is real rather than a software rasteriser, and the README supports that by pointing out that libGLESv2.dylib and libEGL.dylib link Metal.framework directly, with the guest reporting the renderer as ANGLE (Apple, ANGLE Metal Renderer: <chip>).

This fork's own work sits elsewhere. It moves the runtime to QEMU 11.1.1 to pick up Apple's in-hypervisor GIC, replacing an emulated GICv2 with GICv3 via Hypervisor.framework. The README's stated reason is that the old path put every guest interrupt through the big QEMU lock, roughly four lock acquisitions per interrupt and five per IPI across two vCPU threads. The README reports idle QEMU cost falling from about 65 percent of a core to about 15 percent, with coreaudiod attributable to the VM dropping from 6.4 percent to 0.3 percent. It also flags that the 15 percent figure was measured on a freshly booted desktop rather than the same session, so the split between the GIC change and the GL dirty-flag fix should be treated as approximate. Under HVF, QEMU 11.1.1 rejects GICv2 outright, so this is now the only supported configuration rather than an optimisation.

Installing Try Omarchy and running your first session

The repository is built from source with a Makefile rather than distributed as a ready binary in the README shown. The default goal is help, so the first command you run is the one that lists everything else. The README does not document a Homebrew cask or a download URL for a prebuilt app.

make doctor

This checks the local toolchain. Run it before anything else, because the guest image is built in Docker and the runtime is built for macOS, and a missing piece will only surface later otherwise.

make build

This builds only the changed guest, runtime and app inputs. `make build FORCE=1` rebuilds every component, which is what you want if you suspect a stale artifact rather than a code problem.

make run

This builds the app from existing artifacts and opens it. If you rebuild often and want macOS privacy grants to survive, the help text gives `make run DEVELOPMENT_SIGN_IDENTITY="Apple Development: ..."` as the way to keep those grants across local rebuilds. Without a stable signing identity, expect to re-grant permissions.

The help text also lists `make guest`, `make runtime` and `make app` for building one component at a time, `make test` for the native and guest contract tests, and `make reset` and `make clean` variants for clearing state. Distribution is separate: `make package` creates a signed and notarized DMG, and the Makefile defaults `RELEASE_SIGN_IDENTITY` to a specific Developer ID Application identity and `RELEASE_NOTARY_PROFILE` to try-omarchy. Those defaults are the maintainer's, so anyone else packaging a build will need to override both.

What the guest integration gives you, and what it does not

The feature list is longer than a typical VM wrapper. The window is resizable with automatic guest resolution and HiDPI scale updates. Mac audio input and output selection happens inside Omarchy with live routing and system-default fallback. Mac cameras, including FaceTime HD, appear to the guest as an on-demand 720p webcam. Clipboard sharing works two ways for text and PNG images. One optional shared Mac folder is available inside Omarchy under the same name, so `~/Work` stays `~/Work`. TCP and UDP port forwarding runs loopback-only from the Mac into Omarchy.

Two of those deserve scrutiny. The camera is on-demand, and the README is explicit that microphone capture defers its initial device open until an Omarchy application actually records, then closes the device when the guest capture stream stops. The stated consequence is that the first recording may take one device open longer to begin. That is a deliberate trade: launching Try Omarchy does not activate the Mac microphone. The loopback-only restriction on port forwarding is the other one. It keeps the guest off your network interfaces, which is the safer default, and it also means you cannot reach a service in the VM from another machine without something else in front of it.

Video playback is CPU-only, and that is the real ceiling

The README states the current limitation plainly: video decoding is CPU-only, so playback can be slow, especially at high resolutions, and an improved video path is in development. The graphics chain explains why. The virtio GPU path carries rendering commands through virglrenderer and ANGLE to Metal, but decoding is not part of that path, so the guest CPU does the work. On a laptop this shows up as fan noise and battery drain during playback long before it shows up as dropped frames.

There is a second category of limitation the README labels Not yet verified: window resize across a HiDPI boundary and Mac output-device switching, among others. Treat those as untested rather than broken, but do not assume they work. The fork's own history also shows how narrow the margin can be. The audio dropout fix came down to the emulated Intel HDA DMA position advancing from a 100 Hz timer, so the counter moves in coarse jumps and ALSA concludes it has missed. The fix was raising the guest's quantum. A deeper SDL buffer made it worse, and raising the QEMU main loop to QOS_CLASS_USER_INTERACTIVE changed nothing, which rules out buffer depth and priority inversion. That is a lot of tuning for a working audio path, and it suggests other timing-sensitive behaviour may need similar attention.

Finally, the maintenance model. The README notes that the upstream render patch source is unmaintained since 2026-01-14, and this fork responded by vendoring the patch tree in macos/patches/ and trimming it from 29 files to 18. The repository's last push was on 2026-09-15, and it is not archived. Anyone adopting this should understand that part of the work is carrying patches the upstream no longer maintains.

How it compares to running Omarchy in a general VM

The obvious alternative is UTM or a hand-rolled QEMU setup with an Arch Linux ARM image. The difference is in what you configure. A general VM gives you a blank machine and expects you to install Arch, then Omarchy, then work out the display, audio, camera and clipboard plumbing. Try Omarchy ships all of that pre-decided: a pinned image, a pinned Omarchy revision, gl=es for the display, and the integration features listed above.

The cost of that convenience is the same thing that makes it convenient. You do not choose the Arch packages or the Omarchy revision; the guest build spec and artifact provenance do, with temporary fixes carried ahead of the next upstream release enumerated with strict hashes. The README's own comparison table shows the fork deliberately diverging from upstream QEMU, GIC and render-patch choices. If your goal is a general-purpose Linux VM on macOS, this is the wrong tool, because it is one desktop image with a specific set of host integrations. If your goal is to see whether the Omarchy desktop suits you, the setup work a general VM demands is exactly the work you are trying to avoid.

The licence is MIT, and the repository ships a THIRD_PARTY_NOTICES.md alongside it. The Omarchy mark in the app icon comes from the official Omarchy brand kit and, as the README notes, remains subject to Omarchy's trademark rights. The MIT licence on this repository does not grant you rights to that mark, and redistributing a build with the icon is a separate question from redistributing the code.

Upgrading and keeping the pinned image current

Upgrades are not automatic. The image is pinned, and the Makefile exposes the command to move it:

make update-omarchy OMARCHY_RELEASE=x.y.z

The help text describes this as pinning an upstream release and refreshing the ARM64 lock. Nothing in the README suggests the app checks for or applies updates on its own, so the release cadence you get is the cadence you rebuild at. Between v0.3.0 on 2026-09-02 and v0.4.1 on 2026-09-15 there were three tagged releases, which is a fast enough pace that a build can fall behind quickly.

The upgrade cost is mostly build time and signing. `make build` is incremental by design and rebuilds only changed inputs, but `make guest` runs the image build in Docker, and `make runtime` covers the QEMU runtime, which is the larger piece. If you rebuild locally without a stable `DEVELOPMENT_SIGN_IDENTITY`, you will re-grant macOS privacy permissions each time. For distribution, `make package` produces a signed and notarized DMG and expects the signing identity and notary profile named in the Makefile, so a fork that packages its own builds must override `PACKAGE_SIGN_IDENTITY` and `PACKAGE_NOTARY_PROFILE`.

Editorial conclusion

Adopt Try Omarchy if you run an Apple Silicon Mac and want to evaluate the Omarchy desktop without repartitioning or dual-booting. Skip it if you need smooth high-resolution video playback, if you are on Intel, or if you want a general-purpose Linux VM rather than one opinionated desktop image. Before relying on it, check the Not yet verified list in the README (window resize across a HiDPI boundary and Mac output-device switching among them), and confirm which Omarchy release your build pins with make update-omarchy.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. omacom/try-omarchy on GitHub
4. README
5. Releases