Rosetta 2 nach macOS 27: Forschungssoftware migrieren oder behalten? 2026

Eine Intel-Anwendung startet, aber niemand kann zusichern, dass das nächste Systemupdate den Forschungsablauf unberührt lässt.

Entscheidung: macOS 27 ist laut Apple die letzte macOS-Version mit Rosetta-Unterstützung; Rosetta ist darin nicht bereits entfernt. Neue Projekte sollten nach Möglichkeit auf eine native Apple-Silicon-Version wechseln. Bei laufenden Projekten sollten Forschende erst Software, Plugins, Lizenzen und Ergebnisse vollständig prüfen und dann zwischen Beibehaltung, Migration und Parallelbetrieb entscheiden.

Dieser Leitfaden ist für Studierende und Forschende gedacht, die auf Intel-only-Software angewiesen sind.
Er hilft auch Mitarbeitenden mit älteren Plugins oder Hardwareanschlüssen sowie den Verantwortlichen für Geräte und Software einer Hochschule.

Zuletzt aktualisiert am 16.10.2026; geprüft anhand der Apple-Developer-Mitteilung zur Rosetta-Unterstützung und des Apple-Release-Eintrags für macOS 27.0.1.

Rosetta-Unterstützung: Übergangsfenster statt sofortigem Ende

Apple erklärte am 01.09.2026, dass macOS 27 die letzte macOS-Version mit Rosetta-Unterstützung sein soll. Apple sagt außerdem, dass Intel-only-Apps nach diesem System nicht mehr auf Apple-Silicon-Macs laufen werden; bestimmte ältere Spiele sind als Ausnahme genannt. Das ist eine Aussage zur Systemunterstützung, keine Bestätigung, dass eine konkrete Forschungsanwendung unter macOS 27 funktioniert. Apples Mitteilung zur Rosetta-Unterstützung ist daher die maßgebliche Quelle für die Systemgrenze, nicht für die Kompatibilität einzelner Laborprogramme.

Wichtig ist die Unterscheidung: Eine Anwendung, die auf einem Apple-Silicon-Mac unter macOS 27 mit Rosetta startet, hat damit nicht automatisch eine zugesicherte Zukunft über dieses System hinaus. Umgekehrt bedeutet „letzte unterstützte Version“ nicht, dass Rosetta innerhalb von macOS 27 schon unbrauchbar wäre. Der Eintrag zu macOS 27.0.1 vom 28.09.2026 belegt eine spätere Systemveröffentlichung, liefert aber keinen pauschalen Freibrief für Intel-Software.

Für die Entscheidung im Forschungsbetrieb zählen deshalb zwei getrennte Fragen: Kann die Anwendung gegenwärtig starten, und sind alle benötigten Funktionen für das konkrete Projekt freigegeben? Die erste Frage lässt sich technisch prüfen. Für die zweite braucht es Herstellerangaben und einen Test mit echten Projektdaten.

Auch die Begriffe „native Version“ und „Universal-App“ sollten nicht als Kompatibilitätsgarantie gelesen werden. Ein Universal-Binary kann Code für unterschiedliche Prozessorarchitekturen enthalten. Ob darin die benötigten Funktionen, Plugins und Lizenzkomponenten enthalten sind, muss dennoch separat belegt werden. Apple beschreibt den Aufbau eines universellen macOS-Binaries; die konkrete Unterstützung einer Forschungsanwendung folgt daraus nicht.

Softwareunterstützung: Startfähigkeit ist nicht Funktionsfreigabe

Bei Intel-Forschungssoftware sollte die Prüfung mit der offiziellen Produktdokumentation beginnen. Suchen Sie nach einer ausdrücklichen Angabe zu Apple Silicon, einer nativen macOS-Version oder einem Universal-Binary. Prüfen Sie außerdem, welche macOS-Versionen der Hersteller tatsächlich nennt. Fehlt eine solche Aussage, gehört der Status in die Kategorie „ungeklärt“ – nicht in die Kategorie „kompatibel“.

Diese Differenz ist in der Forschung wichtig. Ein Programm kann sich öffnen, während ein bestimmter Importfilter, ein Analysemodul oder ein Exportformat scheitert. Auch ein erfolgreiches Startfenster beweist nicht, dass die für ein Projekt entscheidenden Rechenwege korrekt laufen. Eine allgemeine Aussage auf einer Downloadseite ersetzt daher keine Prüfung des verwendeten Workflows.

