How to Run macOS Apps on Linux with Darling (What Actually Works in 2026)

No hypervisor, no macOS license, no 40 GB VM disk image — just a translation layer sitting between macOS binaries and your Linux kernel.

If you've landed here, you've probably already spun up a macOS virtual machine at some point and hated it — the sluggish performance, the 40+ GB disk footprint, the fact that you're technically running Apple's operating system on hardware Apple never sold it for. There's a lesser-known project that takes a completely different approach: instead of virtualizing an entire operating system, it translates macOS system calls into Linux ones on the fly, so the macOS binary runs directly on your Linux kernel. That project is called Darling, and in this guide I'll show you exactly what it can and can't do in 2026, not the optimistic version you'll find on most download pages.

I'll say this upfront because most articles about Darling bury it: Darling is not a Wine-level replacement for macOS apps. The project's own GitHub page states plainly that most GUI applications will not run at the moment. If you came here hoping to run Final Cut Pro or Xcode's full IDE on Ubuntu, that's not what's on offer today. What is genuinely useful — command-line tools, Homebrew packages, scripting runtimes, and a growing set of console programs — is still worth understanding, especially if you're a developer who occasionally needs to test something built for Darwin without keeping a Mac around. It stands alongside the best open-source tools for technical productivity.

I've spent time going through Darling's build process, its official documentation, and its own compatibility lists, and I'll walk you through what actually installs, what actually runs, and where people usually get stuck. This isn't a copy-paste of the project's marketing page — it's what happens when you follow the instructions on real hardware.

I'm Mostafa Amaan, and on Valley4Techs I write practical, no-fluff guides on Linux, networking, and open-source tools. Let's get into it.

Darling vs. a macOS VM vs. Wine: Quick Comparison

Before you commit an afternoon to building Darling from source, it helps to see how it actually stacks up against the two things people usually try instead: a macOS virtual machine, and a Wine-style compatibility layer.

I included Wine in that table on purpose — people frequently confuse the two. Wine translates Windows binaries to run on Linux; Darling does the same job for macOS binaries. They solve the same category of problem for a different source operating system, and Wine is roughly two decades further along in maturity, which is exactly why its GUI support is so much further ahead.

