Müssen macOS-27-CI-Knoten auf Apple Silicon wechseln? Auswahl 2026

Apple nennt macOS 27 ausschließlich für Apple-Silicon-Macs als kompatibel; macOS 26 ist die letzte Version mit Unterstützung für Intel-Macs und Rosetta (Apples Kompatibilitätsangaben zu macOS 27, Apples Hinweis zu Rosetta). Ersetzen Sie deshalb nicht pauschal alle CI-Knoten: Richten Sie für Jobs, die macOS 27 benötigen, eine Apple-Silicon-Ausführungsumgebung ein und behalten Sie Intel für nachgewiesene Altanforderungen. Ob Sie einen Knoten mieten, kaufen oder zunächst abwarten, entscheiden Sie anhand der Zielsysteme, Werkzeugketten und tatsächlichen Ergebnisse Ihrer CI-Läufe.

Dieser Leitfaden richtet sich an Sie, wenn Sie macOS-App-Builds betreuen und klären müssen, welche Aufgaben auf Intel-Knoten bleiben können.
Er hilft DevOps- und Plattformteams, neue und bestehende Runner sinnvoll zuzuordnen und die Wartungsgrenzen festzulegen.
Als Entwicklungsverantwortliche oder Entwicklungsverantwortlicher erhalten Sie Kriterien für den Vergleich von Anschaffung, Remote-Mac-Nutzung und Parallelbetrieb.

Zuletzt geprüft am 16.10.2026. Die Angaben zu macOS 27, Intel, Rosetta und Xcode wurden anhand der verlinkten Apple-Developer-Seiten gegengeprüft. Da Apple die System- und Werkzeuganforderungen mit neuen Releases ändern kann, kontrollieren Sie die jeweilige Kompatibilität erneut, bevor Sie einen Knoten freigeben.

Systemberechtigung und Binärkompatibilität

Bei der Auswahl von macOS-27-CI-Knoten sind zwei Fragen getrennt zu beantworten: Kann der Host das gewünschte macOS ausführen, und kann das Projekt samt Werkzeugen auf seiner Architektur arbeiten? Eine App, die als Universal Binary vorliegt, macht einen Intel-Host nicht nachträglich zu einem für macOS 27 geeigneten Host. Apple beschreibt die Systemvoraussetzungen und die Architektur von Universal Binaries getrennt (Dokumentation zu Universal Binaries für macOS).

Für Ihre Infrastrukturplanung ergeben sich daraus klare Grenzen:

• macOS 27 als Host: Dafür muss ein kompatibler Apple-Silicon-Mac bereitstehen. Ein Intel-Knoten kann diese Aufgabe nicht übernehmen.
• macOS 26 als Host: Apple bezeichnet diese Version als letzte macOS-Version mit Unterstützung für Intel-Macs und Rosetta. Prüfen Sie zusätzlich, ob die benötigte Xcode-Version und sämtliche Abhängigkeiten zu dieser Umgebung passen.
• Intel- oder Rosetta-Prüfung: Solche Jobs können weiterhin sinnvoll sein, wenn eine Abhängigkeit oder ein Release-Prozess genau diese Ausführungsumgebung verlangt. Sie ersetzen aber nicht automatisch einen nativen Test auf Apple Silicon.

Das sind Anforderungen an das Hostsystem, keine Zusage, dass jeder Build nach einer Migration fehlerfrei läuft. Die Systemberechtigung entscheidet, ob sich das gewünschte macOS auf dem Host installieren lässt. Die Werkzeugkette und Ihr Projekt bestimmen, ob der konkrete Job ausführbar ist und sein Ergebnis den Release-Anforderungen genügt.

Achtung: Verwechseln Sie einen gestarteten Prozess nicht mit einer bestandenen Release-Prüfung. Architektur, Abhängigkeiten, Tests und Signierung müssen im vorgesehenen Zielpfad ebenfalls geprüft werden.

Xcode, Hostsystem und Zielplattform

Xcode-Version, Host-macOS, SDK und Deployment Target hängen zusammen, sind aber nicht austauschbar. Die Apple-Tabelle zu den Xcode-Systemanforderungen zeigt, welches macOS eine bestimmte Xcode-Ausgabe voraussetzt. Die Apple-Release-Seite für Entwicklerwerkzeuge hilft Ihnen, den Status einer Ausgabe nachzuvollziehen. Verwenden Sie diese Angaben für die konkret eingesetzte Version. Leiten Sie aus einer einzelnen Kompatibilitätsangabe keine Freigabe für Ihre gesamte Pipeline ab.

Erfassen Sie für jeden Workflow mindestens die folgenden Merkmale:

