The developer behind Kakehashi, an experimental compatibility layer for running macOS ARM64 binaries on Linux aarch64, has ended active maintenance while leaving the project open for forks and contributions. The repository documents an ambitious userspace approach that executes guest instructions natively and translates operating-system interactions at the Darwin-to-Linux boundary.
Kakehashi is described as a command-line-first system with neither a just-in-time compiler nor an instruction emulator. It loads Apple’s Mach-O executable format, maps a freestanding implementation of libSystem and translates BSD system calls when guest programs cross into the Linux host. The runtime also intervenes for threads and faults, but the ARM64 guest code itself runs on the compatible host processor. Guest working directories are mapped through to the Linux host, according to the project documentation.
That design avoids the cost of translating every instruction, but it does not create a self-contained macOS environment. Users must assemble a guest filesystem, called a ‘bottle,’ from binaries taken manually from a macOS 26 or later installation. The bottle has a fixed path and must live on the host’s internal system drive; external drives and non-native filesystems such as exFAT are unsupported.
The base set of utilities, including zsh, rm and codesign, occupies about 256MB uncompressed, with the documented zsh library adding roughly another megabyte. Some libraries stored in Apple’s shared cache cannot simply be copied, so Kakehashi aliases them to libSystem. A bootstrap step can then download and unpack Apple’s official Xcode Command Line Tools, providing components such as clang, Git and an SDK inside the guest root.
The repository says the system was verified under Docker, Colima, OrbStack and UTM on Linux aarch64. It lists support for command-line workloads including curl, Git-related tools and nested compiler processes. A documented multi-file 7-Zip test ran at approximately 1.24 times the duration of native Linux 7-Zip. The author cautions that nested clang and linker invocations incur a startup cost, and that matching native macOS wall-clock performance was not the project’s main continuous-integration objective.
The project describes its implementation as clean-room work not derived from Darling and says no proprietary Apple binaries are stored in the repository. Users, however, are responsible for transferring required guest files from their own macOS installations.
In the maintenance notice, the developer cited the number of moving parts, the manual binary-transfer requirement and a lack of issues and pull requests revealing what users wanted. The author also noted that AI had been used during development. Although routine maintenance has stopped, the repository invites interested developers to submit changes, fork the work or propose related projects.
