Apple Silicon Macs get Omarchy without dual booting
The 1.1 MB checkout puts the upstream Omarchy desktop inside an ARM64 Arch Linux virtual machine and wraps it in a small Swift/AppKit launcher. On an Apple Silicon Mac, the result opens like an ordinary application and leaves macOS in place. QEMU uses Apple's Hypervisor Framework for virtualization and VirGL for graphics. The repository pins both the Arch packages and the Omarchy revision, which makes the guest less of a moving target than a hand-built VM.
The audience is narrow by design. You need an Apple Silicon Mac, macOS 15 or newer, and at least 8 GB of free space for the initial app path. Intel Macs and other host operating systems are outside the stated requirements. This is also an independent project, not an official Basecamp distribution, so questions about the wrapper and guest image belong with this repository rather than the upstream Omarchy team.
Its 123 files add clipboard, audio, and one shared folder
The 123-file repository includes the integration work that makes this easier than a generic Linux image. Text and PNG images cross the clipboard in both directions after the user signs in. The window responds to resolution and HiDPI changes, and Omarchy can select Mac audio inputs and outputs with a system-default fallback. Accessibility permission maps the Mac Command key to the guest's Super shortcuts, while microphone permission remains optional.
Folder sharing is deliberately limited to 1 chosen Mac folder. It appears under the same name in the Omarchy home directory and gives Linux software full read and write access. The app refuses the whole home folder, ~/Library, and system directories, which reduces the chance of exporting too much. That boundary still deserves attention: selecting a work folder means programs inside the guest can modify its contents.
What happened when we ran it
Our sandbox installed the Python side in 32 seconds, pulling 35 packages and occupying 37 MB. The build completed successfully in 3 seconds. Pip-audit reported 0 known vulnerabilities in that installed dependency set. The checkout at commit 509dd27 contained 123 files, about 20,752 lines of source, one CI workflow, and a tests directory, but no Dockerfile.
The test command exited with failure after 11 seconds. Pytest counted 29 passes and 1 failure out of 30. The failing update test called collect_owned_paths, which raised a ValueError because a generated __pycache__ file had entered native-overlay/usr/local/bin. That log tells us what the preparer rejected; it does not establish why the cache file was present, so blaming Debian, Python 3.12, or the project would go beyond the evidence.
Our measurement setup used a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. It does not reproduce the supported macOS runtime, launch the graphical guest, or measure QEMU graphics and audio. The successful build is encouraging, while the single failing test means commit 509dd27 did not pass its complete suite in our stated environment.
The DMG is simple, while a source build needs about 20 GB
A normal user downloads the signed and notarized v0.1.0 DMG, drags the app into Applications, and follows Omarchy's account provisioning. The first launch takes longer because the app prepares Linux. Storage lives under the user's Library rather than inside the application, so replacing or deleting the app does not erase the persistent VM. That behavior is useful, but it may surprise someone trying to reclaim disk space.
Contributors face a different setup. The README calls for Xcode command-line tools with Swift 6, Python 3, Homebrew, a Docker-compatible engine capable of privileged linux/arm64 containers, and pinned native libraries. It recommends roughly 20 GB for the guest, runtime, caches, and output. A first build downloads sources, assembles a multi-gigabyte guest, and compiles QEMU. Our 3-second sandbox build should not be read as the duration of that full Mac build.
The v0.1.0 updater protects the old VM before activation
The v0.1.0 update design works against a protected clone, verifies signed offline packages and migration data, boots a candidate through a health check, and activates it only after success. An interrupted update leaves the previous VM available. Factory reset is reserved for storage that cannot be migrated cleanly.
The development cleanup commands draw a firm line. make clean removes repository output, caches, and project-owned Docker resources without touching the persistent VM. make clean-all also deletes that VM and app state, and it requires an interactive terminal plus the exact confirmation text. Anyone scripting cleanup should preserve that distinction, because the persistent disk is where the user's configured Omarchy environment lives.
CPU-only video and missing nested virtualization limit daily use
The v0.1.0 README states that video decoding is CPU-only, particularly hurting high-resolution playback. It says an improved path is in development, which is narrower than a shipped feature. Issue 5 documents jagged inner clipping around rounded guest windows. Issue 18 reports failed Chrome installation, an ignored default-browser change, and confusion around Tailscale state. Those reports are specific enough to test before making this a primary desktop.
Nested workloads are another gap. Issue 7 asks for nested virtualization because /dev/kvm is unavailable inside the guest. Developers hoping to run KVM-dependent sandboxes within Omarchy should assume that workflow does not work today. The repository was pushed on August 26, 2026, one day after its first release, and GitHub showed 526 stars plus 6 open issues and pull requests. Activity is current, but the young release history still argues for a trial before moving important work into the VM.