• Host-macOS: Welches System ist auf dem Runner installiert? Verlangt der Job ausdrücklich eine bestimmte Hostversion?
• Xcode: Welche Ausgabe wählt der Workflow aus? Ist sie fest vorgegeben, oder hängt der Job von einer veränderlichen Standardauswahl ab?
• SDK: Welches SDK wird für Build und Tests verwendet? Passt es zur Entwicklungsumgebung, die Ihr Projekt voraussetzt?
• Deployment Target: Für welche Betriebssystemversion soll das erzeugte Produkt lauffähig sein? Das Zielsystem des Produkts ist nicht dasselbe wie das Betriebssystem des CI-Hosts.
• Aufgabenumfang: Baut der Job nur, oder führt er außerdem Tests, Archivierung, Export und Verteilung durch? Diese Schritte können zusätzliche Anforderungen mitbringen.

Ein Xcode-Release kann auf einem bestimmten Hostsystem unterstützt sein, ohne dass damit alle Simulatoren, Plug-ins, Skriptwerkzeuge oder Release-Schritte Ihrer Pipeline abgedeckt sind. Ebenso beweist ein erfolgreicher Build nicht, dass Tests, Archivierung und Signierung auf einem neuen Knoten dieselben Voraussetzungen erfüllen.

Legen Sie für jeden produktiven Workflow eine nachprüfbare Kombination aus Host-macOS, Xcode, SDK, Deployment Target und Architektur fest. Wenn Apple eine benötigte Kombination nicht als unterstützt aufführt, verschieben Sie den betroffenen Job nicht auf Verdacht. Lassen Sie ihn auf der bestehenden unterstützten Spur oder warten Sie auf eine offiziell unterstützte Kombination und einen erfolgreichen Test mit Ihrem Projekt.

Architekturabhängigkeiten und reale Projektlast

Die Architekturfrage wird erst entscheidungsrelevant, wenn Sie wissen, was Ihr Repository tatsächlich voraussetzt. Prüfen Sie neben dem Hauptprojekt auch native Erweiterungen, vorgefertigte Bibliotheken, Kommandozeilenprogramme und Testwerkzeuge. Eine universelle App kann mehrere Binärarchitekturen enthalten; sie garantiert jedoch nicht, dass jede Abhängigkeit für beide Architekturen verfügbar ist.

Sichten Sie Ihre Abhängigkeiten anhand dieser Merkmale:

• Native Erweiterungen: Ermitteln Sie, ob Erweiterungen im Build erzeugt oder als vorgefertigte Binärdateien eingebunden werden. Notieren Sie die unterstützten Architekturen.
• Binärabhängigkeiten: Prüfen Sie, ob Bibliotheken für Intel, Apple Silicon oder beide Architekturen vorliegen. Gehört eine Abhängigkeit nur zu einer Architektur, muss diese Einschränkung in der Job-Zuordnung sichtbar sein.
• Skripte und Werkzeuge: Halten Sie fest, welche Interpreter, Build-Werkzeuge und Hilfsprogramme ausgeführt werden und ob sie bestimmte Architekturannahmen enthalten.
• Tests: Trennen Sie Tests, die lediglich Anwendungscode ausführen, von Tests, die bestimmte Host-, Simulator- oder Binärbedingungen prüfen.
• Rosetta-Annahmen: Suchen Sie danach, ob ein Test Rosetta voraussetzt und ob er eine Übergangsanforderung oder einen tatsächlich nötigen Release-Nachweis abbildet.

Die praktische Messlatte lautet nicht „Der Build startet“, sondern „Build, Tests und Ausgabe erfüllen die Anforderungen des Zielprozesses“. Ein Lauf auf Apple Silicon kann erfolgreich kompilieren, während eine benötigte Intel-Bibliothek fehlt. Ein erfolgreicher Intel-Lauf beweist umgekehrt nicht, dass Ihr Projekt für einen Apple-Silicon-Release vollständig geprüft wurde.

Nehmen Sie auch nicht an, ein Architekturwechsel erhöhe automatisch die Build-Leistung. Ohne vergleichbare eigene Läufe unter kontrollierten Bedingungen ist eine Leistungsbehauptung keine belastbare Entscheidungsgrundlage. Erfassen Sie stattdessen die für Ihr Projekt relevanten Indikatoren: Erfolg oder Fehlschlag je Workflow, verfügbare Abhängigkeitsversionen, Testabdeckung und reproduzierbare Artefakte. Angaben zu Laufzeit oder Durchsatz sollten aus Ihren eigenen CI-Protokollen stammen.

Wartungsaufwand und Sicherheitsgrenzen

