2. November 2026: GitHub hat die Labels macos-14, macos-14-large und macos-14-xlarge außer Betrieb genommen. Teams sollten diese Runner nicht mehr als verlässliche Grundlage einplanen. Für die GitHub Actions macOS 14 Runner Migration gilt: Wählen Sie einen aktuell dokumentierten Ersatz anhand von macOS-, Xcode- und Architekturbedarf aus und testen Sie ihn isoliert, bevor Sie produktive Builds umschalten. Ein pauschaler Wechsel auf latest ist keine belastbare Migrationsstrategie. GitHub bestätigt den Abschalttermin und nennt die betroffenen Labels.

Dieser Leitfaden richtet sich an Teams, deren Workflows noch macos-14, macos-14-large oder macos-14-xlarge verwenden und die betroffene Aufgaben zuerst erfassen müssen.
CI-Verantwortliche für Signierung, Tests und Veröffentlichung erhalten Prüfkriterien für die Abnahme der neuen Umgebung.
DevOps- und Plattformteams können damit Voraussetzungen für Umschaltung, Rückfall und laufenden Betrieb festlegen.

Zuletzt geprüft am 08.11.2026; abgeglichen mit der Dokumentation zu gehosteten Runnern und dem Runner-Images-Repository. Die verfügbaren Labels und installierten Werkzeuge können sich ändern; prüfen Sie deshalb die genannten Quellen erneut unmittelbar vor der Umstellung.

Runner-Labels zuerst nach tatsächlicher Verfügbarkeit auswählen

Die macos-14 Runner-Ausmusterung betrifft nicht nur den Betriebssystemnamen in einer YAML-Datei. Der Wechsel verändert die bereitgestellte Image-Version und kann dadurch Werkzeuge, SDKs, Standardpfade oder vorhandene Vorannahmen in Skripten verändern. GitHub nennt die betroffenen Labels in der Rückzugsankündigung; welche Ersatz-Labels und Softwarestände derzeit angeboten werden, ist dagegen anhand der aktuellen Runner-Dokumentation und des Image-Inventars zu prüfen.

Gehen Sie bei der Auswahl nicht von einer allgemeinen Empfehlung aus, sondern von den Anforderungen Ihres Workflows:

  • Wenn ein dokumentiertes Label die erforderliche macOS-Version, Xcode-Umgebung und Architektur bereitstellt, dann nehmen Sie es als Kandidaten in einen isolierten Testlauf auf.
  • Wenn ein Wechsel auf macos-15 oder macos-26 erwogen wird, dann kontrollieren Sie zuerst, ob genau dieses Label aktuell verfügbar ist und welche Software das zugehörige Image enthält. Der Labelname allein garantiert keinen bestimmten Xcode-Stand.
  • Wenn die Pipeline auf einem selbst verwalteten Runner besondere Werkzeuge oder lokale Konfigurationen voraussetzt, dann dokumentieren Sie diese Unterschiede, bevor Sie gehostete und selbst verwaltete Ausführungen als gleichwertig behandeln.
  • Wenn kein dokumentiertes Label die Anforderungen erfüllt, dann halten Sie die betroffenen Aufgaben getrennt und bewerten Sie eine alternative Ausführungsumgebung, statt auf ein nicht bestätigtes Image zu setzen.

Betroffene Workflows nachvollziehbar erfassen

Suchen Sie in allen Workflow-Dateien nach den drei zurückgezogenen Labels. Eine Suche im Repository findet jedoch nicht zwingend jeden produktiven Verweis: Auch wiederverwendbare Workflows, gemeinsam gepflegte Aktionen und separate Release-Repositories können eigene Runner-Auswahlregeln enthalten. Ergänzen Sie die Textsuche deshalb durch einen Blick in die historischen Laufprotokolle und die Konfiguration der tatsächlich ausgelösten Jobs.

Notieren Sie pro Aufgabe den verwendeten Runner, den Branch- und Trigger-Kontext, die aufgerufenen Build- und Testbefehle sowie die erwarteten Artefakte. Wichtig ist, ob ein Job nur kompiliert, Simulator-Tests ausführt, signiert oder ein Archiv zur Veröffentlichung erzeugt. Ein einzelner Workflow kann mehrere unterschiedliche Anforderungen enthalten; behandeln Sie ihn nicht automatisch als eine austauschbare Einheit.