Eine hilfreiche Vorlage für den Softwareeintrag lautet:

Anwendung:
Herstellerdokumentation:
macOS-Version laut Hersteller:
Native Apple-Silicon-Version / Universal-Binary:
Benötigte Module und Funktionen:
Status: bestätigt / getestet / ungeklärt
Beleg und Prüfdatum:

Die Statusangaben sollten bewusst eng definiert sein. „Bestätigt“ bedeutet: Der Hersteller nennt die relevante Plattform- und Systemunterstützung ausdrücklich. „Getestet“ bedeutet: Das Team hat die konkrete Version mit dem konkreten Projekt geprüft, aber keine weitergehende Herstellerfreigabe gefunden. „Ungeklärt“ heißt: Es fehlt ein belastbarer Beleg oder eine wesentliche Funktion wurde nicht getestet.

Bei wissenschaftlicher Software können Versionshinweise entscheidend sein. Die Systemanforderungen von MATLAB für Mac sind ein Beispiel dafür, warum die Prüfung auf Produkt- und Versionsniveau erfolgen sollte. Daraus darf nicht abgeleitet werden, dass eine andere Anwendung oder ein bestimmtes MATLAB-Projekt unterstützt wird. Entscheidend ist die Dokumentation genau der verwendeten Softwareversion.

Wie lässt sich die Unterstützung für Apple Silicon prüfen?

Ermitteln Sie zuerst, ob der verwendete Prozess tatsächlich nativ oder unter Rosetta läuft. Eine einfache Sichtprüfung kann in Terminal erfolgen:

uname -m
file "/Applications/Beispiel.app/Contents/MacOS/Beispiel"

Eine beispielhafte Ausgabe könnte so aussehen:

arm64
... Mach-O universal binary with 2 architectures: [x86_64] [arm64]

Die Ausgabe ist hier ein Anschauungsbeispiel, kein Messergebnis für eine bestimmte Forschungsanwendung. uname -m beschreibt die Architektur der laufenden Terminal-Sitzung; ein Terminal, das selbst unter Rosetta gestartet wurde, kann deshalb ein anderes Ergebnis liefern als eine native Sitzung. file gibt einen Hinweis auf die enthaltenen Architekturen des untersuchten Programms, bestätigt aber weder die Funktionsfähigkeit aller Module noch die Herstellerfreigabe. Apples Dokumentation zur Rosetta-Übersetzungsumgebung erklärt die Rolle der Übersetzung, nicht den vollständigen Funktionsumfang einer Drittanbieteranwendung.

Prüfen Sie anschließend die Herstellerunterlagen und notieren Sie die genaue Versionsnummer der Anwendung. Wenn keine eindeutige Aussage zur nativen Ausführung vorliegt, fragen Sie beim Hersteller oder beim zuständigen Hochschul-Support schriftlich nach. Die Frage sollte konkrete Komponenten nennen: Anwendungsversion, macOS-Version, verwendete Plugins, Lizenzmethode und benötigte Analysefunktion. Eine allgemeine Antwort wie „läuft auf Mac“ reicht für eine belastbare Migrationsentscheidung nicht aus.

Abhängigkeiten: Plugins, Lizenzen und externe Komponenten

Ein Wechsel der Hauptanwendung kann an Komponenten scheitern, die in der Produktbeschreibung kaum sichtbar sind. Dazu gehören Plugins, Skripte, Kommandozeilenprogramme, Lizenzserver, Treiber und Geräteanschlüsse. Diese Abhängigkeiten müssen einzeln erfasst werden. Dass das Hauptprogramm startet, beweist nicht, dass ein externes Modul dieselbe Prozessorarchitektur unterstützt.

Homebrew-Pakete verdienen eine eigene Prüfung, wenn sie Teil des Workflows sind. Die Homebrew-FAQ zum Standard-Installationspräfix beschreibt unterschiedliche Installationsorte je nach Architektur. Das kann für Skripte relevant sein, die Programme über fest eingetragene Pfade aufrufen. Ein Skript, das nur auf einem Rechner funktioniert, weil es einen alten absoluten Pfad voraussetzt, ist noch kein verlässlich migrierter Workflow.

