Darling: Mac-Programme unter Linux ausführen

Mac-Software auf einem Linux-Rechner starten, ohne Apple-Hardware im Schrank zu haben – das klingt zunächst nach einem Widerspruch. Beide Welten unterscheiden sich in vielen Details, vom Dateiformat der Programme bis zur Art, wie sie mit dem Betriebssystem sprechen. Trotzdem gibt es ein Projekt, das genau diese Lücke schließen will: Darling. Es erlaubt die Ausführung von macOS-Anwendungen unter Linux und arbeitet dabei nach demselben Grundprinzip wie das bekannte Wine, das Windows-Programme auf Linux lauffähig macht.

Anfang September 2026 rückt die Software erneut in den Blick der Entwickler-Community. Auslöser sind laut einem Bericht von t3n Diskussionen auf der Plattform Hacker News. Bemerkenswert daran: Darling ist keine Neuvorstellung, sondern ein bereits fast zehn Jahre altes Projekt, das über die Zeit gereift ist. Grund genug, sich anzusehen, wie die Kompatibilitätsschicht arbeitet, was sie heute schon leistet und wo die klaren Grenzen verlaufen.

Was Darling ist – und was nicht

Darling ist eine reine Kompatibilitätsschicht. Das ist ein wichtiger Unterschied zu einem klassischen Emulator, der komplette Hardware nachbildet. Statt eine virtuelle Maschine samt Prozessor zu simulieren, übersetzt Darling die Anfragen einer macOS-Anwendung direkt in eine Sprache, die das darunterliegende Linux-System versteht. Das spart Ressourcen und kommt einer nativen Ausführung deutlich näher als jede Form der Vollemulation.

Der Name des Projekts ist kein Zufall, sondern ein technisches Kofferwort. Er setzt sich aus Darwin und Linux zusammen. Darwin ist das Unix-basierte Fundament, auf dem Apple seine Betriebssysteme aufbaut – macOS, iOS und die verwandten Plattformen gründen alle darauf. Laut der offiziellen Dokumentation implementiert Darling eine vollständige Darwin-Umgebung auf dem Linux-System. Damit stellt es der Mac-Software die Umgebung bereit, die sie erwartet, während im Hintergrund Linux die eigentliche Arbeit erledigt.

Die Entwickler beschreiben das Prinzip selbst als Adaption von Wine. Wo Wine die Aufrufe von Windows-Programmen abfängt und für Linux umsetzt, tut Darling dasselbe für macOS-Anwendungen. Der konzeptionelle Rahmen ist also erprobt – nur eben auf ein anderes Ökosystem übertragen.

Der Darlingserver als Simultandolmetscher

Das technische Herzstück des Projekts ist der sogenannte Darlingserver. Man kann sich dieses Programm wie einen Simultandolmetscher zwischen zwei Sprechern vorstellen, die keine gemeinsame Sprache haben. Auf der einen Seite steht die Apple-Software, auf der anderen das Linux-System.

Jedes Programm kommuniziert über sogenannte Systemaufrufe mit dem Betriebssystem. Immer dann, wenn eine Anwendung eine Datei öffnen, Speicher anfordern oder eine andere grundlegende Operation ausführen will, wendet sie sich mit einem solchen Aufruf an den Kern des Systems. Eine macOS-Anwendung nutzt dafür die Aufrufe, die Darwin bereitstellt – und die kennt Linux nicht. Genau hier greift der Darlingserver ein: Er fängt diese Anfragen ab und übersetzt sie in Befehle, mit denen der Linux-Kernel etwas anfangen kann.

Damit dieser Übersetzungsaufwand den Rechner nicht ausbremst, bündelt der Server die Rechenprozesse effizient. Statt für jede kleine Aufgabe einer Mac-App einen eigenen, aufwendigen Linux-Prozess zu starten, verwaltet Darling diese Vorgänge intern. Das schont den Arbeitsspeicher und hält den Overhead in Grenzen – ein Ansatz, der zeigt, dass Darling nicht nur funktionieren, sondern auch praktikabel bleiben soll.

Mach-O-Dateien und die Brücke zur Hardware

Ein zentrales Hindernis liegt schon im Format der Programme selbst. Apple verwendet für seine ausführbaren Dateien das Format Mach-O, mit dem Linux von Haus aus nichts anfangen kann. Linux erwartet ein anderes Format und würde eine Mach-O-Datei schlicht nicht starten.