Hinweis: Ein Workflow, der nach der Änderung startet, ist noch nicht migriert. Der Start belegt nur, dass ein Runner den Job angenommen hat; er sagt nichts darüber aus, ob Toolchain, Architektur und Auslieferungsergebnis noch stimmen.

Xcode und SDK getrennt vom Betriebssystem abnehmen

Ein neues macOS-Image bringt nicht automatisch die Xcode-Version mit, die ein Projekt benötigt. Ebenso beweist ein installiertes Xcode nicht, dass das Projekt mit der enthaltenen SDK-Version, den verwendeten Build-Einstellungen oder den vorgesehenen Simulatorzielen kompatibel ist. Prüfen Sie die Anforderungen daher gegen die konkreten Angaben in Apples Xcode-26-Versionshinweisen und den Systemanforderungen von Xcode.

Trennen Sie dabei vier Fragen, die in einer Runner-Migration leicht vermischt werden:

  • Welche macOS-Version benötigt das gewählte Xcode?
  • Welche Xcode- und SDK-Version ist für das Projekt freigegeben?
  • Welche Zielplattformen und Simulatoren müssen im CI verfügbar sein?
  • Wird eine Vorabversion benötigt, oder muss die Pipeline ausschließlich mit einer stabilen Veröffentlichung laufen?

Die letzte Unterscheidung gehört in die Freigabekriterien. Eine Beta-Version kann für einen gezielten Kompatibilitätstest sinnvoll sein, sollte aber nicht unbemerkt zur Produktionsgrundlage werden. Halten Sie in den Workflow-Protokollen fest, welches Xcode tatsächlich ausgewählt und gestartet wurde. Prüfen Sie außerdem, ob ein Job die Version über den Pfad, eine Auswahlaktion oder eine Umgebungsvariable bestimmt: Ein erfolgreicher Wechsel des Runner-Labels kann sonst unbemerkt eine andere Xcode-Installation aktivieren.

Für die Xcode-CI-Umgebung empfiehlt sich eine explizite Erwartung statt einer impliziten Voreinstellung. Lassen Sie den Job zu Beginn die relevanten Versionsinformationen ausgeben und vergleichen Sie sie mit der freigegebenen Projektbasis. Schlägt diese Vorprüfung fehl, sollte der Job abbrechen, bevor er Abhängigkeiten lädt oder Artefakte erzeugt. So wird ein ungeeigneter Runner als Umgebungsfehler erkannt und nicht erst durch schwerer zuzuordnende Compiler- oder Testfehler sichtbar.

Architektur und native Abhängigkeiten einzeln prüfen

Ein Labelwechsel kann zugleich einen Wechsel der verfügbaren CPU-Architektur bedeuten. Das ist für Projekte mit vorkompilierten Bibliotheken, Architekturprüfungen oder speziell angepassten Skripten relevant. Verlassen Sie sich deshalb nicht auf den Betriebssystemnamen oder auf den Erfolg eines einfachen Build-Aufrufs: Erfassen Sie die tatsächliche Runner-Architektur während des Testlaufs und gleichen Sie sie mit den Projektanforderungen ab.

Prüfen Sie native Abhängigkeiten möglichst in getrennten Phasen:

  • Installation: Können Paketmanager und Installationsskripte die benötigten Pakete in der neuen Umgebung beziehen? Werden Binärpakete passend zur Architektur ausgewählt?
  • Kompilierung: Werden sämtliche Ziele gebaut, oder überspringen bedingte Skripte einzelne Module? Kontrollieren Sie Architekturannahmen in Shell-Skripten und Build-Konfigurationen.
  • Test: Starten die relevanten Unit- und Simulator-Tests tatsächlich, und verwenden sie die erwarteten Binärdateien?
  • Lieferung: Ist das erzeugte Archiv für die vorgesehenen Zielgeräte und den nachgelagerten Signierungs- und Veröffentlichungsprozess geeignet?

Bei einem Fehler sollten Sie zuerst bestimmen, welche Phase abweicht. Eine erfolgreiche Abhängigkeitsinstallation belegt nicht, dass das Projekt korrekt kompiliert wurde; ein erfolgreicher Build wiederum belegt nicht, dass native Tests und Simulatoren funktionieren. Diese Trennung verhindert, dass ein geändertes Paket oder ein übersprungenes Testziel fälschlich als Runner-Kompatibilität bewertet wird.