Bei Lizenzen sollte das Team prüfen, ob die Lizenz an ein Gerät, einen Benutzer, einen Server oder eine bestimmte Installation gebunden ist. Klären Sie außerdem, ob eine neue Installation eine zusätzliche Freischaltung benötigt oder ob ein Lizenzserver aus dem Hochschulnetz erreichbar sein muss. Der Lizenzadministrator sollte die Antwort schriftlich festhalten. Verlassen Sie sich nicht allein auf einen erfolgreichen Start im Testkonto.

Bei Hardwareabhängigkeiten gehören Treiber, USB- oder andere Schnittstellen und die Verfügbarkeit des jeweiligen Geräts in die Prüfung. Bei einem ausgelagerten oder entfernten Mac kann ein lokal angeschlossenes Laborgerät beispielsweise nicht automatisch verfügbar sein. Wenn eine Messung zwingend ein physisches Gerät am Arbeitsplatz voraussetzt, ist eine entfernte Umgebung möglicherweise kein geeigneter Ersatz. Diese Grenze muss vor dem Test geklärt werden.

Die Tabelle ist eine Entscheidungshilfe, keine automatische Freigabe. Schon ein ungeklärter, für das Projekt unverzichtbarer Baustein kann ausreichen, um eine vollständige Umstellung vorerst zu stoppen.

Ergebnisreproduzierbarkeit: Vergleich mit der bestehenden Arbeitsbasis

Ein Migrationsversuch sollte nicht mit einem beliebigen Beispieldatensatz enden. Wählen Sie ein repräsentatives, freigegebenes Projekt, das typische Eingaben, Verarbeitungsschritte und Exporte abdeckt. Legen Sie vor dem Test fest, welche Ergebnisse das Team als gleichwertig akzeptiert. Ein allgemeiner Fehlergrenzwert lässt sich nicht seriös für alle Forschungsgebiete festlegen; die Akzeptanzkriterien müssen aus dem jeweiligen Verfahren und dem bestehenden Qualitätsprozess kommen.

Halten Sie mindestens die folgenden Punkte fest:

• Eingabedateien und deren Prüfsummen oder eine andere teamübliche Identifikation.
• Softwareversion, Systemversion, Plugins und relevante Einstellungen.
• Die Schritte der Analyse einschließlich Skripten und externen Werkzeugen.
• Erwartete Zwischenresultate und die für das Projekt entscheidenden Endergebnisse.
• Exportformate, Dateinamen, Metadaten und Ablageorte.
• Abweichungen gegenüber der bisherigen Arbeitsbasis sowie die Entscheidung des fachlich Verantwortlichen.

Vergleichen Sie nicht nur die sichtbare Ausgabe. Prüfen Sie auch, ob erwartete Dateien erzeugt werden, ob Metadaten erhalten bleiben und ob nach einem erneuten Öffnen des Projekts dieselben Verarbeitungsschritte verfügbar sind. Bei Skripten sind Pfade, Umgebungsvariablen und aufgerufene Hilfsprogramme Teil des Ergebnisses. Änderungen daran können einen Ablauf verfälschen, obwohl die grafische Oberfläche korrekt aussieht.

Apples Hinweise zu Architekturunterschieden im macOS-Code sind für Entwickler eine zusätzliche Orientierung. Für die Bewertung eines fertigen Forschungsworkflows ersetzen sie jedoch keinen Regressionstest. Auch ein identischer Exportname oder ein erfolgreich abgeschlossener Programmlauf beweist keine wissenschaftliche Gleichwertigkeit, wenn das Team die relevanten Resultate nicht verglichen hat.

Wartung und Kontinuität: Migration, Beibehaltung oder Parallelbetrieb

Die passende Entscheidung hängt davon ab, ob die Anwendung geschäftskritisch ist, wie vollständig ihre Abhängigkeiten dokumentiert sind und ob eine belastbare Rückkehrmöglichkeit besteht. Ein neues Projekt mit bestätigter nativer Unterstützung kann in der Regel auf die native Version ausgerichtet werden. Ein laufendes Projekt sollte seine bestehende Arbeitsbasis nicht aufgeben, bevor die entscheidenden Funktionen und Resultate abgenommen sind.

Migration passt, wenn Herstellerangaben und Tests die erforderlichen Funktionen abdecken. Der Übergang sollte Versionsstände, Installation, Lizenz, Skripte und Rückfallplan einschließen. Eine bloße Neuinstallation ist keine Migration, wenn Projektdateien oder automatisierte Verarbeitungsschritte ungeprüft bleiben.