Darling löst das mit einem eigenen Ladeprogramm. Dieser Loader nimmt die Apple-Dateien, befördert sie in den Arbeitsspeicher des Linux-Rechners und macht sie dort ausführbar. Erst dadurch wird eine für den Mac kompilierte Anwendung auf einem Linux-System überhaupt lauffähig.

Auch der Zugriff auf Hardware verlangt eine Sonderlösung. Wenn eine Mac-App etwa die Soundkarte ansprechen will, erwartet sie die Schnittstellen, die sie von macOS kennt. Darling setzt hier auf eine Art Brückentechnologie: Das Projekt erzeugt dynamische Platzhalter, die der Apple-Software eine vertraute Umgebung vorspielen. Die Audio-Anfragen leiten diese Platzhalter im Hintergrund unbemerkt an die Linux-Infrastruktur weiter. Die Anwendung glaubt, mit einem Mac zu sprechen – tatsächlich landet ihre Anfrage bei den Audio-Diensten des Linux-Systems.

Dateisystem: DPREFIXes und Overlayfs

Damit sich eine Mac-Anwendung auch beim Blick auf die Festplatte zu Hause fühlt, braucht sie die gewohnte Ordnerstruktur von macOS. Darling baut diese als virtuelles Abbild nach. Dafür nutzt das Projekt sogenannte DPREFIXes, die dem WINEPREFIX seines Vorbilds ähneln. In diesen Verzeichnissen entsteht eine macOS-typische Ordnerhierarchie, die von der Anwendung erwartet wird.

Technisch kommt dabei das Kernel-Modul Overlayfs zum Einsatz. Es kombiniert ein schreibgeschütztes Basis-Dateisystem mit einem beschreibbaren Verzeichnis im Heimordner des Nutzers. So bleibt die Grundstruktur unverändert und stabil, während Änderungen sauber in einer separaten, beschreibbaren Schicht landen. Das ist ein bewährter Ansatz, um eine konsistente Umgebung bereitzustellen, ohne das eigentliche System zu verändern.

Bei den Dateisystemen gibt es allerdings Einschränkungen. Die Dokumentation weist ausdrücklich darauf hin, dass NFS, ZFS oder eCryptfs als beschreibbare Schicht nicht unterstützt werden. Wer eine dieser Technologien für die schreibbare Ebene einsetzt, stößt an eine Grenze. Die Verschlüsselung mittels fscrypt funktioniert dagegen reibungslos – ein wichtiger Hinweis für alle, die verschlüsselte Umgebungen betreiben.

Systemvoraussetzungen für den Build

Wer Darling nicht als fertiges Paket nutzt, sondern aus dem Quellcode kompiliert, sollte die Anforderungen kennen. Der Build-Prozess ist ressourcenhungrig. Laut Dokumentation braucht es mindestens vier Gigabyte Arbeitsspeicher und bis zu 16 Gigabyte freien Festplattenspeicher. Außerdem setzt Darling ein 64-Bit-System voraus.

Diese Zahlen sind für moderne Entwicklerrechner unproblematisch, machen aber deutlich, dass das Kompilieren keine Nebensache ist. Der Vorgang bindet über eine gewisse Zeit spürbar Ressourcen. Wer nur einmal etwas ausprobieren möchte, sollte das einplanen – für den Dauerbetrieb in einer Infrastruktur ist der einmalige Aufwand dagegen zu vernachlässigen.

Wofür Darling heute wirklich taugt

Der aktuelle Entwicklungsstand richtet sich klar an ein bestimmtes Publikum: Softwareentwickler und Betreiber von IT-Infrastruktur. Die Kompatibilitätsschicht ist derzeit fast ausschließlich auf die Kommandozeile fokussiert. Wer klassische Desktop-Apps mit Fenstern und Menüs erwartet, greift damit an der falschen Stelle zu.

Auf der Kommandozeile funktioniert dagegen schon eine ganze Reihe wichtiger Werkzeuge zuverlässig. Dazu zählen laut t3n:

• der Paketmanager Homebrew, mit dem sich auf dem Mac üblicherweise Software installieren lässt,
• der Compiler Clang,
• die Programmiersprache Python,
• sowie Teile der Xcode Command Line Tools.