Ein zusätzlicher Knoten bedeutet mehr als eine weitere Maschine. Ihr Team muss Systemupdates, installierte Xcode-Versionen, Secrets, Runner-Zuordnung und Wiederherstellung konsistent verwalten. Werden beide Architekturen auf einem gemeinsam genutzten Host abgebildet, können Updates oder Konfigurationsänderungen mehrere Jobtypen betreffen. Getrennte Knoten schaffen eine klarere Abgrenzung, benötigen aber eigene Pflege und eine nachvollziehbare Zuordnung der Workflows.

Bei selbstverwalteten Runnern sollten Sie prüfen, wie Jobs registriert und aktualisiert werden und wie ein Runner nach einem Fehler wieder in Betrieb genommen wird. Die Dokumentation zu selbstgehosteten Runnern beschreibt wichtige Betriebsaspekte. Wenn externe Beiträge Workflows auslösen können, betrachten Sie Berechtigungen und den Zugriff auf Geheimnisse gesondert. Die Sicherheitshinweise zu pull_request_target zeigen, weshalb ein vertrauenswürdiger Runner nicht unbedacht mit fremdem Code und privilegierten Zugangsdaten verbunden werden sollte.

Auch die Signierung gehört in die Architekturentscheidung. Prüfen Sie, wo Zertifikate und andere Signierinformationen liegen, welche Jobs sie benötigen und wie Sie den Zugriff begrenzen. Apples Dokumentation zur Signierung von Mac-Apps für die Verteilung erläutert den Signierkontext. Für Ihre CI zählt nicht nur, ob ein Zertifikat verfügbar ist, sondern auch, ob ein fehlgeschlagener oder nicht vertrauenswürdiger Job darauf zugreifen könnte.

Bewerten Sie die Wartung anhand überprüfbarer Indikatoren:

• Läuft ein repräsentativer Job nach einem geplanten System- oder Werkzeugupdate weiter?
• Sind verwendete Xcode-Versionen und Abhängigkeiten dokumentiert und reproduzierbar eingerichtet?
• Werden Jobs eindeutig einem Intel- oder Apple-Silicon-Knoten zugewiesen?
• Sind Secrets und Signiermaterial auf die Workflows beschränkt, die sie benötigen?
• Kann Ihr Team nach einem Knotenausfall eine geeignete Umgebung wiederherstellen und den betroffenen Job erneut ausführen?

Betriebshinweis: Führen Sie eine Wiederherstellungsprobe mit einem tatsächlichen Projektworkflow durch. Ein dokumentierter Plan ist erst dann ein belastbarer Rückfallweg, wenn ein Teammitglied ihn ohne den ausgefallenen Knoten praktisch ausführen kann.

Gesamtbetriebskosten ohne Schätzpreise

Ein fairer Kostenvergleich braucht keinen erfundenen Pauschalpreis. Er braucht eine Kostenstruktur, in die Sie Ihre Teamdaten und die konkreten Bedingungen einer Beschaffungs- oder Mietoption eintragen. Ohne verifizierte Preise, Ausstattung und Nutzungsdauer lässt sich nicht seriös behaupten, dass Kaufen, Mieten oder Beibehalten günstiger ist.

Berücksichtigen Sie bei jeder Variante dieselben Kostenpositionen:

• Knotenbeschaffung: Kauf, Miete oder Weiterbetrieb. Prüfen Sie die konkreten Angebotsbedingungen statt allgemeiner Annahmen.
• Nutzungszeitraum: Ordnen Sie die geplante Nutzung den tatsächlich benötigten Release- und Wartungszeiträumen zu.
• Pflegeaufwand: Erfassen Sie Arbeit für Updates, Werkzeuginstallation, Runner-Verwaltung, Fehleranalyse und Wiederherstellung.
• Leerlaufkapazität: Nutzen Sie Ihre Workflow-Protokolle, um zu beurteilen, ob ein dedizierter Knoten regelmäßig ausgelastet ist oder häufig ungenutzt bleibt.
• Parallelbetrieb: Berücksichtigen Sie die doppelte Pflege während der Übergangsphase, einschließlich getrennter Abhängigkeiten und zusätzlicher Abnahme.
• Rückfall und Ausfall: Beziehen Sie ein, welcher Aufwand entsteht, um nach einem fehlgeschlagenen Update oder einem Knotenausfall weiterzubauen.