Beibehaltung ist vertretbar, wenn ein laufendes Projekt von einer Intel-only-Komponente abhängt und die neue Umgebung die fachlichen Anforderungen noch nicht erfüllt. Beibehalten heißt jedoch nicht, dass spätere Systemversionen ebenfalls Unterstützung garantieren. Die Teamdokumentation sollte festhalten, welche macOS-Version und welche Programmstände als funktionierende Basis dienen und wann die Entscheidung erneut geprüft wird.

Parallelbetrieb ist sinnvoll, wenn die bestehende Umgebung weiter benötigt wird, während eine native Variante überprüft wird. Die Trennung sollte nachvollziehbar sein: etwa durch getrennte Installationen, klar gekennzeichnete Projektkopien und dokumentierte Lizenzbedingungen. Vermeiden Sie, dass Mitarbeitende unbemerkt abwechselnd verschiedene Versionen mit denselben Forschungsdaten verwenden.

Pausieren der Aktualisierung ist die risikoärmere Zwischenentscheidung, wenn eine Aktualisierung die bestehende Basis gefährden könnte und ein Testsystem noch nicht bereitsteht. Das ist keine dauerhafte Strategie. Legen Sie einen Verantwortlichen und ein Ereignis für die erneute Prüfung fest, etwa eine Herstellerfreigabe oder den erfolgreichen Abschluss der Projektrückläufe.

Prüfablauf für die Arbeitsgruppe

Ein geordneter Ablauf verhindert, dass eine technische Einzelprüfung mit einer Forschungsfreigabe verwechselt wird. Die folgenden Schritte lassen sich als Teamprotokoll verwenden:

1. Anwendungen und Versionen inventarisieren. Erfassen Sie die genaue Version jeder benötigten Forschungsanwendung, Plugins, Skripte, Kommandozeilenprogramme und Treiber. Notieren Sie, welche davon für laufende Projekte unverzichtbar sind.
2. Herstellerinformationen sammeln. Suchen Sie nach expliziten Aussagen zu Apple Silicon, macOS 27 und den benötigten Funktionen. Fehlt eine klare Aussage, markieren Sie den Punkt als ungeklärt und bitten Sie den Hersteller um eine schriftliche Auskunft.
3. Lizenz und Geräteabhängigkeiten klären. Fragen Sie Lizenzverantwortliche nach Aktivierung, Lizenzserver und Bedingungen einer Testinstallation. Erfassen Sie außerdem erforderliche Hardware und deren Anschlussweg.
4. Testumfang festlegen. Wählen Sie ein repräsentatives Projekt und dokumentieren Sie Eingaben, Verarbeitungsschritte, Einstellungen sowie die erwarteten Resultate. Die fachlich verantwortliche Person legt die projektspezifischen Abnahmekriterien fest.
5. Isoliert testen. Verwenden Sie eine getrennte Testumgebung und verändern Sie die bestehende Forschungsinstallation nicht unkontrolliert. Halten Sie fest, ob Prozesse nativ oder unter Rosetta laufen und welche Komponenten geprüft wurden.
6. Ergebnisse vergleichen. Prüfen Sie die fachlich entscheidenden Resultate, Zwischenstände, Exporte und Metadaten gegen die bestehende Arbeitsbasis. Jede Abweichung braucht eine Bewertung, keine bloße technische Erklärung.
7. Beschluss und Rückfall festhalten. Wählen Sie Migration, Beibehaltung, Parallelbetrieb oder pausierte Aktualisierung. Dokumentieren Sie Belege, Verantwortliche, betroffene Projekte und den Anlass für die nächste Prüfung.

Für ein kleines Prüfprotokoll kann eine textbasierte Akte genügen:

Beschluss: Dual-Track
Anwendung und Version:
System und Laufarchitektur:
Geprüfte Plugins / Skripte / Lizenz:
Projekt und Abnahmekriterien:
Ergebnisvergleich:
Offene Risiken:
Verantwortliche Person:
Nächster Prüfgrund:

Der Beispielbeschluss ist keine Empfehlung für jedes Labor. Er zeigt, welche Angaben ein nachvollziehbarer Datensatz enthalten sollte. Eine Arbeitsgruppe sollte die Felder an ihre internen Qualitäts- und Dokumentationsregeln anpassen.

Isolierte Prüfung auf einem entfernten Mac

