macOS 28 Rosetta: Forschungssoftware migrieren 2026

Stand: 16.08.2026. Apple bestätigt, dass Rosetta als allgemeine Übersetzungsschicht für Intel-Anwendungen bis macOS 27 verfügbar ist. Für spätere Systeme ist lediglich ein eingeschränkter Funktionsumfang für bestimmte ältere Spiele beschrieben. (Apple Developer Documentation zur Rosetta-Laufzeit)

Symptom: Ihre Forschungssoftware startet heute noch, hängt aber von Intel-Code, alten Plugins, Treibern oder Kommandozeilenkomponenten ab.
Schnellste Lösung: Prüfen Sie 2026 die komplette Abhängigkeitskette in einer getrennten Apple-Silicon-Umgebung. Wenn ein kritisches Element nicht nativ läuft oder die Ergebnisse nicht reproduzierbar sind, behalten Sie die geprüfte macOS-27-Umgebung und verschieben das Upgrade.

SECTION 01Für wen dieser Migrationsplan gedacht ist

Dieser Ablauf richtet sich an Sie, wenn Sie als Doktorand, wissenschaftlicher Mitarbeiter oder Laboradministrator Intel-basierte Forschungssoftware weiterhin produktiv einsetzen. Besonders gefährdet sind Arbeitsplätze mit älteren Plugins, proprietären Gerätetreibern, selbst kompilierten Erweiterungen oder Kommandozeilenwerkzeugen, die nie ausdrücklich für Apple Silicon freigegeben wurden.

Auch Entwickler wissenschaftlicher Anwendungen profitieren davon. Eine Anwendung kann zwar als Universal Binary vorliegen, während ein Plugin, eine Bibliothek oder ein Installationsskript weiterhin nur x86_64 unterstützt.

Sie müssen deshalb nicht nur prüfen, ob das Hauptprogramm startet. Entscheidend ist, ob der vollständige Forschungsprozess mit denselben Eingabedaten, Parametern und Ausgabedateien wiederholbar bleibt.

SECTION 0216.08.2026: Risikobild und Ausgangsentscheidung

Am 16.08.2026 ist macOS 28 noch nicht offiziell veröffentlicht. Apple bestätigt jedoch, dass Rosetta als allgemeine Unterstützung für Intel-Anwendungen bis macOS 27 verfügbar ist. Für die Zeit danach beschreibt Apple lediglich einen eingeschränkten Rosetta-Funktionsumfang für bestimmte ältere, nicht mehr gepflegte Spiele. Das ist keine Zusage, dass wissenschaftliche Intel-Programme, Plugins oder Treiber weiter funktionieren werden. (Apple Developer Documentation zur Rosetta-Laufzeit)

Die praktische Konsequenz lautet: Behandeln Sie macOS 28 nicht als normales, folgenloses Systemupdate. Teilen Sie Ihre Forschungsaufgaben zunächst in drei Risikoklassen ein.

Hohe Priorität

Ein Experiment läuft regelmäßig und kann nicht ohne Weiteres unterbrochen werden.
Das Ergebnis hängt von einem Intel-Plugin, einem Treiber oder einer proprietären Bibliothek ab.
Es gibt keine dokumentierte Apple-Silicon-Version.
Ein Fehlschlag würde Proben, Messzeit oder eine laufende Publikationsarbeit gefährden.

Mittlere Priorität

Eine native Version existiert, wurde aber noch nicht mit Ihren Daten und Skripten geprüft.
Das Programm kann ersetzt werden, doch die Exportformate oder Parameter unterscheiden sich.
Die Anwendung wird nur gelegentlich für Nachanalysen oder Visualisierungen eingesetzt.

Niedrige Priorität

Das Programm ist bereits Universal oder Apple-Silicon-nativ.
Alle Erweiterungen und externen Werkzeuge sind ebenfalls geprüft.
Ein repräsentativer Datensatz erzeugt auf beiden Architekturen nachvollziehbare Ergebnisse.

Die Priorität darf nicht allein vom Alter der Software abhängen. Ein zehn Jahre altes Hilfsprogramm kann harmlos sein, während ein kleines, nicht sichtbares Plugin den gesamten Workflow blockiert.

SECTION 03Erste Stunde: Abhängigkeitskette aufnehmen