Entscheidungszweige für Architektur und Ausführungsort

  • Wenn alle benötigten Abhängigkeiten für die Architektur des dokumentierten gehosteten Runners verfügbar sind und die repräsentativen Tests bestehen, dann kann dieser Runner-Kandidat in die Abnahme gehen.
  • Wenn eine Abhängigkeit zwingend eine andere Architektur voraussetzt, dann suchen Sie nicht nach einem bloß ähnlich benannten Betriebssystem-Label. Prüfen Sie ein dokumentiertes Runner-Angebot mit passender Architektur oder halten Sie einen getrennten Ausführungspfad vor.
  • Wenn ein Teil der Arbeit auf einem gehosteten Runner und ein anderer nur in einer kontrollierten Mac-Umgebung zuverlässig ausführbar ist, dann lassen Sie die Aufgaben zunächst getrennt laufen und vergleichen Sie ihre Ergebnisse, bevor Sie Zuständigkeiten zusammenführen.
  • Wenn weder die Architektur noch die Herkunft der Abhängigkeiten reproduzierbar festgehalten werden, dann ist die Migration noch nicht freigabefähig. Ergänzen Sie die Protokollierung und wiederholen Sie den Test mit demselben Commit.

Übergabe mit Build-, Test- und Signierungsnachweisen absichern

Eine vollständige Abnahme muss den realen Zweck des Jobs widerspiegeln. Ein bloßer Clean Build ist ein wichtiger Nachweis, reicht aber für eine Pipeline, die Simulatoren, Signierung oder Veröffentlichungsarchive nutzt, nicht aus. Führen Sie daher repräsentative Aufgaben auf dem Kandidaten-Runner aus und vergleichen Sie Ergebnisse und Protokolle mit einer bekannten erfolgreichen Basis.

Geordnete Prüfschritte für den Migrationslauf

  1. Ausgangszustand sichern. Halten Sie den Commit, den bisherigen Runner und die relevanten Angaben zu macOS, Xcode, SDK und Architektur fest. Sammeln Sie Build-Protokolle, Testergebnisse und Archivinformationen aus einer erfolgreichen Ausführung. Ohne diese Referenz bleibt später unklar, ob eine Abweichung neu ist oder bereits vorher bestand.

  2. Einen separaten Kandidatenjob einrichten. Ändern Sie nicht sofort den produktiven Workflow. Lassen Sie den Ersatz-Runner in einem separaten Job oder einer kontrollierten Testkonfiguration laufen. Beide Jobs sollten denselben Commit und dieselben fachlichen Build- und Testbefehle verwenden, soweit das parallel möglich ist.

  3. Umgebung und Abhängigkeiten protokollieren. Geben Sie die tatsächlichen Versionen der benötigten Werkzeuge aus und halten Sie fest, wie Pakete bezogen wurden. Wenn Caches verwendet werden, kontrollieren Sie, ob deren Schlüssel Betriebssystem, Toolchain oder Architektur ausreichend unterscheiden. GitHub beschreibt das Verhalten von Abhängigkeits-Caches für Actions; ein Cache-Treffer allein ist aber kein Beleg dafür, dass der wiederverwendete Inhalt zur neuen Umgebung passt.

  4. Build und Tests getrennt ausführen. Führen Sie einen sauberen Build aus und danach die vorgesehenen Tests. Prüfen Sie ausdrücklich, ob die erwarteten Simulatorziele verfügbar sind und Testläufe wirklich gestartet wurden. Achten Sie auf Jobs, die wegen Bedingungen, fehlender Ziele oder geänderter Skripte erfolgreich enden, ohne die vorgesehene Prüfung auszuführen.

  5. Signierung und Archivierung kontrollieren. Verifizieren Sie, dass Zertifikate, Profile, Keychains und projektbezogene Signierungseinstellungen im neuen Kontext funktionieren. Prüfen Sie das erzeugte Archiv sowie die nachgelagerten Schritte, mit denen es geprüft, verteilt oder veröffentlicht wird. Behandeln Sie Zugangsdaten als separate Sicherheitsanforderung: Eine Migration darf keine Geheimnisse in Ausgaben oder dauerhaft ungeschützten Dateien sichtbar machen.

  6. Nachweise vergleichen und Freigabe dokumentieren. Vergleichen Sie die neuen Protokolle mit der gesicherten Basis. Notieren Sie Abweichungen, nicht bestandene Prüfungen und genehmigte Einschränkungen. Legen Sie fest, welche Ergebnisse für die Umschaltung zwingend erforderlich sind und unter welchen Bedingungen der alte Ausführungspfad wieder aktiviert wird.

