Wann endet die Unterstützung für Rosetta 2? Migrations-Checkliste für Unternehmens-Mac-CI 2026

Apple hat bestätigt, dass macOS 27 die letzte große macOS-Version mit allgemeiner Rosetta-Unterstützung für Intel-only-macOS-Anwendungen sein soll. Das bedeutet nicht, dass Rosetta am Veröffentlichungstag sofort abgeschaltet wird. Es bedeutet aber, dass ein Unternehmen macOS 27 nicht als Begründung für weiteres Aufschieben verwenden sollte.

Die Apple-Dokumentation zur Rosetta-Übersetzungsumgebung beschreibt Rosetta als Übersetzungsschicht, mit der Intel-Code auf Apple-Silicon-Systemen ausgeführt werden kann. Diese Aussage betrifft nicht automatisch jede Intel-Komponente in jeder Umgebung.

Sie müssen vier Fälle auseinanderhalten:

• Intel-Mac-Hardware: Ein Intel-Mac ist eine physische Plattform. Seine Zukunft hängt von der Unterstützung der jeweiligen macOS-Version und von den eingesetzten Werkzeugen ab.
• Intel-only-macOS-Anwendung: Eine solche Anwendung kann auf Apple Silicon über Rosetta starten, solange das Betriebssystem diese allgemeine Unterstützung bereitstellt.
• Universal Binary: Diese Datei enthält getrennte arm64- und x86_64-Slices. macOS kann den passenden Slice laden, sofern Signatur, Bibliotheken und Laufzeitumgebung korrekt sind.
• Rosetta-Prozess: Ein Apple-Silicon-Mac kann einen einzelnen Intel-Prozess ausführen, obwohl der Host selbst vollständig arm64 ist.
• Intel-Binary in einer Linux-VM: Das ist ein anderer Übersetzungsfall. Apple dokumentiert die Ausführung von Intel-Binaries in Linux-VMs separat; Sie dürfen diese Unterstützung nicht als Zusage für Intel-only-macOS-Apps interpretieren. Die Dokumentation zu Intel-Binaries in Linux-VMs behandelt genau diese Abgrenzung.

macOS 26.4 und spätere Versionen können außerdem einen Hinweis zur Migration anzeigen. Ein solcher Hinweis ist kein Beleg dafür, dass Ihre Pipeline bereits vollständig portiert ist. Er ist ein Signal, Ihre Abhängigkeiten und Ausnahmegenehmigungen zu prüfen.

Kann macOS 27 noch Intel-Anwendungen ausführen?
Nach dem derzeit bestätigten Apple-Stand ja, soweit es sich um die von Rosetta abgedeckten Intel-only-macOS-Anwendungen handelt. Diese Kompatibilität ist jedoch kein langfristiger Vertrag für die nächste Hauptversion. Für eine Unternehmens-CI zählt deshalb nicht, ob ein einzelner manueller Start gelingt, sondern ob Build, Test, Signierung, Veröffentlichung und Wiederanlauf ohne Rosetta reproduzierbar funktionieren.

Eine Migration scheitert häufig nicht an der Installation einer arm64-Version, sondern an ungeklärten Übergaben. Legen Sie daher pro Abhängigkeit eine verantwortliche Rolle, einen technischen Nachweis und ein Abnahmekriterium fest.

IT-Verantwortung

Die IT-Verantwortung entscheidet, welche Apple-Silicon-Knoten auf macOS 27 aktualisiert werden dürfen. Dafür benötigt sie eine Liste mit:

• Hostname und Knotenpool
• macOS-Version und Architektur
• CI-Agent und Startmechanismus
• installierten Laufzeitkomponenten
• Rosetta-Status oder Rosetta-Prozessnachweis
• Wartungsfenster und Rückfalloption
• verantwortlichem Team
• Freigabestatus

Die IT darf einen Knoten nicht allein deshalb freigeben, weil der Host Apple Silicon verwendet. Ein arm64-Host kann weiterhin Intel-Tools, Intel-Plugins oder x86_64-Hilfsprozesse starten.

Plattformteam

Das Plattformteam prüft Routing, Cache-Grenzen und Umgebungsvariablen. Native und kompatible Knoten müssen über getrennte Labels, Queues oder Pools angesprochen werden. Caches dürfen nicht unkontrolliert zwischen arm64- und x86_64-Läufen geteilt werden.

Das gilt besonders für Paketverzeichnisse, Build-Artefakte, vorkompilierte Plugins und selbst verwaltete Toolchains. Ein gemeinsamer Cache kann einen erfolgreichen Testlauf vortäuschen, wenn ein bereits kompiliertes Intel-Artefakt wiederverwendet wird.