Beginnen Sie nicht mit einer Neuinstallation. Erstellen Sie zuerst eine Migrationsakte, die den derzeit funktionierenden Zustand beschreibt. Für jedes Element sollten Sie mindestens folgende Informationen erfassen:

Name und genaue Version der Anwendung
Bezugsquelle und Lizenzmodell
Architektur: Intel, Universal oder Apple Silicon
Installationsort und verantwortliche Person
Verwendete Plugins, Extensions und Treiber
Externe Kommandozeilenprogramme und dynamische Bibliotheken
Eingabe- und Ausgabeformate
Abhängigkeit von Netzwerkdiensten, Geräten oder Berechtigungen
Letzter erfolgreich reproduzierter Datensatz

Bei einer grafischen Anwendung öffnen Sie im Finder das Informationsfenster mit Befehl-I. Apple unterscheidet dort zwischen „Intel“, „Universal“ und „Apple Silicon“. Eine Intel-Anwendung benötigt auf einem Apple-Silicon-Mac Rosetta; eine Universal-Anwendung enthält grundsätzlich beide Architekturen, kann aber wegen eines alten Plugins trotzdem im Rosetta-Modus gestartet werden. (Apple Support zur Architekturprüfung)

Für ein ausführbares Kommandozeilenprogramm reicht die Prüfung des Hauptprogramms nicht aus. Verwenden Sie beispielsweise:

file /Pfad/zum/Programm
lipo -archs /Pfad/zum/Programm

Apple weist darauf hin, dass Sie den Pfad zur tatsächlichen ausführbaren Datei prüfen müssen, nicht nur zum App-Ordner. lipo -archs zeigt, ob etwa arm64, x86_64 oder beide Architekturen enthalten sind. (Apple-Dokumentation zu Universal Binaries)

Prüfen Sie außerdem typische versteckte Abhängigkeiten:

find ~/Library -type f \( -name "*.dylib" -o -name "*.bundle" -o -name "*.plugin" \)

Dieser Befehl liefert keine automatische Kompatibilitätsbewertung. Er hilft Ihnen lediglich, Komponenten zu finden, die in der grafischen Oberfläche nicht auffallen. Danach müssen Sie jede Datei einem Programm, einem Herstellerdokument oder einem internen Build-Prozess zuordnen.

Erfahrung aus der Administration: „Die Anwendung startet“ ist kein Freigabekriterium. Ein Intel-Plugin kann erst beim Import eines bestimmten Datenformats, beim Export eines Ergebnisses oder beim Zugriff auf ein Messgerät geladen werden.

Dokumentieren Sie die Befunde nicht nur in einer privaten Notiz. Für ein Labor ist eine gemeinsame Migrationsakte sinnvoller, weil dort auch Lizenzinhaber, Geräteverantwortliche und die Person für die Ergebnisprüfung sichtbar bleiben.

SECTION 04Erste Woche: Native Testumgebung ohne Produktionsrisiko

Installieren Sie die Apple-Silicon-Version zunächst auf einem separaten Mac oder in einer isolierten, ausdrücklich dafür vorgesehenen Umgebung. Überschreiben Sie nicht den Arbeitsplatz, auf dem gerade Experimente laufen. Der Test muss reproduzierbar sein, aber nicht zwingend auf demselben Gerät stattfinden.

Wenn Sie eine entfernte Mac-Umgebung verwenden, klären Sie vor Beginn vier Punkte:

Ist die benötigte macOS-Version tatsächlich verfügbar?
Erhalten Sie ausreichende Installations- und Administrationsrechte?
Können Sie die erforderlichen Pakete, Compiler und Bibliotheken installieren?
Wie werden sensible Forschungsdaten übertragen, gelöscht und gegen unbefugten Zugriff geschützt?

Bei personenbezogenen oder unveröffentlichten Daten müssen Sie die Vorgaben Ihrer Hochschule und der DSGVO berücksichtigen. Verwenden Sie für den ersten Durchlauf deshalb einen öffentlichen Datensatz oder eine vollständig anonymisierte Kopie. Prüfen Sie außerdem, ob VNC-, SSH- oder Webzugänge in die Sicherheitsfreigabe Ihres Instituts passen.

Installieren Sie anschließend in dieser Reihenfolge:

Dokumentieren Sie die Ausgangsversion von macOS und die Hardwarearchitektur.
Installieren Sie die native Hauptanwendung ohne alte Konfigurationsdateien zu übernehmen.
Erfassen Sie jede automatisch vorgeschlagene Zusatzkomponente.
Installieren Sie Forschungsbibliotheken und Pakete aus einer nachvollziehbaren Quelle.
Bauen Sie selbst kompilierte Erweiterungen mit arm64 oder als Universal Binary neu.
Übertragen Sie nur die für den Test benötigten Konfigurationsdateien.
Speichern Sie Terminalausgaben, Installationsprotokolle und Fehlermeldungen.

Besondere Aufmerksamkeit verdienen R, MATLAB und ähnliche Plattformen, bei denen Hauptprogramm, Pakete, Toolboxes und externe Compiler getrennt bewertet werden müssen. Für MATLAB dokumentiert der Hersteller beispielsweise eine native Apple-Silicon-Version ab R2023b, nennt aber zugleich Produkte und Support Packages, die auf Apple Silicon nicht verfügbar sind. Außerdem ist MATLAB R2025b laut Hersteller die letzte Version für Intel-Macs; ab R2026a ist Intel nicht mehr als Plattform vorgesehen. (MathWorks: Apple-Silicon-Systemanforderungen)

Das ist kein allgemeines Urteil über jede MATLAB-Anwendung. Es zeigt vielmehr, warum Sie die konkrete Toolbox und den konkreten Workflow prüfen müssen.

SECTION 05Kurzfristige Rückkehrtests mit einem repräsentativen Datensatz

Ein Testdatensatz sollte klein genug sein, damit Sie ihn mehrfach ausführen können, aber realistisch genug, um die kritischen Verarbeitungsschritte abzubilden. Nutzen Sie nach Möglichkeit einen bereits veröffentlichten oder vollständig anonymisierten Datensatz.

Vergleichen Sie nicht nur die Enddatei. Halten Sie für die Intel- und Apple-Silicon-Umgebung jeweils fest:

Start und Ende jedes Verarbeitungsschritts
verwendete Programmversionen und Pakete
Warnungen und Fehlermeldungen
erzeugte Dateiformate und Metadaten
Zufallsstarts, Toleranzen und Rundungsoptionen
Abweichungen in Diagrammen, Kennzahlen oder Modellparametern
benötigte manuelle Eingriffe

Bei numerischen Analysen kann eine bytegenaue Gleichheit unrealistisch sein, während die wissenschaftliche Aussage trotzdem reproduzierbar bleibt. Legen Sie daher vor dem Test fest, welche Abweichung fachlich akzeptabel ist. Diese Grenze darf nicht erst nach einem fehlgeschlagenen Vergleich angepasst werden.

Für automatisierte Abläufe sollten Sie jede Shell-Datei, Python-Umgebung, R-Abhängigkeit und CI/CD-Konfiguration prüfen. Ein Skript kann unauffällig sein, aber über PATH, Homebrew-Pfade oder fest codierte Intel-Bibliotheken auf die alte Architektur verweisen.

Wenn Sie selbst Software entwickeln, bauen Sie die Anwendung nicht einfach unter Rosetta. Apple empfiehlt, vorkompilierte Bibliotheken zu aktualisieren oder vom Anbieter eine Apple-Silicon-fähige XCFramework anzufordern. Für Universal Binaries müssen die enthaltenen Architekturvarianten getrennt geprüft werden. (Apple Technote zur Behebung von Build-Fehlern auf Apple Silicon)

SECTION 06Entscheidungswerkzeug für die Upgrade-Freigabe

Nutzen Sie diese bedingte Prüfliste unmittelbar vor der Freigabe. Kreuzen Sie einen Punkt erst an, wenn dafür ein Protokoll, ein Herstellerdokument oder ein reproduzierbarer Test vorliegt.

[ ] Das Hauptprogramm ist als Apple Silicon oder Universal identifiziert.
[ ] Alle produktiv verwendeten Plugins, Extensions und Treiber sind einzeln geprüft.
[ ] Alle externen Kommandozeilenprogramme und dynamischen Bibliotheken sind mit file oder lipo kontrolliert.
[ ] Eingabeformate, Ausgabeformate und Metadaten funktionieren in der Testumgebung.
[ ] Die Automatisierung läuft ohne fest codierte Intel-Pfade oder nicht verfügbare Abhängigkeiten.
[ ] Ein repräsentativer, anonymisierter Datensatz wurde in beiden Umgebungen verarbeitet.
[ ] Ergebnisabweichungen sind fachlich erklärt und innerhalb der vorher festgelegten Grenze.
[ ] Lizenzen, Administrationsrechte, Netzwerkzugriffe und DSGVO-Anforderungen sind geklärt.
[ ] Ein Rückfall auf die geprüfte Umgebung ist technisch möglich und dokumentiert.