Ein sinnvoller Vergleich bewertet nicht bloß den abschließenden Status „grün“. Er berücksichtigt, ob dieselben Ziele gebaut wurden, welche Tests liefen, welches Archiv entstand und ob die Signierungs- und Veröffentlichungsschritte wie vorgesehen abgeschlossen wurden. Wenn ein Projekt private Pakete oder interne Dienste nutzt, gehört auch deren Erreichbarkeit in die Abnahme. So bleibt sichtbar, ob ein Fehler von der Runner-Umgebung, der Netzwerkpolitik, einer Abhängigkeit oder der eigentlichen Änderung im Commit stammt.

FAQ zur Migration der macOS-CI

Welches Runner-Label kommt nach dem Ende von macOS 14 infrage?
Wählen Sie das Label nicht allein nach dem neuesten Betriebssystemnamen. Prüfen Sie in der aktuellen GitHub-Dokumentation, welche gehosteten Runner verfügbar sind, und gleichen Sie diese Auswahl mit dem Image-Inventar ab. Entscheidend sind die benötigte Xcode-Version, die Architektur und alle projektspezifischen Abhängigkeiten. Ein Label ist erst dann ein geeigneter Ersatz, wenn die isolierte Pipeline damit vollständig abgenommen wurde.

Was muss vor einem Wechsel auf macos-15 oder macos-26 geprüft werden?
Kontrollieren Sie zunächst, ob das gewünschte Label aktuell dokumentiert ist. Danach vergleichen Sie macOS- und Xcode-Anforderungen, SDKs, Simulatorziele, Architektur und native Abhängigkeiten. Prüfen Sie außerdem Signierung, private Paketquellen, Caches und Netzwerkzugriffe. Die Versionsnummer des Runner-Images belegt keine Kompatibilität Ihres Projekts; maßgeblich sind reproduzierbare Ergebnisse mit demselben Commit und derselben Abnahmelogik.

Wie lässt sich nach dem Wechsel die Funktion von Xcode und Simulatoren nachweisen?
Sichern Sie zunächst die relevanten Angaben aus den alten Laufprotokollen und führen Sie dieselben Build- und Testaufträge mit dem neuen Runner aus. Prüfen Sie, ob Xcode und SDK passen, das erwartete Simulatorziel verfügbar ist und die Tests tatsächlich gestartet und abgeschlossen werden. Bewahren Sie Protokolle, Testergebnisse und Archivinformationen auf. Ein erfolgreicher Build allein belegt weder funktionierende Simulatorprüfungen noch eine korrekte Veröffentlichung.

Wie sollten Intel-Build-Aufgaben nach der Ausmusterung von macOS 14 weiterlaufen?
Ermitteln Sie zuerst, ob die Aufgabe wirklich eine Intel-Architektur benötigt oder ob sie nur bislang zufällig auf einem Intel-Runner lief. Prüfen Sie Binärabhängigkeiten, Architekturannahmen in Skripten und die verfügbaren Runner-Eigenschaften. Falls ein dokumentierter gehosteter Runner die erforderliche Architektur nicht abdeckt, behalten Sie einen separat verwalteten Intel-Ausführungspfad bei, bis ein gleichwertiger Ersatz geprüft und freigegeben ist.

Netzwerk, Caches und Zuständigkeiten in der Betriebsentscheidung berücksichtigen

Der Wechsel des Images löst keine Probleme, die aus Zugriffsrechten oder Netzwerkrichtlinien entstehen. Listen Sie daher private Paketquellen, interne Dienste und erforderliche Verbindungen auf und testen Sie sie aus dem Kandidatenjob. Wenn ein Job Zugang zu internen Ressourcen benötigt, klären Sie vor der Umschaltung, ob die gehostete Ausführungsumgebung diesen Zugriff überhaupt erhalten darf und welche Sicherheitskontrollen dafür gelten.

