Darling

Darling runs macOS programs on Linux without a virtual machine, the way Wine runs Windows programs. The project makes that comparison itself, and the name is Darwin plus Linux. A macOS binary is loaded directly, its system calls are answered by a Linux-side implementation of Darwin, and the Apple frameworks it links against are either Apple's own open-source releases or reimplementations. Many command-line tools already work; graphical applications are the unfinished part.

How it works

There are two moving pieces. A Mach-O loader maps macOS executables into a Linux process, and darlingserver, a userspace kernel server, implements the Mach IPC, POSIX and Darwin syscall interfaces those executables expect. Because there is no hardware emulator, nothing sits between the program's instructions and the CPU; neither the landing page nor the README mentions translating between CPU architectures.

Above that layer the code comes from two places. The low-level components — XNU, libSystem, Security — are built from Apple's open-source Darwin releases, which is also how the project answers the EULA question: it only uses the parts of Darwin Apple published as free software. The higher-level frameworks have to be written again. Foundation, CoreFoundation, CoreAudio and AppKit are reimplemented, AppKit on top of The Cocotron, with pieces of the Apportable Foundation and GNUstep mixed in. GUI work is backed by that AppKit plus an initial Metal backend that translates to Vulkan.

Installed software lives in a DPREFIX, Darling's WINEPREFIX: a chroot-like tree with a macOS filesystem layout, ~/.darling by default and moved with the DPREFIX environment variable. Prefixes are built with overlayfs, which is where the sharpest practical limit comes from — see below.

Usage

$ uname
Linux
$ darling shell
Darling [~]$ uname
Darwin

darling shell drops you into a macOS-like shell inside the prefix, and it carries enough of the Apple tooling to install things the macOS way:

Darling [~]$ installer -pkg mc-4.8.7-0.pkg -target /      # .pkg; uninstaller removes
Darling [~]$ hdiutil attach Xcode_7.2.dmg                 # DMG images
Darling [~]$ cp -r /Volumes/Xcode_7.2/Xcode.app /Applications

The README's showcase is compiling a C hello-world with the clang from an Xcode 7.2 image and running the result. Newer Xcode ships as .xip, which unxip unpacks inside the shell. Note what the example does not claim: the Xcode toolchain runs, Xcode the application does not.

It also runs under WSL 2, so a Windows machine can host it too.

Limitations

• GUI support is described on the landing page as basic and experimental, for simple graphical applications. Anyone hoping to run a real macOS desktop app should expect it not to work.
• .mpkg installers are unsupported.
• The overlayfs-based prefix cannot live on NFS or eCryptfs, and the default location fails outright on an encrypted home directory.
• CPU architecture is not addressed on either page, which matters as macOS software moves to arm64-only builds.
• iOS apps are a long-term wish that depends on writing a UIKit from scratch.
• Community packages exist but are explicitly not vetted by the Darling team; official packages cover only some distributions.

Related

Wine is the precedent Darling points to, and abi-stability covers why the Win32 ABI through Wine ended up the stable binary target on Linux. Darling is a long way from that position, since the frameworks a GUI app needs are exactly what it still has to rewrite. For what it takes to get one demanding application through a compatibility layer, lightroom-cc-on-linux is a worked Wine example.

On the watchlist for the GUI story: re-check whether the AppKit and Metal-over-Vulkan work runs non-trivial graphical apps.

Repo: darlinghq/darling, GPL-3.0 (submodules may differ). Star count not recorded.