Wenden Sie anschließend diese Entscheidungslogik an:

Wenn alle Punkte erfüllt sind, wählen Sie die native Migration. Aktualisieren Sie zuerst ein nichtkritisches Gerät und beobachten Sie den Workflow, bevor weitere Laborgeräte folgen.
Wenn nur die Komponentenprüfung oder der Ergebnisvergleich offen ist, wählen Sie den zeitlich begrenzten Parallelbetrieb. Legen Sie einen Verantwortlichen und einen konkreten Nachtest fest; lassen Sie die produktive macOS-27-Umgebung unverändert.
Wenn ein kritisches Intel-Element nicht ersetzbar ist, wählen Sie „Upgrade verschieben“. Bewahren Sie die geprüfte macOS-27-Umgebung, sperren Sie ungeplante Systemupdates und dokumentieren Sie den Grund.
Wenn die Anwendung startet, aber Datenimport, Export, Gerätezugriff oder Ergebnisreproduktion scheitern, gilt die Umgebung als nicht freigegeben.
Wenn die Datenverarbeitung in einer entfernten Umgebung aus Datenschutz- oder Lizenzgründen nicht zulässig ist, verwenden Sie dort nur Testdaten und suchen Sie für Originaldaten eine intern genehmigte Umgebung.

Diese Liste ist bewusst strenger als ein einfacher Starttest. Für Forschungssoftware zählt nicht, ob ein Fenster geöffnet wird, sondern ob der wissenschaftliche Prozess kontrolliert fortgesetzt werden kann.

SECTION 07FAQ zur Rosetta-Migration

Intel-Software nach macOS 28

Eine allgemeine Weiterverwendung Intel-basierter Forschungssoftware darf nicht angenommen werden. Apple grenzt die allgemeine Rosetta-Unterstützung auf macOS 27 ein. Ob ein einzelnes Programm später funktioniert, hängt von seiner Architektur, seinen Plugins, seinen Bibliotheken und seinen Systemintegrationen ab. Für eine Forschungsumgebung ist deshalb ein dokumentierter Test belastbarer als die Aussage des Herstellers „läuft auf dem Mac“.

Rosetta-Abhängigkeit erkennen

Die Finder-Anzeige „Art“ ist der erste Test. Danach untersuchen Sie ausführbare Dateien mit file oder lipo und prüfen Plugins, Bundles, Treiber sowie Installationsskripte separat. Bei einer Universal-Anwendung kann die Option „Mit Rosetta öffnen“ aktiviert sein, damit alte Intel-Erweiterungen funktionieren. Entfernen Sie diese Option erst, wenn die Erweiterungen nativ aktualisiert oder ersetzt wurden.

macOS 27 als Übergangssystem

Eine geprüfte macOS-27-Umgebung ist sinnvoll, wenn ein produktiver Workflow noch ein nicht ersetzbares Intel-Element benötigt. Sie sollte nicht als dauerhaft ungepflegtes Altsystem behandelt werden. Definieren Sie eine verantwortliche Person, sperren Sie ungeplante Upgrades, sichern Sie Installationsmedien und legen Sie einen Termin für die nächste Herstellerprüfung fest.

Fehlendes Intel-Plugin

Fehlt eine Apple-Silicon-Version, prüfen Sie zuerst einen Ersatz über ein kompatibles Exportformat oder einen separaten Verarbeitungsschritt. Ist das fachlich nicht möglich, bleibt der betroffene Workflow vorerst in der geprüften macOS-27-Umgebung. Eine neue Plattform darf erst freigegeben werden, wenn die wissenschaftlich relevanten Funktionen ohne dieses Plugin nachweisbar erhalten bleiben.

SECTION 08Upgrade-Freigabe und Rückfallbedingungen

Am Tag der geplanten Aktualisierung brauchen Sie keine allgemeine Einschätzung, sondern eine klare Entscheidung. Die Freigabe sollte schriftlich festhalten, welche Person den Test durchgeführt hat, mit welchem Datensatz gearbeitet wurde und welche Komponenten noch unter Beobachtung stehen.