Bei selbst verwalteten Runnern liegen Installation, Aktualisierung und Absicherung der Laufzeitumgebung stärker im Verantwortungsbereich des Teams. GitHub beschreibt Anforderungen und Grenzen im Leitfaden zu selbst gehosteten Runnern. Berücksichtigen Sie besonders, wer Image-Updates einspielt, wie Zugänge geschützt werden und wie ein Runner nach einem fehlgeschlagenen Job in einen definierten Zustand zurückkehrt. Eine selbst verwaltete Mac-Umgebung bietet mehr Kontrolle über installierte Werkzeuge, verlangt aber auch nachvollziehbare Betriebsprozesse.

Gehostete Runner und selbst verwaltete Mac-Systeme sollten deshalb nicht nur nach dem Betriebssystem verglichen werden. Entscheidend sind die Zuständigkeit für Updates, die Verfügbarkeit benötigter Abhängigkeiten, Netzwerkzugang, Geheimnisverwaltung und die Frage, ob das Team eine eigene Laufzeitumgebung betreiben kann. Für eine dauerhafte macOS-CI ist die beste Lösung diejenige, deren Voraussetzungen im Team abgesichert und deren Ergebnisse regelmäßig überprüft werden können.

Falls eine zusätzliche, kontinuierlich zugängliche Mac-Umgebung für Vergleichs- oder Validierungsjobs benötigt wird, kann ein Remote-Mac ein separater Prüfpfad sein. Er ersetzt nicht automatisch die GitHub-gehostete Pipeline und ist kein Beleg dafür, dass beide Umgebungen identisch arbeiten. Informationen zu einer realen Mac-Umgebung stellt RUVCLOUD bereit. Entscheidend bleibt, den gleichen Commit, dieselbe freigegebene Toolchain und dieselben Abnahmekriterien zu verwenden.

Freigabe-Checkliste

  • [ ] Alle Verweise auf macos-14, macos-14-large und macos-14-xlarge sind in Workflow-Dateien, wiederverwendbaren Workflows und relevanten Laufprotokollen erfasst.
  • [ ] Das ausgewählte Ersatz-Label ist in den aktuellen GitHub-Angaben dokumentiert; Image-Inhalt und Architektur wurden zusätzlich im Image-Inventar geprüft.
  • [ ] Die tatsächlich gestartete Xcode- und SDK-Version entspricht der freigegebenen Projektbasis und ist mit Apples Versions- und Systemhinweisen abgeglichen.
  • [ ] Native Abhängigkeiten wurden nicht nur installiert, sondern auch gebaut und in den vorgesehenen Tests überprüft.
  • [ ] Build, Simulatorziel, Signierung, Archiv und nachgelagerter Veröffentlichungsprozess sind durch Protokolle und Artefakte belegt.
  • [ ] Private Abhängigkeiten, Netzwerkzugriffe, Caches und vertrauliche Zugangsdaten sind im Kandidatenpfad geprüft.
  • [ ] Für fehlgeschlagene Prüfungen ist ein Rückfallpfad dokumentiert; die Umschaltung erfolgt erst nach der Freigabe durch die zuständigen Verantwortlichen.

Die Migration ist erst dann belastbar, wenn die neue Umgebung die für das Projekt relevanten Ergebnisse reproduziert und Abweichungen verstanden sind. Ein unmittelbarer Wechsel auf latest kann zwar einen Job wieder startbar machen, lässt aber offen, ob Xcode, Architektur, Tests und Signierung weiterhin zusammenpassen. Teams, die nach der Abnahme einen zusätzlichen Mac-Prüfpfad benötigen, können die verfügbaren Optionen auf der RUVCLOUD-Seite zu Preisen und Mietbedingungen prüfen. Für reproduzierbare, standardisierte Jobs ohne Bedarf an einer dauerhaft zugänglichen Mac-Umgebung kann der gehostete Runner die einfachere Wahl bleiben; ein Remote-Mac ist vor allem dann zu bewerten, wenn das Team eine kontrollierbare Mac-Umgebung für fortlaufende Validierung benötigt.