Toolchain-Verantwortliche

Die Toolchain-Verantwortlichen entscheiden je Komponente zwischen drei Wegen:

1. native arm64-Version einsetzen,
2. eigene Software als arm64 oder Universal Binary neu bauen,
3. geschlossene oder noch nicht portierbare Komponenten befristet isolieren.

Die Apple-Anleitung zur Portierung auf Apple Silicon sollte dabei als technische Referenz dienen. Für selbst entwickelte Binärdateien ist die Anleitung zum Bau eines Universal Binary relevant.

Die Entscheidung „Installation erfolgreich“ reicht nicht. Jede Komponente muss mindestens in einem echten Projekt geprüft werden: Eingabedateien, Tests, erzeugte Artefakte, Signierung und Veröffentlichung.

Sicherheits- und Release-Verantwortliche

Diese Rolle prüft Keychain-Zugriffe, Zertifikate, Notarisierung, interne Plugins, LaunchAgents, Daemons und unbeaufsichtigte Neustarts. Ein Werkzeug, das nur in einer interaktiven Sitzung funktioniert, ist für eine CI-Produktionsfreigabe nicht ausreichend.

Besonders kritisch sind Universal Binaries. Beide Architektur-Slices müssen mit der vorgesehenen Signatur ausgeliefert und im Release-Prozess geprüft werden. Dokumentieren Sie Hash, Logauszug, Signaturprüfung und Genehmigung. Muss für eine Komponente die Systemsicherheit dauerhaft abgesenkt werden, gehört sie auf eine Blockierungs- oder befristete Ausnahmeliste.

Prüfen Sie nicht nur die sichtbare Hauptanwendung. Die häufigsten Rosetta-Abhängigkeiten liegen in Hilfsprozessen, Installationsskripten und Plugins.

Erfassen Sie mindestens:

• ausführbare Dateien und dynamische Bibliotheken
• Kommandozeilenwerkzeuge
• Paketmanager-Verzeichnisse
• CI-Agenten und Runner
• LaunchAgents und Daemons
• Installations-, Vor- und Nachbereitungsskripte
• Plugin-Loader und interne Erweiterungen
• Interpreter und Wrapper
• selbst entwickelte Hilfsprogramme
• vorkompilierte Test- und Packaging-Werkzeuge

Für eine nachvollziehbare Prüfung genügen zunächst wenige Befehle:

file /pfad/zur/datei
lipo -info /pfad/zur/datei
ps -axo pid,command
uname -m

file zeigt die erkannten Architekturen einer Datei. lipo -info hilft bei der Unterscheidung zwischen einem reinen x86_64-Binary und einem Universal Binary. uname -m beschreibt die Architektur der laufenden Shell, nicht automatisch die Architektur jedes gestarteten Unterprozesses. Deshalb müssen Sie auch die tatsächlich laufenden Prozesse und die von CI-Skripten gestarteten Hilfsprogramme untersuchen.

Erweitern Sie die Tabelle um die operative Bedeutung:

Wie prüfen Sie, ob die Mac-CI von Rosetta abhängt?
Starten Sie nicht nur einen Test-Build. Erstellen Sie eine Prozessaufnahme während eines vollständigen CI-Laufs und ordnen Sie jeden x86_64-Prozess seinem aufrufenden Skript und seinem Verantwortlichen zu. Prüfen Sie danach zusätzlich Agent-Start, Cache-Wiederherstellung, Signierung und Neustart. Erst diese Kette zeigt, ob Rosetta eine echte Produktionsabhängigkeit ist.

Achtung: Ein erfolgreicher Build auf einem frisch eingerichteten Knoten beweist keine vollständige Migration. Ein nachgelagerter Signierungsprozess, ein Plugin-Loader oder ein Deployment-Skript kann weiterhin einen Intel-Unterprozess starten.

Native arm64-Werkzeuge sind die erste Wahl. Sie benötigen weniger Übersetzungsabhängigkeit und machen die spätere Stilllegung der Kompatibilität planbarer. Bei eigenen Komponenten sollten Sie prüfen, ob ein arm64-Build genügt oder ob ein Universal Binary für gemischte Entwickler- und CI-Umgebungen erforderlich ist.

Bei jeder Ersetzung gehören diese Nachweise in das Migrationsticket:

• verwendete Version und Installationsquelle
• erkannte Architektur
• reproduzierbarer Installationsschritt
• reales Projekt oder repräsentativer CI-Job
• erzeugte Artefakte und deren Hash
• Test- und Signierungsergebnis
• Rückfallverfahren
• geplantes Ende einer Ausnahme