Der häufigste Fehler besteht darin, die Entscheidung am Hauptprogramm festzumachen. In Forschungsumgebungen sitzen die eigentlichen Risiken oft in Importfiltern, Gerätetreibern, PDF- oder Bildexporten, R-Paketen, MATLAB-Toolboxes oder selbst kompilierten Bibliotheken.

Für ein Labor mit mehreren Geräten empfiehlt sich eine gestufte Freigabe:

Zuerst wird ein nichtkritischer Arbeitsplatz aktualisiert.
Danach wird derselbe repräsentative Datensatz erneut verarbeitet.
Erst nach erfolgreicher Prüfung folgt ein zweites Gerät mit ähnlicher Nutzung.
Produktive Geräte mit laufenden Experimenten bleiben bis zum Abschluss der Rückfallprüfung unverändert.
Die Freigabe wird bei jedem kritischen Fehler zurückgenommen, nicht erst nach mehreren Fehlversuchen.

Wenn ein Experiment nicht pausieren darf, ist ein Parallelbetrieb kein unnötiger Luxus, sondern eine Risikobegrenzung. Er verursacht zwar zusätzlichen Verwaltungsaufwand, verhindert aber, dass ein ungeprüftes Systemupdate den einzigen funktionierenden Analyseweg beseitigt.

SECTION 09Langfristige Pflege der Migrationsakte

Eine einmalige Prüfung reicht nicht aus. Wiederholen Sie die Architekturprüfung, wenn sich eine der folgenden Bedingungen ändert:

neue macOS-Version oder Sicherheitsaktualisierung
neue Version der Forschungssoftware
Wechsel eines Plugins oder Gerätetreibers
Änderung der Compiler- oder Homebrew-Toolchain
Veröffentlichung einer neuen Ausgabemethode
Wechsel der verantwortlichen Person im Labor

Kennzeichnen Sie jede Komponente mit einem Status: „nativ geprüft“, „Universal geprüft“, „Intel mit Übergangssystem“, „Ersatz gesucht“ oder „nicht freigegeben“. Ergänzen Sie Datum, Testdatensatz, verantwortliche Person und Ergebnisdateien.

Wenn Sie eine isolierte Testumgebung benötigen, kann ein gemieteter Mac von MACNOX eine sinnvolle Zwischenstation sein, sofern die benötigte Systemversion, die Administrationsrechte, der Fernzugriff und die Löschprozesse vorab bestätigt sind. Über Informationen zur Mac-Nutzung für Forschungsumgebungen können Sie zunächst klären, ob ein entfernter Testarbeitsplatz zu Ihrem Ablauf passt. Für die Kostenprüfung finden Sie die aktuellen Angaben auf der Seite zu Mac-Mietpreisen.

Das ersetzt keine Prüfung der Hochschulrichtlinien. Es verhindert aber, dass Sie für einen kurzen Kompatibilitätstest sofort einen zusätzlichen lokalen Arbeitsplatz beschaffen müssen.

SECTION 10Der sinnvolle nächste Schritt für Ihr Labor

Wenn Ihr aktueller Intel-Workflow produktiv und nicht kurzfristig unterbrechbar ist, ist ein ungeplanter Wechsel auf Apple Silicon keine belastbare Strategie. Die bisherige Umgebung bindet Sie an alte Hardware oder an ein System, dessen weitere Rosetta-Kompatibilität nicht garantiert ist. Ein lokaler Ersatz-Mac verursacht zusätzlich Beschaffung, Wartung, Lizenzverwaltung und möglicherweise eine lange Übergangsphase.

Für einen kontrollierten Test ist es oft vernünftiger, zunächst eine anonymisierte Projektkopie in einer getrennten Mac-Umgebung auszuführen. Wenn Sie dafür eine MACNOX-Umgebung anfordern, sollten Sie vorab die gewünschte macOS-Version, Zugriffsrechte, Datenlöschung und die Dauer des Tests festlegen.

Erst wenn der native Workflow vollständig durchgelaufen ist, entscheiden Sie zwischen Migration, Parallelbetrieb und dem befristeten Verbleib auf macOS 27. Warten Sie nicht auf die Veröffentlichung von macOS 28, um erstmals herauszufinden, welche Intel-Komponente Ihr Experiment tatsächlich blockiert.