What Darling Actually Does (Show, Don't Tell)

Rather than start with a definition, here's the simplest possible demonstration of what Darling is doing under the hood. Once it's installed, this is the entire process of running your first macOS command on Linux:

$ darling shell echo Hello world
Hello world

That single line is doing something a VM can't: it just executed a real Darwin-compatible echo binary, through Darling's own system call emulation and runtime libraries, without ever booting a second operating system. No virtual disk mounted, no boot sequence, no separate kernel spinning up in the background. The macOS-flavored process is talking directly to your Linux kernel, just translated on the fly.

Darling's translation architecture: Mach system calls and Cocoa/Darwin APIs are intercepted and translated directly into native Linux kernel operations.

That's the core distinction worth understanding before you install anything: Darling is a compatibility layer, not a virtualization tool. A VM (or a hypervisor like KVM) creates a completely separate machine, complete with its own kernel, that happens to run alongside yours. Darling instead reimplements the pieces of Darwin — the open-source core that macOS is built on — that a program needs to function: Mach IPC, the POSIX layer, the dyld loader, launchd, and reimplementations of Apple frameworks like Foundation and CoreFoundation. When a macOS binary asks the "kernel" for something, Darling intercepts that request and hands it off to your actual Linux kernel in a form it understands.

What Actually Works in 2026 (This Is the Part Most Articles Skip)

This is the section I most wanted to write, because it's the one every other Darling article glosses over. Saying "Darling lets you run macOS apps on Linux" without qualifying that sentence sets people up for a frustrating afternoon. Here's the honest breakdown, straight from the project's own documentation.

Officially confirmed working, based on Darling's own compatibility notes:

• Homebrew — the macOS package manager itself runs, which opens the door to installing other Homebrew-distributed CLI packages.
• Terminal GNU Emacs 28.1 — installed via Homebrew, confirmed working.
• Python 3 — both the Homebrew-installed version and Python 3.11 from python.org.
• CMake 3.23.2 — installed via Homebrew.
• GNUPlot — works specifically when outputting to PNG files rather than an interactive window.
• The Xcode command-line tools — including the Clang toolchain, which means you can actually compile and run a Mach-O binary from inside Darling.
• EdenMath, a lightweight scientific calculator — one of the few GUI apps confirmed to run.

Notice the pattern: everything on that list is a terminal tool, a scripting runtime, or a build toolchain. That's not a coincidence. Darling's own component system reflects this reality directly — when you configure the build, you choose which "components" to compile, and the CLI-focused ones (core, system, cli) are dramatically more mature than the GUI ones (gui, gui_frameworks).

If you're weighing whether this is even the right tool for what you're trying to do, it's worth pairing this with a broader read on what changes when you switch from Windows to Linux — a lot of the same "will my software actually work" questions apply here too.

Installing Darling on Linux — Full Walkthrough

Darling doesn't ship as a simple package for most distributions — you're building it from source. Don't let that scare you off; it's a repeatable process, it just takes time and disk space. Here's what you need before you start:

• A 64-bit x86 Linux distribution, kernel 5.0 or newer. Darling does not support 32-bit systems at all, even to run 32-bit macOS applications.
• A CPU with SSE3 support — every CPU sold in the last 15+ years qualifies.
• Clang 11 or newer for compiling.
• At least 4 GB of RAM for the build, and roughly 5 GB of disk space for the source tree plus up to 16 GB free during the build itself.

Step 1: Install Build Dependencies

The dependency list is long because Darling reimplements a huge portion of an operating system's userland. Here it is for the most common distributions:

sudo apt install cmake automake clang-15 bison flex libfuse-dev libudev-dev pkg-config \
libc6-dev-i386 gcc-multilib libcairo2-dev libgl1-mesa-dev curl libglu1-mesa-dev \
libtiff5-dev libfreetype6-dev git git-lfs libelf-dev libxml2-dev libegl1-mesa-dev \
libfontconfig1-dev libbsd-dev libxrandr-dev libxcursor-dev libgif-dev libavutil-dev \
libpulse-dev libavformat-dev libavcodec-dev libswresample-dev libdbus-1-dev \
libxkbfile-dev libssl-dev libstdc++-12-dev

sudo dnf install make cmake clang bison dbus-devel flex glibc-devel.i686 fuse-devel \
systemd-devel elfutils-libelf-devel cairo-devel freetype-devel.{x86_64,i686} \
libjpeg-turbo-devel.{x86_64,i686} fontconfig-devel.{x86_64,i686} \
libglvnd-devel.{x86_64,i686} mesa-libGL-devel.{x86_64,i686} \
mesa-libEGL-devel.{x86_64,i686} mesa-libGLU-devel.{x86_64,i686} \
libtiff-devel.{x86_64,i686} libxml2-devel libbsd-devel git git-lfs libXcursor-devel \
libXrandr-devel giflib-devel pulseaudio-libs-devel libxkbfile-devel openssl-devel \
llvm libcap-devel libavcodec-free-devel libavformat-free-devel

sudo pacman -S --needed make cmake clang flex bison icu fuse gcc-multilib \
lib32-gcc-libs pkg-config fontconfig cairo libtiff mesa glu llvm libbsd libxkbfile \
libxcursor libxext libxkbcommon libxrandr ffmpeg git git-lfs

If you're deciding which distro to run this on in the first place, our Linux distro comparison for laptops is a good starting point — Ubuntu and Fedora both have first-class dependency lists here, which matters when you're compiling something this large.

Step 2: Clone the Source

Darling uses Git submodules and Git LFS, so a plain git clone will leave you with a broken tree. (If you want a refresher on Git workflows, see our beginner's guide to Git and GitHub). Make sure git-lfs is installed first, then clone recursively:

GIT_CLONE_PROTECTION_ACTIVE=false git clone --recursive https://github.com/darlinghq/darling.git
cd darling

Step 3: Configure and Build

mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

A few practical notes I'd have wanted before starting this myself:

• make -j$(nproc) parallelizes the build across your CPU cores — on a single thread this build can take well over an hour. Don't exceed roughly twice your core count or you'll thrash your RAM instead of speeding things up.
• If you can't set up 32-bit multilib libraries, add -DTARGET_i386=OFF to the cmake command to build only the 64-bit components. RHEL 10 actually requires this, since 32-bit libraries were dropped from that release entirely.
• Only need the essentials? Pass -DCOMPONENTS=cli,python to skip the heavier GUI and framework components and get a working shell much faster.
• A Darling install is not portable — the install path is hardcoded into the binary. If you need to move it later, uninstall first with tools/uninstall and rebuild with a new CMAKE_INSTALL_PREFIX.

Running Your First macOS Software on Darling

Once installation finishes, Darling creates something it calls a DPREFIX — conceptually identical to a Wine prefix, it's a chroot-like environment with a macOS-style filesystem layout where software gets installed. It's created automatically at ~/.darling the first time you use Darling.

From here, dropping into a Darling shell and installing Homebrew is the most reliable first move, since it unlocks the largest set of known-working software:

$ darling shell
Darling [~]$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Darling [~]$ brew install python3

You can also install standard .pkg packages directly with Darling's own installer tool, and mount .dmg disk images with hdiutil — both work from inside the shell, mirroring how you'd handle them on real macOS.

Compiling With Apple's Own Toolchain

One of the more genuinely impressive things Darling can do is let you compile and run a Mach-O binary using Apple's actual Clang toolchain — extracted from an Xcode .xip archive and run through Darling's unxip tool:

cd /Applications
unxip Xcode_11.3.xip
export SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
echo 'void main() { puts("Hello world"); }' > helloworld.c
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang helloworld.c -o helloworld
./helloworld

That last command genuinely compiles and executes a real macOS binary, built with Apple's own compiler, running on Linux without any virtualization. It's a great sanity check that your build succeeded, and it's the closest thing to "Xcode on Linux" that currently exists — note that Xcode's IDE itself doesn't run, only its command-line toolchain.

The Apple Silicon Dilemma: Can Darling Run ARM64 macOS Apps on Linux?

With Apple transitioning entirely to Apple Silicon (M-series processors), virtually all modern macOS software is compiled for the ARM64 (aarch64) architecture. A common question among Linux developers is whether Darling can execute these newer ARM64 Mac binaries on standard x86_64 PCs.

The short answer is: Darling is an API translation layer, not a CPU instruction emulator. Understanding this distinction is critical:

• How Darling works: On an x86_64 Linux system, Darling executes x86_64 Mach-O binaries natively on your physical CPU. It translates operating system calls (Mach and POSIX), but it does not convert ARM CPU instructions into x86 instructions. It lacks a built-in CPU translation engine like Apple's Rosetta 2.
• Universal 2 ("Fat") Binaries: Many macOS packages are distributed as Universal binaries, containing machine code for both arm64 and x86_64. Darling's dynamic linker (dyld) automatically inspects the binary, extracts the x86_64 slice, and runs it without issue. You can inspect any binary using the command lipo -info binary_name.
• ARM64-Only Binaries: If a developer compiles a macOS CLI tool exclusively for Apple Silicon without an x86_64 slice, Darling on an x86_64 Linux PC will throw a Bad CPU type in executable error. To run ARM64 macOS binaries on Linux, you would either need to run Darling on an ARM64 Linux board (e.g., Ampere or Raspberry Pi with experimental builds) or layer QEMU user-mode emulation beneath Darling.

Managing and Troubleshooting the darlingserver Daemon

Behind every darling shell session sits a crucial background service called darlingserver. It acts as the Mach kernel coordinator, emulating Darwin's inter-process communication (Mach IPC), process lifecycles, and launchd subsystems. When Darling hangs or acts unpredictably, the issue is almost always a stuck or orphaned darlingserver daemon.

How to Reset a Stuck Darling Session

If executing darling shell hangs indefinitely or outputs Cannot connect to darlingserver, follow this recovery sequence in your Linux terminal:

# 1. Attempt a graceful shutdown of the Darling subsystem
darling shutdown

# 2. If it remains stuck, terminate orphaned daemon processes
killall -9 darlingserver 2>/dev/null

# 3. Clean up stale UNIX domain sockets and IPC locks
rm -rf /tmp/darling-$USER /run/user/$(id -u)/darling*

# 4. Verify no lingering overlay mounts remain
grep -E 'darling|overlay' /proc/mounts

Running Inside Docker or CI/CD Containers: If you are compiling or testing Darling inside a Docker container, darlingserver requires specific Linux kernel capabilities. Make sure your container runs with --cap-add=SYS_ADMIN --cap-add=SYS_PTRACE --security-opt seccomp=unconfined, otherwise IPC communication will fail silently during prefix initialization.

Is This Legal? The Nuance Most Articles Skip

This comes up in nearly every discussion thread about Darling, so it's worth addressing directly instead of hand-waving past it. Darling itself — the project's code — is legal and open source. It's built from the parts of Darwin that Apple has publicly released as open-source software, plus community reimplementations of higher-level frameworks like Cocoa (based on The Cocotron and GNUstep). The Darling project is upfront that they only use Darwin components Apple has actually released as free software.

Where it gets murkier is the software you choose to run inside Darling. Apple's macOS software license historically restricts running macOS-related software on non-Apple hardware, and that's the same gray area that applies to running a macOS VM on non-Apple hardware, or a Hackintosh. Darling sidesteps part of that debate since it doesn't run actual Apple-licensed macOS system software — it reimplements the environment those apps expect. But if you install a specific proprietary macOS application inside Darling, that app's own license terms still apply to you, same as they would anywhere else.

I'm not a lawyer, and this isn't legal advice — if you're doing anything beyond personal experimentation with open-source CLI tools, it's worth reading the specific license of whatever software you're running.

5 Mistakes People Make When Trying Darling

1. Expecting full GUI app support. This is the single biggest source of disappointment. Go in expecting a better shell environment and a working Clang toolchain, not a Mac desktop.
2. Trying this on an encrypted home directory. Darling's DPREFIX system depends on overlayfs, and it silently fails on eCryptfs-encrypted or NFS-mounted home folders. Check this before you spend an hour debugging a build that actually succeeded.
3. Using a plain git clone instead of a recursive one. Darling depends heavily on submodules. A shallow, non-recursive clone leaves half the source tree missing and the build fails in confusing ways.
4. Not enough RAM during the build. Under 4 GB, the compile either fails outright or swaps so heavily it appears to hang for hours. If you're on a low-memory VM or container, build elsewhere or add swap first.
5. Moving the installation directory afterward. Darling hardcodes its install prefix into the binary itself. If you relocate the folder instead of properly uninstalling and rebuilding, you'll get cryptic "cannot mount overlay" errors with no obvious cause.

Need Full macOS GUI Apps? Modern VM Alternatives (Docker-OSX vs. OSX-KVM)

If your actual goal is running graphical software — such as Xcode's full Storyboard/SwiftUI canvas, Sketch, Final Cut Pro, or Safari — Darling will not satisfy your requirements today. Instead of spending hours attempting to force GUI frameworks into Darling, modern KVM-accelerated virtualization tools provide near-native performance on Linux workstations.

1. Docker-OSX (SickCodes)

Docker-OSX wraps a complete QEMU/KVM virtualized macOS installation into a Docker container. It automates the entire disk creation, installer download, and bootloader process with a single command. With X11/Wayland display passthrough and PulseAudio forwarding, it runs full macOS Sonoma/Sequoia desktops directly in a Linux window with near-native CPU speeds.

2. OSX-KVM (kholia)

For power users and dedicated hypervisor rigs (such as home lab servers running Proxmox VE), OSX-KVM is the gold standard. It provides raw QEMU scripts with OpenCore bootloaders, allowing dedicated PCIe GPU passthrough (AMD Radeon GPUs) for genuine hardware-accelerated Metal 3 graphics.

3. Sosumi (Snap Package)

If you are on Ubuntu and want a zero-configuration GUI macOS VM without typing complex QEMU flags, Sosumi is available as a one-click Snap package (sudo snap install sosumi). It manages the disk images and RAM allocation in the background, providing an accessible gateway for testing.

When to Use Darling vs. When to Just Run a VM

From what I've seen, the decision usually comes down to one question: do you need a specific macOS application, or do you need a Darwin-flavored environment? If it's the former — you need an actual macOS GUI app to open and function normally — Darling isn't there yet, and a real macOS VM (run legally on Apple hardware) or borrowing time on a physical Mac is still the practical answer. If it's the latter — you want to test a build script, compile something against macOS SDKs, or run a CLI tool that only ships for Darwin — Darling can save you the overhead of spinning up and maintaining a full virtual machine.

If your interest in Darling stems from general Linux experimentation rather than a specific macOS compatibility need, it's also worth browsing what else is worth setting up after a fresh install — our guide on what to do after installing Linux covers the broader checklist, and if virtualization in general is more your goal than macOS specifically, our VMware vs. Proxmox comparison is a better starting point than Darling entirely.

Final Thoughts

Darling is one of those projects that's easy to oversell and just as easy to write off — neither is fair to it. It's not going to replace a Mac, and it's not going to run your favorite macOS design app tomorrow afternoon. But as a way to get a genuine Darwin-compatible shell, run Homebrew, and compile against Apple's own SDKs without touching a hypervisor, it does something no VM or Wine-style tool currently offers on Linux. Twelve years into development, it's still very much a project for developers and tinkerers rather than a plug-and-play solution for end users — and being upfront about that from the start will save you a frustrating first afternoon with it.

If you do get it running, start small: a Homebrew install and a compiled "Hello world" through Apple's Clang is a realistic, satisfying first milestone. Chasing a full GUI app on day one is the fastest way to give up on a genuinely interesting piece of open-source engineering.

Frequently Asked Questions