Belegen Sie jede Position mit internen Nutzungs- und Wartungsaufzeichnungen oder den Bedingungen der konkreten Lösung, die Sie prüfen. Auf der VMSPIN-Preisseite können Sie die dort ausgewiesenen Angebotsangaben nachsehen. Übernehmen Sie daraus nur Informationen, die tatsächlich genannt sind. Fehlende Angaben zu Konfiguration, Verfügbarkeit oder Leistung bleiben offene Fragen und dürfen nicht durch Schätzwerte ersetzt werden.

Für Teams in Deutschland gehören Datenschutz und Zugriffskontrolle in die Bewertung. Klären Sie, welche Repository-Inhalte, Artefakte und Geheimnisse in der ausgewählten Umgebung verarbeitet werden und wer darauf Zugriff erhält. Prüfen Sie Ihre Anforderungen nach DSGVO anhand der konkreten Vertrags- und Betriebsinformationen statt anhand einer pauschalen Bezeichnung wie „Cloud“. Stabilität bedeutet nicht nur, dass ein Host erreichbar ist: Auch wiederholbare Builds und eine kontrollierte Fortsetzung nach einem Fehler zählen.

Auswahlhilfe nach Workflow-Bedingungen

Treffen Sie die Entscheidung nicht für „die CI“ als Ganzes, sondern für die Aufgaben, die Sie auf den Knoten ausführen. Verwenden Sie diese Checkliste für die Zuordnung:

• [ ] macOS 27 ist als Hostsystem erforderlich. Weisen Sie den Workflow einem geeigneten Apple-Silicon-Knoten zu. Ein Intel-Mac ist dafür keine Alternative.
• [ ] Eine Aufgabe verlangt ausdrücklich Intel oder eine Prüfung unter der älteren Umgebung. Behalten Sie dafür eine separate Intel-Spur, sofern Hostsystem und Xcode-Version laut Apple unterstützt werden.
• [ ] Das Projekt muss beide Architekturen oder mehrere Hostsysteme abdecken. Starten Sie mit getrennten Spuren. Fassen Sie sie erst zusammen, wenn die erforderlichen Aufgaben und Ergebnisse auf dem vorgesehenen Zielpfad nachweislich abgedeckt sind.
• [ ] Weder macOS 27 noch eine konkrete Apple-Silicon-Anforderung kommt in Ihren Workflows vor. Ersetzen Sie nicht allein wegen des Versionswechsels Ihre gesamte Infrastruktur. Prüfen Sie die bestehenden Hosts und planen Sie Änderungen erst nach der Kompatibilitätsprüfung.
• [ ] Kompatibilität oder Wiederherstellung ist noch nicht belegt. Verschieben Sie die endgültige Beschaffung oder lassen Sie den betroffenen Job vorerst auf seiner bestehenden, unterstützten Spur.

Auswertung: Ist das erste Kästchen erfüllt, braucht der betreffende Job eine Apple-Silicon-Spur. Ist nur das zweite erfüllt, bleibt eine geprüfte Intel-Spur für diese Aufgabe sinnvoll. Sind die ersten beiden Bedingungen gleichzeitig erfüllt, betreiben Sie vorerst beide Spuren. Trifft keine der Bedingungen zu, behalten Sie den bestehenden Knoten bis zur nächsten konkreten System- oder Werkzeuganforderung und investieren Sie zuerst in einen repräsentativen Kompatibilitätstest.

Ein bestandener Apple-Silicon-Lauf belegt nur die geprüfte Kombination aus Projekt, Werkzeugen und Host. Er rechtfertigt nicht automatisch, Intel-Aufgaben zu streichen, wenn Ihre Release- oder Kompatibilitätsanforderungen diese weiterhin voraussetzen. Ebenso ist eine vorübergehend notwendige Intel-Spur kein Grund, alle neuen macOS-27-Aufgaben dort festzuhalten.

Als Entscheidungsnachweis genügt kein einzelner grüner Build. Wählen Sie eine repräsentative Gruppe produktiver Aufgaben: Kompilierung, Tests, Archivierung und die jeweils erforderlichen Verteilungs- oder Signierschritte. Führen Sie sie auf der vorgesehenen Spur aus, sichern Sie die Protokolle und prüfen Sie, ob das erwartete Artefakt entsteht. Wiederholen Sie die Prüfung mit einem gezielten Wiederherstellungsszenario, etwa nach einem fehlgeschlagenen Job oder einer erforderlichen Neuinstallation des Knotens.

Meilensteine für die Umstellung

Planen Sie die Auswahl anhand überprüfbarer Freigabepunkte statt eines pauschalen Migrationstermins.

Vor der Zuweisung: Erfassen Sie pro Job die benötigte Hostversion, Xcode-Ausgabe, SDK, Deployment Target, Architektur und erforderlichen Geheimnisse. Kennzeichnen Sie, welche Bedingungen durch eine veröffentlichte Apple-Angabe belegt sind und welche noch einen Projekttest benötigen.