Wie migrieren Sie x86_64-Build-Werkzeuge nach arm64?
Beginnen Sie mit dem Aufrufer, nicht mit dem sichtbaren Werkzeug. Finden Sie heraus, welches Skript, welcher Agent oder welcher Plugin-Loader die Datei startet. Installieren Sie anschließend die native Version, löschen Sie architekturfremde Caches und führen Sie denselben Projektlauf auf einem isolierten arm64-Knoten aus. Die Migration ist erst abgeschlossen, wenn Funktion und Ausgabe mit dem bisherigen Produktionslauf übereinstimmen.

Geschlossene Werkzeuge ohne native Version kommen in eine Ausnahmegenehmigung. Eine Ausnahme benötigt einen Besitzer, einen konkreten Anwendungsfall, ein Enddatum und ein Risiko. „Wird später ersetzt“ ist kein ausreichender Eintrag.

Der sichere Übergang erfolgt über zwei getrennte Knotenpools:

• Native Pool: arm64-Tools, neue Builds und alle bereits validierten Aufgaben.
• Kompatibilitätspool: Rosetta-abhängige Aufgaben mit dokumentiertem Ausstiegsdatum.

Neue dauerhafte Abhängigkeiten dürfen nicht in den Kompatibilitätspool gelangen. Routing über Labels oder Queues verhindert, dass ein Job zufällig auf dem falschen Knoten landet.

Wählen Sie repräsentative Pull-Request-, Test-, Archivierungs- und Release-Aufgaben. Führen Sie sie auf beiden Pools aus und vergleichen Sie:

• Rückgabecode und Fehlertyp
• Artefakt-Hash und Paketinhalt
• Signatur und Notarisierung
• verwendete Prozesse und Architektur
• Cache-Verhalten
• Queue-Zustand
• Wiederanlauf nach Neustart
• Verhalten bei fehlenden Zertifikaten oder Netzwerkunterbrechung

Konkrete Laufzeiten, Kapazitäten und Fehlerraten dürfen Sie nur aus Ihren CI-Aufzeichnungen oder einer klar gekennzeichneten Messung ableiten. Ohne solche Daten sollten Sie keine prozentuale Leistungsverbesserung behaupten.

Welche CI-Skripte können beim Ende von Rosetta scheitern?
Gefährdet sind Skripte, die Intel-only-Tools direkt starten, x86_64-Pfade fest eintragen, Intel-Paketverzeichnisse wiederherstellen oder Plugins mit nur einem Architektur-Slice laden. Ebenso kritisch sind Vor- und Nachbereitungsskripte, die in einem interaktiven Terminal funktionieren, aber im unbeaufsichtigten Agent-Kontext keine Keychain- oder Berechtigungszugriffe erhalten.

Die Xcode-27-Release-Notes und die macOS-27-Release-Notes müssen vor der Produktionsfreigabe nochmals gegen die finale Version geprüft werden. Änderungen an Supportformulierungen, Toolchain-Anforderungen oder Migrationshinweisen können Ihre Ausnahmeplanung beeinflussen.

Die Zahl der Entwickler ist kein belastbares Maß für die benötigte Mac-CI-Kapazität. Entscheidend sind ausstehende Aufgaben, Parallelität, Laufdauer aus Ihren Aufzeichnungen, Release-Spitzen, Wartungsfenster und die gewünschte Redundanz.

Verwenden Sie ein variables Modell:

• Aufgabenlast: erwartete parallele Jobs
• native Kapazität: nach Dual-Run belegbare arm64-Kapazität
• Kompatibilitätslast: verbleibende Rosetta-Aufgaben
• Spitzenlast: höchste beobachtete Release-Auslastung
• Redundanz: Kapazität bei Ausfall eines Knotens
• Ausstiegsdatum: spätestens geplanter Rückbau des Kompatibilitätspools

Sie können bestehende Apple-Silicon-Knoten für Dual-Run verwenden, wenn ihre Auslastung, Cache-Isolation und Wiederanlaufnachweise dies zulassen. Reicht die Kapazität nicht aus, vergleichen Sie drei Wege:

Wenn Sie für den Dual-Run kurzfristig zusätzliche Apple-Silicon-Knoten benötigen, können Sie bei CALMVPS die verfügbaren Mac-Mietoptionen gegen Ihre internen Beschaffungs- und Freigabeprozesse prüfen. Entscheidend ist nicht ein pauschaler Preisvergleich, sondern ob Zugriff, Root-Rechte, Datenhaltung, Netzwerkpfad und Abnahmetests zu Ihren Vorgaben passen.

