macOS-Software ohne Mac: Open-Source-Projekt Kakehashi führt über 200 macOS-Tools direkt auf ARM-Linux aus

Die langjährige Gewissheit, dass Apple-Software ausschließlich auf Apple-Hardware läuft, zeigt erste Risse. Anfang August 2026 erreichte ein Open-Source-Projekt namens Kakehashi (japanisch für „Brücke“) die Startseite von Hacker News und erzielte 156 Punkte sowie 34 Kommentare. Das Kernprinzip lässt sich in einem Satz zusammenfassen: Ausführung nativer macOS-Software direkt auf ARM-Linux-Rechnern – ganz ohne macOS-Installation oder Virtuelle Maschinen (VM). Bislang wurden über 200 integrierte macOS-Kommandozeilenwerkzeuge erfolgreich getestet, und selbst das Archivierungsprogramm 7-Zip funktioniert einwandfrei. Damit wird Apples geschlossenes Ökosystem erstmals durch eine gezielte technische Lösung herausgefordert.

Abb.: Der Veröffentlichungs-Thread zu Kakehashi auf Hacker News, in dem der Autor Fragen zum Entwicklungsstand beantwortete. Quelle: news.ycombinator.com

Warum das bisher als unmöglich galt

Für die meisten Anwender bilden Apple-Software und Mac-Hardware eine untrennbare Einheit: Anwendungen für macOS starten schlicht nicht auf anderen Plattformen. Dies ist kein Zufall, sondern das Ergebnis von Apples Strategie des „Walled Gardens“.

Apples Geschäftsmodell verknüpft den Verkauf von Hardware direkt mit exklusiver Software. Die Lizenzbestimmungen (EULA) von macOS schreiben vor, dass das Betriebssystem nur auf herstellereigener Hardware betrieben werden darf. Die Installation auf Dritthersteller-Geräten verletzt diese Vereinbarung. Zusammen mit den Provisionen des App Stores und den Cloud-Diensten dient jeder gekaufte Mac als Eintrittskarte in dieses Ökosystem. Über Jahrzehnte gab es für die Nutzung von macOS-Software auf fremder Hardware nur zwei Wege: Entweder den Einsatz einer trägen, ressourcenintensiven VM oder das Ausweichen auf komplexe, rechtlich umstrittene Hackintosh-Konfigurationen.

Kakehashi verfolgt einen dritten Ansatz: Nicht das Betriebssystem wird portiert, sondern lediglich die Anwendung.

Die Funktionsweise: Ein Übersetzer auf Systemebene

Die Ausführung von macOS-Anwendungen unter Linux scheitert gewöhnlich an den unterschiedlichen Systemschnittstellen (ABIs und System Calls). Früher erforderte die Kommunikation zwischen beiden Welten den Import der gesamten macOS-Benutzerumgebung.

Der entscheidende Ansatz von Kakehashi basiert auf der Erkenntnis, dass Apples M-Chips und moderne ARM-Linux-Geräte auf dieselbe grundlegende Befehlssatzarchitektur (ARM) setzen. Da die Befehle auf CPU-Ebene identisch verarbeitet werden, läuft der Anwendungscode direkt auf dem Linux-Prozessor ab, ohne dass eine CPU-Emulation erforderlich ist. Eine Übersetzung wird nur an den Schnittstellen benötigt, an denen die Anwendung Betriebssystemdienste anfordert – etwa beim Lesen von Dateien, bei Netzwerkzugriffen oder der Speicherallokation. Kakehashi fungiert an dieser Stelle als Intercept-Schicht: Ruft eine macOS-Anwendung eine Datei ab, wandelt Kakehashi die Anforderung in den entsprechenden Linux-Systemaufruf um und liefert das Ergebnis zurück.

Abb.: Apples M-Prozessoren und gängige ARM-Linux-Geräte nutzen dieselbe Architektur, was den Rechenaufwand für die Ausführung drastisch reduziert. Quelle: Wikimedia Commons

Architektonisch bezeichnet man dieses Konzept als Kompatibilitätsschicht (Compatibility Layer). Das bekannteste historische Vorbild ist Wine, das Windows-Anwendungen unter Linux nutzbar macht.

Ein 30 Jahre altes Prinzip

Im Jahr 1993 startete das Open-Source-Projekt Wine mit einem ähnlich ehrgeizigen Ziel: Die Ausführung von Windows-Software auf Linux-Systemen. Damals bezweifelten Experten den Erfolg, da die Nachbildung tausender Windows-APIs unlösbar schien. Nach drei Jahrzehnten kontinuierlicher Entwicklung hat sich Wine jedoch zu einer etablierten Schlüsseltechnologie entwickelt.