Vor dem ersten produktiven Lauf: Installieren oder wählen Sie die geforderte Werkzeugkette, begrenzen Sie den Zugriff auf Signierdaten und ordnen Sie den Job eindeutig seiner Spur zu. Ein macOS-27-Workflow benötigt einen geeigneten Apple-Silicon-Host; eine Intel-Spur bleibt für nachgewiesene Altanforderungen getrennt.

Bei der Abnahme: Prüfen Sie Build, Tests, Archivierung und notwendige Signierschritte mit demselben Repository und denselben Workflow-Einstellungen, die für die Freigabe vorgesehen sind. Bewahren Sie die CI-Protokolle so auf, dass Fehlschläge und Unterschiede zwischen den Spuren nachvollziehbar bleiben.

Vor dem Rückbau: Beenden Sie die Intel-Spur erst, wenn die Aufgaben, für die sie besteht, auf der neuen Spur erfolgreich abgedeckt oder ausdrücklich aus dem Releaseumfang entfernt wurden. Dokumentieren Sie außerdem, wer im Fehlerfall die Wiederherstellung übernimmt und wie die benötigte Werkzeugkette erneut eingerichtet wird.

Antworten zur CI-Knotenauswahl

Kann ein Intel-Runner macOS 27 ausführen? Nein. Für macOS 27 ist ein unterstützter Apple-Silicon-Host erforderlich. Das gilt unabhängig davon, ob Ihr Anwendungscode als Universal Binary vorliegt.

Muss jede macOS-CI-Aufgabe auf Apple Silicon umziehen? Nein. Behalten Sie Intel für Aufgaben, deren Anforderungen es nachweislich voraussetzen, und weisen Sie nur die macOS-27-Jobs zwingend einem geeigneten Host zu.

Können macOS-27- und ältere Xcode-Jobs denselben Knoten nutzen? Das hängt davon ab, ob Hostsystem und Xcode-Version für die jeweilige Kombination unterstützt sind. Prüfen Sie die Apple-Systemanforderungen je Job und vermeiden Sie eine Zuweisung allein aufgrund ähnlicher Projektdateien.

Wann ist eine doppelte Spur entbehrlich? Wenn die bisherigen Intel-Prüfungen keinen erforderlichen Release- oder Kompatibilitätsnachweis mehr liefern und die neue Spur die benötigten Aufgaben sowie die Wiederherstellung abdeckt. Halten Sie sie länger vor, solange diese Bedingungen nicht erfüllt sind.

Entscheidung vor Kauf, Miete oder Aufschub

Die Wahl zwischen Intel, Apple Silicon und Parallelbetrieb sollte sich an den tatsächlichen Aufgaben Ihrer Pipeline orientieren. Wenn Ihre bestehende Infrastruktur nur eine Hostumgebung und wenige, gut dokumentierte Werkzeuge bedienen muss, kann der Weiterbetrieb sinnvoll sein. Müssen Sie macOS 27 ausführen, benötigen Sie einen passenden Apple-Silicon-Host. Wenn beide Anforderungen nebeneinander bestehen, vergleichen Sie zunächst die zusätzliche Pflege und die tatsächliche Nutzung beider Spuren, bevor Sie eine davon abschalten.

Ein eigener Knoten bedeutet Anschaffung oder gebundene Hardware, laufende Pflege und möglicherweise ungenutzte Kapazität, wenn die CI-Aufträge schwanken. Ein Remote Mac kann diese Bindung verringern, ersetzt aber weder die Prüfung der konkreten Xcode- und Systemkombination noch Ihre Verantwortung für Secrets, Runner-Sicherheit und Wiederherstellung. Wenn Sie dafür keine eigene Hardware anschaffen möchten, prüfen Sie die auf der VMSPIN-Angebotsseite ausgewiesenen Optionen anhand Ihrer Zielsysteme und Werkzeugkette. Nicht aufgeführte Konfigurationen oder Kompatibilitäten sollten Sie vor einer Entscheidung ausdrücklich klären.

Wenn Sie einen Knoten nur für eine begrenzte Migration, einen Abnahmelauf oder eine zusätzliche Apple-Silicon-Spur benötigen, kann die Miete über VMSPIN eine flexible Alternative zum sofortigen Kauf sein. Entscheiden Sie erst nach einem erfolgreichen Test Ihres Workflows und anhand der tatsächlich angebotenen Bedingungen. Bei dauerhaft hoher Auslastung oder Anforderungen an lokale Anschlüsse kann ein eigener Mac besser passen.