Kakehashi Runs macOS Binaries on Linux ARM, Wine-Style

A Show HN project called Kakehashi is doing something that sounds impossible until you think about it for thirty seconds: it runs macOS binaries directly on Linux ARM machines. No virtual machine, no instruction emulation, no kernel module. Load the Mach-O, map a stand-in libSystem, translate BSD syscalls to Linux ones at the boundary, and let the CPU execute the code natively.

The thirty seconds of thinking is what makes it plausible. For two decades, "run macOS software on Linux" meant either full virtualization of macOS (slow, legally fraught, hardware-picky) or Darling-style API reimplementation on x86. Apple Silicon quietly changed the math. A Darwin arm64 binary and a Linux aarch64 binary now target the same instruction set; the only real differences are the executable format, the syscall ABI, and the userspace libraries underneath. That's not an emulation problem anymore. That's a Wine problem — and Wine problems, while brutal, are tractable.

What it actually does today

Kakehashi is written from scratch in Rust and split into a CLI, a Mach-O loader, a runtime, and a freestanding replacement for libSystem.B.dylib. Guest memory is identity-mapped, and syscalls cross into the Rust runtime through small assembly stubs that handle TLS switching and NEON register preservation. Guest processes live in a "bottle" — an isolated directory tree shaped like a macOS filesystem, with the host root exposed at /Volumes/linux. Frameworks the runtime can't provide, like Security and CoreFoundation, get soft stubs that keep CLI tools limping along.

The verified wins are modest but real: the official macOS builds of 7-Zip and curl work, including multithreaded compression and HTTPS with certificate validation, and Apple's own Git from the Xcode Command Line Tools handles basic operations. The author, Vladislav Kalinkin, reports 7-Zip running about 5.2x slower than a native Linux binary on compression (syscall-heavy) and within 1.1–1.2x on compute-bound work. Those numbers are self-reported and nobody on the HN thread has independently reproduced them yet, so treat them as directional. But the shape is exactly what you'd expect from a translation layer with per-syscall overhead and zero instruction-level cost — which is itself weak evidence the architecture is what it claims to be.

The Darling question

Prior art matters here, and the obvious comparison is Darling, which has been reimplementing Darwin userspace on Linux since 2012. Kalinkin's pitch leans on Darling's historical kernel-module dependency, which made it a non-starter in Docker and most cloud environments. That critique is stale — HN commenters were quick to note that Darling runs in userspace now too — and the sharper questions in the thread were about provenance: the project was built with heavy LLM assistance, and Kalinkin's "light-gray room" answer to whether the design independently arrived at Darling-shaped conclusions didn't fully satisfy anyone.

The honest differentiation is narrower but still meaningful: Darling's center of gravity has been x86-64 macOS, while Kakehashi targets the arm64 world Apple actually ships today, and it's small enough to run inside Colima or a plain Docker container on any aarch64 host. It's also worth noting Apple validated the inverse of this trick themselves — Rosetta for Linux lets Linux VMs on Apple Silicon run x86-64 Linux binaries. Syscall-boundary translation between kernels sharing a CPU architecture is a proven pattern; WSL1 was the same idea aimed at Linux-on-Windows.

The CI math, and the catch

The stated motivation is money, and the money is real. GitHub-hosted macOS runners carry a 10x per-minute billing multiplier over Linux, and Linux arm64 runners are cheaper still — call it an order of magnitude, more against Graviton spot capacity. Every team shipping macOS software pays that tax because Apple's licensing ties macOS to Apple hardware, and the supply of rentable Apple hardware is thin and expensive. A userspace layer that ran the Darwin toolchain on commodity ARM Linux would be genuinely disruptive to the MacStadium/Anka/hosted-Mac-runner economy.

But look at what works versus what would need to work. 7-Zip, curl, and Git all have perfectly good native Linux builds — running their Darwin versions on Linux is a tech demo, as HN commenters pointed out. The valuable targets are the things that only exist as Darwin binaries: clang with Apple's SDKs, xcodebuild, codesign, notarization, simulator tooling. Kakehashi explicitly doesn't support code signing (no real Security.framework), and Xcode proper is nowhere in sight. And there's a legal asterisk the README doesn't dwell on: the tool fetches Apple's Command Line Tools from Apple's own update servers, and Apple's license agreements for that software contemplate Apple-branded hardware. Nobody's been sued over a 53-star experiment, but a CI vendor building on this would be inviting the Corellium treatment.

There's also the treadmill. macOS compatibility is a moving target that breaks Homebrew and Darling alike every September. A solo experimental project chasing Apple's private ABI churn is signing up for Wine's twenty-year grind with none of Wine's contributor base.

Should you care?

As a thing to deploy: no. Don't put this in a pipeline; the author himself calls it experimental, and the useful workloads don't run yet. As a signal: absolutely. The arm64 convergence means Darwin-on-Linux no longer requires an emulator, just a syscall translator and a very long list of stubbed libraries — the cost of attempting this dropped by an order of magnitude, which is precisely why a single developer with LLM leverage can get 7-Zip and Git running in months. Someone is eventually going to chase the real prize: Apple's compiler and signing toolchain on cheap Linux ARM iron. Whether that someone survives Apple's lawyers and Apple's ABI churn is the actual open question. Kakehashi's contribution is proving the entry fee is now low enough that people will keep trying.