Heute bildet Wine die Grundlage moderner Systeme: Valve nutzt eine angepasste Version (Proton) im Steam Deck, wodurch hunderte Nutzer Windows-Spiele nativ auf einem mobilen Linux-Gerät ausführen können. Was einst als unmachbar galt, wurde zum Fundament einer erfolgreichen Hardware-Plattform.

Kakehashi ist nicht der erste Versuch einer Kompatibilitätsschicht für macOS. Das Projekt Darling verfolgte ein ähnliches Ziel, wies jedoch geringere Entwicklungsgeschwindigkeiten auf. Der Entwickler von Kakehashi stellte auf Hacker News klar, dass es sich nicht um einen Fork von Darling handelt, sondern um eine eigenständige, in Rust geschriebene Implementierung, die vollständig im User Space arbeitet und minimale Systemrechte benötigt. Die Erwähnung von AI-Unterstützung im Entwicklungsprozess führte in der Community zu Diskussionen über saubere Quellcode-Implementierung, worauf der Autor auf die vollständige Transparenz des Open-Source-Codes verwies.

Ist eine 5,2-fache Verzögerung ein Hindernis?

Der derzeit auffälligste Benchmark betrifft das Archivierungstool 7-Zip: Bei einem Komprimierungstest mit 8.000 Dateien und 240 MB Datenvolumen lieferte 7-Zip korrekte Ergebnisse, lief jedoch 5,2-mal langsamer als die native Linux-Version (118 Sekunden gegenüber 22,5 Sekunden). Gleichzeitig bestanden über 200 curl-Befehlsvarianten die automatisierten Tests, und grundlegende Funktionen des Xcode-internen Git-Tools arbeiteten fehlerfrei.

Eine 5,2-fache Verzögerung wirkt im ersten Moment hoch, entspricht jedoch den typischen Merkmalen einer frühen Kompatibilitätsschicht. Der Leistungsunterschied entsteht primär durch die ständige Übersetzung der Systemaufrufe. Je mehr kleine Dateien verarbeitet werden, desto häufiger tritt dieser Aufwand auf. Bei großen Einzeldateien reduziert sich der Unterschied auf Faktor 1,1 bis 1,2. Wine wies in seinen Anfangsphasen deutlich höhere Verzögerungen auf. Der Entwickler hat bereits Optimierungspläne vorgelegt und strebt als nächste Meilensteine die Unterstützung der vollständigen Xcode-Toolchain (inklusive iOS-Kompilierung) sowie von Homebrew für macOS an.

In den Diskussionen wird jedoch auch auf Risiken hingewiesen: Apple verändert mit nahezu jedem Hauptrelease von macOS interne Schnittstellen, was Kompatibilitätsschichten zu kontinuierlichen Nacharbeiten zwingt. Es bleibt ein asymmetrischer Aufwand gegenüber einem geschlossenen Ökosystem.

Die Bedeutung für das Ökosystem

Grundsätzlich zeigt dieses Projekt den klaren Gegensatz zwischen offenen Standards und proprietären Ökosystemen. Während die Open-Source-Philosophie die freie Nutzbarkeit von Software auf beliebiger Hardware betont, setzt Apple auf die Kontrolle innerhalb des eigenen Ökosystems. Kakehashi demonstriert, dass technische Barrieren durch geeignete Abstraktionen überwunden werden können.

Sollten exklusive macOS-Werkzeuge für Videobearbeitung, Musikproduktion oder Design künftig auf günstiger ARM-Hardware lauffähig sein, würde dies Apples Differenzierung über die Hardware verändern. Die Geschichte von Wine zeigt: Die Verwendbarkeit von Windows-Software auf anderen Plattformen hat den Wert der Anwendungen gesteigert, anstatt das Ursprungsnetzwerk zu schwächen.

Wie weit Kakehashi letztlich gelangen wird, bleibt abzuwarten – die Leistungsdifferenz, sich ändernde Schnittstellen und Lizenzfragen stellen spürbare Hürden dar. Dennoch zeigt die Entwicklung seit 1993, dass grundlegende Veränderungen meist mit kleinen technischen Ansätzen beginnen.

Weiterführende Links:

• Kakehashi GitHub-Repository (wie-project): Projektseite, README, Architektur-Dokumentation und Roadmap
• HN-Diskussions-Thread (item?id=49145937): Details des Autors zu 7-Zip, curl, Xcode-Git sowie dem Verhältnis zu Darling
• Offizielle Wine-Historie: WineHQ-Projektbeschreibung „Wine Is Not an Emulator“
• Wine Wikipedia-Eintrag: Entwicklungsgeschichte von 1993 bis zum Einsatz auf dem Steam Deck