Für einen PoC sollte der Mietknoten dieselben realen CI-Aufgaben erhalten wie der geplante Produktionsknoten. Ein synthetischer Test sagt wenig über Signierung, private Abhängigkeiten oder Wiederanlauf aus. Die Kriterien gehören deshalb vor der Bestellung in die Abnahme.

Müssen Sie macOS 27-Kompatibilitätsknoten behalten?
Ja, wenn mindestens eine geschäftskritische Aufgabe weiterhin einen Intel-only-Prozess benötigt und noch kein getesteter Ersatz verfügbar ist. Der Knoten braucht dann eine dokumentierte Aufgabe, einen Besitzer, eine Sicherheitsprüfung und ein verbindliches Ausstiegsdatum. Nein, wenn alle produktiven Aufgaben auf arm64 validiert sind und der Dual-Run keine offenen Unterschiede zeigt.

Verwenden Sie diese Freigaberegeln:

• Upgrade verschieben: Wenn Prozessinventur oder Signierungsprüfung unvollständig ist.
• Teilweise upgraden: Wenn der native Pool freigegeben ist, aber definierte Rosetta-Ausnahmen bestehen.
• Kompatibilitätspool verkleinern: Wenn eine Aufgabe auf arm64 reproduzierbar läuft und ihr Artefakt geprüft wurde.
• Neue Knoten beschaffen oder mieten: Wenn Dual-Run und Release-Spitzen die vorhandene native Kapazität übersteigen.
• Migration blockieren: Wenn Sicherheitsoptionen abgesenkt werden müssen oder der Wiederanlauf nicht unbeaufsichtigt funktioniert.

Für ein Unternehmen mit strengen DSGVO-Anforderungen müssen zusätzlich Datenflüsse, Zugriffskontrolle, Protokollierung, Zertifikatsverwaltung und Löschung nach Ende des Tests dokumentiert werden. Ein Remote-Knoten ist damit nicht automatisch genehmigt; er ist ein Infrastrukturbaustein, der dieselbe Prüfung wie eigene Hardware benötigt.

1. Verantwortung festlegen: Benennen Sie IT, Plattform, Toolchain, Release und Einkauf als zuständige Rollen.
2. Assets erfassen: Prüfen Sie Binärdateien, Agenten, Plugins, Skripte, Bibliotheken, Daemons und Caches.
3. Architektur nachweisen: Sichern Sie file, lipo, Prozess- und Agent-Logs als Migrationsevidenz.
4. Entscheidung treffen: Ersetzen, als arm64 oder Universal Binary neu bauen oder befristet isolieren.
5. Pools trennen: Definieren Sie native und kompatible Routing-Regeln ohne gemeinsamen Architektur-Cache.
6. Dual-Run starten: Testen Sie reale Build-, Test-, Archivierungs- und Release-Aufgaben.
7. Sicherheit abnehmen: Prüfen Sie Keychain, Signierung, Notarisierung, Plugins und Neustart.
8. Kapazität modellieren: Nutzen Sie reale Aufgabenlast, Spitzen, Redundanz und das Ausstiegsdatum.
9. macOS 27 freigeben: Aktualisieren Sie erst, wenn die produktiven Aufgaben native Nachweise besitzen.
10. Ausnahmen abbauen: Entfernen Sie Kompatibilitätsknoten nach belegter Migration, nicht nach Kalenderdatum allein.

Wenn Ihre derzeitige Lösung aus gekauften Macs besteht, entstehen während dieser Phase oft drei konkrete Nachteile: zusätzliche Hardware muss beschafft werden, freie Kapazität für den Dual-Run fehlt und Wartung oder Austausch bindet interne IT-Ressourcen. Ein kurzfristiger Cloud- oder Mietpool löst diese Punkte nicht automatisch, kann aber für einen abgegrenzten PoC, eine Release-Spitze oder eine parallele Validierung die bessere operative Option sein. Mit CALMVPS können Sie dafür einen isolierten Apple-Silicon-Testknoten einplanen und die Entscheidung anschließend anhand Ihrer echten CI-Nachweise treffen. Geeignete Optionen und Abrechnungsmodelle finden Sie in der Übersicht zur Mac-Miete von CALMVPS.

Der richtige nächste Schritt ist daher nicht die pauschale Abschaltung von Rosetta und auch nicht das unbegrenzte Festhalten am Kompatibilitätspool. Erfassen Sie die x86_64-Abhängigkeiten, beweisen Sie native arm64-Ausführung mit echten Produktionsaufgaben und halten Sie nur jene Kompatibilitätsknoten vor, für die ein genehmigter, terminierter Ausnahmefall existiert.