Ein Programm, das jahrelang seinen Dienst tat, wird auf den neuen Mac kopiert –
und tut nichts. Entweder hüpft das Symbol im Dock zweimal und verschwindet
wieder, oder eine knappe Meldung erklärt, die App könne nicht geöffnet werden.
Auf dem alten Rechner lief exakt dieselbe Datei ohne Murren. Besonders beliebt
ist die Variante mit dem Plug-in: Das Hauptprogramm startet, aber die eine
Erweiterung, die den ganzen Arbeitsablauf trägt, taucht in der Liste einfach nicht
mehr auf.
Die „Layer 8“-Wahrheit
Das Programm ist nicht defekt, es spricht nur eine andere Sprache als der
Prozessor. Apple-Silicon-Macs führen ARM-Befehle aus, die alte App enthält
Intel-Befehle für x86_64. Damit die trotzdem laufen, liefert Apple mit Rosetta 2
einen Übersetzer mit – aber eben nur auf Anforderung, und die besteht darin, dass
jemand einmal auf „Installieren“ klickt. Wer diesen Dialog vor drei Wochen
weggeklickt hat, sitzt heute vor einer App, die scheinbar grundlos nicht startet.
Die Fehlermeldung verrät den Zusammenhang selten.
Interessanter ist der Fall, in dem Rosetta längst installiert ist. Dann hilft
kein weiteres Klicken, sondern nur das Wissen, was die Übersetzung leistet und
was nicht. Zwei Grenzen erwischen Büroanwender regelmäßig. Erstens die
Befehlssätze: Alles bis AVX2 wird übersetzt, die AVX-512-Vektorbefehle nicht –
Software, die darauf baut, bricht mitten im Betrieb ab statt beim Start.
Zweitens, und das ist die häufigere Falle, die Unteilbarkeit des Prozesses: Intel-
und ARM-Code dürfen nicht im selben Prozess zusammenkommen, und die Übersetzung
gilt immer für alles, was der Prozess nachlädt. Ein Intel-Plug-in in einer
nativen App wird deshalb nicht geladen. Es ist nicht beschädigt, es passt nur
nicht hinein.
Bleibt die unbequeme Wahrheit zum Schluss: Ein Übersetzer ist eine Brücke,
gedacht für den Übergang. Wer Software einsetzt, für die es nach Jahren immer
noch keine native Fassung gibt, hat kein Rosetta-Problem, sondern ein
Wartungsproblem beim Hersteller.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Feststellen, welcher Mac vor dir steht
Erst die Grundfrage klären, denn auf einem Intel-Mac ist Rosetta nie die Antwort. Die Ausgabe arm64 bedeutet Apple Silicon, x86_64 bedeutet Intel:
uname -m
2.
Die Architektur der Anwendung prüfen
Jetzt die App selbst befragen. Der Pfad zeigt auf die ausführbare Datei im Programmpaket; steht dort nur x86_64, braucht sie Rosetta. Universal-Apps melden zwei Architekturen, native Apps nur arm64:
Beim ersten Start einer Intel-App bietet macOS die Installation selbst an und verlangt dafür Administrator-Zugangsdaten sowie eine Internetverbindung. Wurde der Dialog weggeklickt oder soll die Einrichtung ohne ihn laufen, erledigt das der Softwareaktualisierungs-Befehl im Terminal:
Nach der Ursache suchen, wenn Rosetta bereits da ist
Startet die App trotz vorhandener Übersetzung nicht, liegt es meist an einem der dokumentierten Löcher: AVX-512-Befehle, Kernel-Erweiterungen oder Virtualisierer für x86_64 werden nicht übersetzt. Ebenso scheitert jeder Versuch, ein Intel-Plug-in in einen ARM-Prozess zu laden oder umgekehrt – das verhindert das System grundsätzlich.
5.
Plug-ins und Erweiterungen einheitlich halten
Bei Audio-, Video- und Grafikprogrammen entscheidet nicht die App allein, sondern der ganze Prozess. Entweder alles läuft nativ oder alles läuft übersetzt. Wo eine App wahlweise beides kann, muss die Betriebsart zur Architektur der eingesetzten Plug-ins passen; die Einstellung dafür steckt im Informationsfenster des Programms und heißt je nach macOS-Version etwas anders.
6.
Die native Version besorgen und das Problem beenden
Rosetta ist eine Brücke, kein Dauerzustand. Fast jede aktiv gepflegte Software liegt inzwischen als Universal- oder Apple-Silicon-Fassung vor. Der Umstieg darauf spart nicht nur die Übersetzung, sondern auch die gesamte Klasse von Fehlern aus den vorherigen Schritten.
Häufige Fragen (FAQ)
?Was macht Rosetta eigentlich genau?
Apple beschreibt Rosetta 2 als Übersetzungsmechanismus: Ein Mac mit Apple Silicon kann damit Code ausführen, der für den Befehlssatz x86_64 kompiliert wurde. Die Übersetzung passiert auf zwei Wegen – im Voraus, wenn das System einen günstigen Zeitpunkt sieht, und zur Laufzeit für Code, der erst während der Ausführung entsteht. Der Prozessor führt am Ende ausschließlich ARM-Befehle aus; die Intel-Befehle sind nur noch die Vorlage. Für dich ist davon nichts zu sehen: Es gibt keine Rosetta-App, die man startet.
?Warum stürzt eine App unter Rosetta ab, obwohl Rosetta installiert ist?
Rosetta übersetzt nicht alles. Apple dokumentiert, dass zwar alle x86_64-Befehle einschließlich AVX und AVX2 übersetzt werden, die Vektorbefehle aus AVX-512 aber nicht ausgeführt werden. Software, die auf diesen Erweiterungen aufsetzt – Wissenschafts-, Audio- und Videowerkzeuge sind die üblichen Verdächtigen –, bricht deshalb ab, obwohl der Rest der App läuft. Ebenfalls nicht übersetzt werden Kernel-Erweiterungen und Virtualisierer, die eine x86_64-Plattform nachbilden wollen.
?Kann ich Intel- und ARM-Code in einer App mischen?
Nein, und das erklärt eine ganze Klasse rätselhafter Ladefehler. Apple hält fest, dass das System das Mischen von arm64- und x86_64-Code im selben Prozess verhindert; die Übersetzung gilt immer für den kompletten Prozess samt aller Module, die er nachlädt. Ein Plug-in, eine Bibliothek oder ein Audio-Modul in der jeweils anderen Architektur wird deshalb nicht geladen. Die Meldung lautet dann oft nur, das Modul sei beschädigt – beschädigt ist daran nichts, es passt nur nicht in den Prozess.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Homebrew installiert, aber 'zsh: command not found: brew' auf dem Mac? Auf Apple Silicon fehlt /opt/homebrew im PATH. So richtest du brew dauerhaft ein.