Der praktische Mehrwert liegt genau hier. Entwickler können Apple-spezifische Kommandozeilen-Werkzeuge serverseitig in Automatisierungs-Pipelines auf Linux-Rechnern laufen lassen, ohne dafür physische Mac-Hardware bereithalten zu müssen. Wer etwa in einem Build-System auf bestimmte Apple-Tools angewiesen ist, spart sich damit unter Umständen einen dedizierten Mac im Serverschrank. Für Teams, die ihre Continuous-Integration-Infrastruktur ohnehin auf Linux betreiben, kann das eine spürbare Vereinfachung sein.

Wo die Grenzen verlaufen

Bei grafischen Anwendungen wird es dünn. Die Unterstützung für Apples Cocoa-Framework, das die Basis für grafische Oberflächen bildet, steckt noch im experimentellen Stadium. Die Projektverantwortlichen betonen ausdrücklich, dass große grafische Programme derzeit nicht lauffähig sind. Namentlich genannt werden die Entwicklungsumgebung Xcode, die Musiksoftware Logic sowie das Videoschnittprogramm Final Cut Pro.

Wer also gehofft hat, auf einem Linux-Notebook mal eben Final Cut Pro zu öffnen oder komplette Xcode-Projekte in der grafischen Oberfläche zu bearbeiten, muss sich gedulden. Für diese Szenarien führt bislang kein Weg an echter Apple-Hardware vorbei.

Die ARM64-Frage und der Blick nach vorn

Ein spannender Punkt der aktuellen Diskussionen betrifft die Prozessorarchitektur. Bislang unterstützt Darling die x86_64-Architektur, also die klassische 64-Bit-Welt von Intel und AMD. In der Community wird nun eine mögliche Portierung auf ARM64 thematisiert.

Dieser Schritt wäre naheliegend. Apple hat seine gesamte Mac-Reihe auf eigene Prozessoren umgestellt, die auf der ARM-Architektur basieren. Immer mehr Mac-Software wird primär für diese Chips entwickelt und ausgeliefert. Eine ARM64-Unterstützung in Darling würde das Projekt damit näher an die reale Verbreitung heutiger Apple-Software heranführen. Noch handelt es sich um eine Diskussion in der Entwickler-Community, nicht um eine feste Zusage – aber die Richtung ist klar erkennbar.

Trotz aller Einschränkungen bei grafischen Programmen löst Darling schon heute reale Probleme in der Softwareentwicklung. Der Nutzen entsteht nicht auf dem Desktop, sondern in Infrastruktur und Automatisierung. Genau dort, wo Mac-Werkzeuge gebraucht, aber Mac-Rechner nur mit Aufwand betrieben werden, spielt die Kompatibilitätsschicht ihre Stärken aus.

Was bedeutet das für dich?

Ob Darling für dich interessant ist, hängt stark davon ab, was du damit vorhast. Die folgende Einordnung hilft bei der Entscheidung:

• Wenn du Entwickler bist und Apple-Kommandozeilen-Werkzeuge in deine Build- oder Test-Pipelines einbinden willst, lohnt ein Blick. Homebrew, Clang und Python laufen bereits zuverlässig, und du sparst dir womöglich einen separaten Mac in der Infrastruktur.
• Wenn du IT-Infrastruktur betreibst, prüfe zunächst dein Dateisystem. NFS, ZFS und eCryptfs werden als beschreibbare Schicht nicht unterstützt – fscrypt dagegen schon. Das solltest du vor der Planung klären.
• Wenn du grafische Mac-Programme brauchst, etwa Final Cut Pro, Logic oder Xcode mit Oberfläche, ist Darling derzeit keine Lösung. Diese Anwendungen laufen nicht.
• Wenn du selbst kompilieren willst, halte mindestens vier Gigabyte RAM und bis zu 16 Gigabyte freien Speicher bereit und nutze ein 64-Bit-System.
• Wenn du auf Apple Silicon setzt, behalte die ARM64-Diskussion im Auge. Eine spätere Portierung könnte den Nutzen des Projekts für aktuelle Mac-Software deutlich erhöhen.

Als ersten Schritt empfiehlt es sich, die offizielle Projektdokumentation zu lesen und mit einem einzelnen, klar umrissenen Kommandozeilen-Werkzeug zu starten – etwa Homebrew oder Python. So bekommst du ein Gefühl dafür, wie stabil die Übersetzung in deinem konkreten Anwendungsfall läuft, bevor du Darling fest in eine Pipeline einbindest.