Wenn die Hochschule keinen geeigneten Apple-Silicon-Testrechner bereitstellt, kann ein gemieteter Mac eine getrennte Prüfstation ergänzen. Vor der Auswahl sind die tatsächliche Konfiguration, der Zugriff, die Übergabe und die Mietbedingungen zu kontrollieren; aus einem Angebot allein folgt keine Zusage für die Eignung einer bestimmten Forschungsanwendung. Die Informationen zu den Mietpreisen für Mac mini sollten deshalb als Angebotsangaben geprüft werden, nicht als Beleg für Softwarekompatibilität.

Eine entfernte Umgebung eignet sich besonders, wenn der Test keine lokal angeschlossene Spezialhardware erfordert und die Forschungsdaten sicher übertragen werden dürfen. Klären Sie vorab, welche Daten die Institution auf extern verwalteten Systemen verarbeiten darf. Dazu gehören Datenschutz, Zugriffsrechte, Speicherort, Aufbewahrung und Löschung. Bei sensiblen oder personenbezogenen Daten gelten die Vorgaben der Hochschule und der DSGVO; eine technische Verbindung per Fernzugriff ersetzt keine Datenschutzfreigabe.

Für den Test sollte ein separater Benutzerzugang verwendet werden, soweit die Arbeitsweise der Umgebung dies zulässt. Übertragen Sie nur die für die Abnahme benötigten Daten und vermeiden Sie dauerhaft gespeicherte Zugangsdaten. Prüfen Sie nach dem Test, welche Dateien zurückkopiert werden müssen und wie temporäre Daten entfernt werden. Die technische Erreichbarkeit per Fernzugriff ist außerdem von einer stabilen Verbindung und den Bedingungen des konkreten Angebots abhängig.

SFTPMAC kann als zusätzliche Testoption in Betracht kommen, wenn kein geeigneter Labor-Mac zur Verfügung steht. Die Übersicht der Mac-Umgebung von SFTPMAC ist der richtige Ausgangspunkt, um verfügbare Zugriffs- und Übergabebedingungen zu prüfen. Vor einer Buchung sollte die Arbeitsgruppe bestätigen, dass die tatsächliche Umgebung, die Mietdauer und der Fernzugriff zum geplanten Test passen. Eine Kompatibilitätszusage für eine bestimmte Forschungssoftware lässt sich daraus nicht ableiten.

Der Vergleich mit dem bisherigen Vorgehen sollte sachlich bleiben: Ein eigener Mac bindet Anschaffungskapital und muss im Labor verwaltet werden; ein vorhandener Linux- oder Windows-Rechner bietet nicht automatisch die erforderliche macOS-Testumgebung; eine isolierte Fernumgebung kann dagegen für begrenzte Prüfungen zusätzliche Einrichtung und Datenübertragung erfordern. Für dauerhafte Hochlast, zwingende lokale Geräteanschlüsse oder Projekte mit nicht auslagerbaren Daten ist eine gemietete Umgebung nicht automatisch die passende Wahl. Für einen zeitlich begrenzten Kompatibilitätstest kann sie jedoch helfen, eine Umstellung zu prüfen, ohne die bestehende Arbeitsbasis sofort zu ersetzen.

Beschluss mit Belegen statt Annahmen

macOS 27 ist nach Apples Angabe die letzte macOS-Version mit Rosetta-Unterstützung, nicht eine Version, in der Rosetta bereits entfernt wurde. Für neue Projekte ist eine bestätigte native Apple-Silicon-Version die bevorzugte Richtung. Bei laufender Intel-Forschungssoftware sollte die Arbeitsgruppe erst Plugins, Skripte, Lizenzen, externe Komponenten und die Reproduzierbarkeit des konkreten Projekts bewerten.

Wer die Prüfung vor einer Systemänderung absichern möchte, sollte zuerst die Herstellerunterlagen und die projektspezifischen Abnahmekriterien festlegen. Fehlt ein geeigneter Mac im Labor, kann ein isolierter Test auf einem entfernten Mac eine Ergänzung sein – sofern Datenregeln, tatsächliche Konfiguration und Übergabe vorab geklärt sind. Langfristige Rechenlast, zwingende physische Geräte und vertrauliche Daten können dagegen für eine eigene, institutionell verwaltete Lösung sprechen. Für einen befristeten Test lässt sich anschließend anhand der realen Bedingungen prüfen, ob eine Mac-Miete von SFTPMAC zur Validierung passt.