Die GitHub-Ankündigung vom 01.10.2026 nennt den 02.11.2026 als Ausmusterungstermin für das macOS-14-Runner-Image. Warten Sie nicht bis zu diesem Termin: Prüfen Sie zuerst die betroffenen Workflows, testen Sie ein unterstütztes Runner-Label parallel und schalten Sie erst um, wenn Ihr eigener Build-, Test- und Veröffentlichungsweg auf dem Kandidaten erfolgreich war. Falls ein fest kontrollierbares macOS oder ein dauerhaft verfügbarer Knoten erforderlich ist, bewerten Sie Remote-Mac-CI als separate Betriebsoption.

Für Entwicklerinnen und Entwickler, die noch macOS-14-Labels verwenden und die Kompatibilität ihrer Projekte mit einer neueren macOS- und Xcode-Umgebung prüfen müssen.
Für CI-Teams, die Workflow, Abhängigkeiten, Cache und Artefakte nachvollziehbar vergleichen wollen.
Für Plattformverantwortliche, die entscheiden müssen, ob ein gehosteter Runner genügt oder ein kontrollierbarer Mac-Ausführungsknoten sinnvoller ist.

Zuletzt aktualisiert am 07.10.2026; geprüft anhand der GitHub-Ausmusterungsankündigung und der offiziellen Runner-Images. Prüfen Sie vor der Veröffentlichung erneut, ob GitHub Termin, betroffene Labels oder Brownout-Fenster geändert hat.

Vor der Migration: Betroffene Workflows und Ausmusterung erfassen

Die Ausmusterung betrifft laut GitHub die Labels macos-14, macos-14-large und macos-14-xlarge; auch die angekündigten Brownout-Zeiträume gehören zur Übergangsplanung. Die konkreten Zeitfenster sollten direkt in der aktuellen Ankündigung geprüft werden, statt sie aus einem älteren Kalender oder einer kopierten Teamnotiz zu übernehmen. Diese Angaben sind ein Anlass zur Planung, aber noch kein Nachweis dafür, dass ein Projekt auf einem neuen Image unverändert läuft.

Suchen Sie in sämtlichen Workflow-Dateien nach den betroffenen Labels, nicht nur in der Standarddatei für Pull Requests. Berücksichtigen Sie auch wiederverwendbare Workflows, Matrix-Konfigurationen und Ausführungen, die nur auf bestimmten Branches oder bei manueller Freigabe starten. Die Workflow-Syntax von GitHub erlaubt mehrere Formen der Runner-Auswahl; insbesondere bei Variablen und Matrizen kann eine reine Textsuche einzelne Fälle übersehen. Prüfen Sie deshalb auch die Auswertung des Schlüssels runs-on in der Dokumentation zur Workflow-Syntax.

Zu erfassender Punkt Wo nachsehen Was für die Migrationsentscheidung zählt
Runner-Label runs-on, Matrizen und wiederverwendbare Workflows Welche Jobs tatsächlich ein macOS-14-Label anfordern
Auslöser Branch-Regeln, Pull Requests, Zeitpläne und manuelle Starts Ob ein Job regelmäßig, nur vor einer Veröffentlichung oder selten läuft
Aufgabe Build-, Test-, Signierungs- und Veröffentlichungsjobs Welche Schritte für die Freigabe kritisch sind
Zuständigkeit Workflow-Eigentümer und Freigabeverantwortliche Wer Testergebnisse bewertet und eine Rückkehr freigibt

Wann wird der macOS-14-Runner ausgemustert? GitHub nennt den 02.11.2026 als geplanten Termin. Die Ankündigung enthält darüber hinaus Brownout-Zeitfenster, die während der Übergangsphase die Nutzung beeinflussen können. Da sich ein öffentlich angekündigter Zeitplan ändern kann, sollten Teams die Seite vor der tatsächlichen Umschaltung nochmals prüfen und die dort genannten Labels mit den Workflow-Dateien abgleichen.

Führen Sie aus der Bestandsaufnahme eine kleine, überprüfbare Liste: betroffener Workflow, verantwortliche Person, letzte bekannte erfolgreiche Ausführung und nächster geeigneter Testlauf. So lässt sich die Migration nach Risiko priorisieren. Ein täglich ausgeführter Veröffentlichungsworkflow braucht eine andere Aufmerksamkeit als ein selten gestarteter Prüfjob; beide dürfen aber nicht als unbetroffen gelten, nur weil sie im Alltag wenig sichtbar sind.

Vor dem ersten Test: Eine belastbare Vergleichsbasis sichern

Ein erfolgreicher Lauf auf einem neuen Runner ist nur aussagekräftig, wenn klar ist, was sich gegenüber dem bisherigen Lauf geändert hat. Halten Sie deshalb vor dem Test die für das Projekt maßgeblichen Umgebungsbedingungen fest. Dazu gehören Xcode-Auswahl, verwendetes SDK, Installationsweg der Abhängigkeiten, Build-Parameter, Testziele sowie die Regeln für Artefaktprüfung und Veröffentlichung. Die aktuell bereitgestellte Software kann sich mit dem Runner-Image ändern; GitHub verweist für diese Inhalte auf sein Runner-Image-Repository.

Sichern Sie nicht einfach einen vollständigen Log als vermeintliche Baseline. Halten Sie stattdessen fest, welche relevanten Schritte ausgeführt wurden, welche Tests tatsächlich liefen und woran ein korrektes Artefakt erkennbar ist. Bei einem iOS-Projekt kann das etwa heißen, Build und Tests getrennt zu protokollieren und die erwarteten Archivierungs- und Signierungsschritte ausdrücklich zu benennen. Ein grüner Job ist nicht automatisch ein Beleg dafür, dass der Workflow denselben Veröffentlichungsweg wie zuvor durchlaufen hat.

Basismerkmal Vor dem Wechsel dokumentieren Beim Vergleich beachten
Werkzeuge Xcode-Auswahl, SDK und projektbezogene Build-Einstellungen Prüfen, ob der neue Runner eine benötigte Werkzeugversion bereitstellt
Abhängigkeiten Paketmanager, Auflösungsdateien und Installationsschritte Keine Änderung an Quellcode und Abhängigkeiten unbemerkt mit der Image-Migration vermischen
Tests Testziele, Aufrufparameter und erwartete Prüfergebnisse Verifizieren, dass nicht versehentlich Testziele ausgelassen werden
Cache Cache-Schlüssel, gespeicherte Pfade und Wiederherstellung Einen Cache-Fehler nicht vorschnell mit einem Werkzeugfehler verwechseln
Artefakte Archivierungsweg und projektspezifische Prüfmerkmale Build-Erfolg und vollständigen Veröffentlichungsnachweis getrennt bewerten

Bewahren Sie außerdem eine repräsentative, erfolgreiche Ausführung auf, ohne Zugangsdaten oder Signierungsgeheimnisse in frei zugängliche Logs zu schreiben. Wenn Sie für die Diagnose mehr Protokollierung benötigen, begrenzen Sie deren Umfang und prüfen Sie vor dem Speichern, ob vertrauliche Umgebungswerte ausgegeben werden könnten. Für Cache-Verhalten und Cache-Schlüssel ist die GitHub-Dokumentation zur Abhängigkeitsspeicherung die passende Referenz.

Im Probebetrieb: Ein neues Runner-Label isoliert erproben

Ändern Sie nicht sofort den produktiven Workflow. Erstellen Sie einen separaten Branch oder ergänzen Sie vorübergehend einen parallel laufenden Job, der denselben relevanten Build mit einem unterstützten Label ausführt. Die in der Ankündigung genannten Kandidaten und ihre Verfügbarkeit sind vor dem Einsatz nochmals zu prüfen. Für die Image-Inhalte sind die jeweils aktuellen Dateien für macOS 15 und macOS 26 aussagekräftiger als eine allgemeine Annahme über die Bedeutung eines Labels.

Auswahl Vor dem Test prüfen Geeignet, wenn …
macos-15 Aktuelle Image-Liste, Systemversion, Architektur und enthaltene Werkzeuge das Projekt mit der dort ausgewiesenen Werkzeugumgebung kompatibel ist
macos-26 Aktuelle Image-Liste, Systemversion, Architektur und enthaltene Werkzeuge die Projektabhängigkeiten und der Build ausdrücklich mit dieser Umgebung geprüft wurden
Bestehender macOS-14-Job Tatsächliche bisherige Workflow-Konfiguration und letzter erfolgreicher Lauf ein zeitlich begrenzter Vergleich für die Migration benötigt wird

Die Bezeichnungen macos-15 und macos-26 sind Runner-Labels, keine vollständige Beschreibung jeder Eigenschaft eines konkreten Jobs. Verwechseln Sie Label, installierte macOS-Version, Architektur, verfügbare Xcode-Werkzeuge, Deployment-Ziel des Projekts und eigene Workflow-Konfiguration nicht miteinander. Die Runner-Dokumentation von GitHub erläutert die gehosteten Runner; die konkreten Image-Readmes liefern die jeweils aktuell ausgewiesene Softwareliste. Ein Label allein beantwortet daher nicht, ob ein Projekt auf dem Runner funktioniert.

Wie lässt sich der Workflow vor der Umstellung verifizieren? Führen Sie den Kandidaten mit denselben Quellständen, relevanten Build-Parametern und Testzielen aus wie den bisherigen Job. Vergleichen Sie anschließend Logs, Testresultate und Artefakte; bewerten Sie Abweichungen einzeln, bevor Sie sie als Regression oder als harmlose Umgebungsänderung einstufen. Eine erfolgreiche Kompilierung ist notwendig, aber für eine Veröffentlichung nicht hinreichend.

Hinweis: Vermeiden Sie einen parallelen Test, der gleichzeitig Runner-Image, Abhängigkeiten, Cache-Schlüssel und Build-Parameter ändert. Wenn der Lauf fehlschlägt, lässt sich die Ursache sonst nur schwer einer einzelnen Veränderung zuordnen.

Während der Fehleranalyse: Abweichungen gezielt beheben

Ordnen Sie jeden Fehler zuerst einer möglichen Ursache zu: Systemwerkzeug, Abhängigkeitsauflösung, Cache, Skriptannahme oder Architekturbedingung. Prüfen Sie die Fehlermeldung und den betroffenen Workflow-Schritt, bevor Sie Änderungen vornehmen. Wenn beispielsweise ein Installationsskript einen bestimmten Pfad annimmt, ist das zunächst ein Hinweis auf eine Skriptannahme und kein Beweis dafür, dass eine komplette Neuinstallation aller Pakete erforderlich ist.

Gehen Sie bei der Korrektur schrittweise vor:

  • Werkzeuge: Vergleichen Sie die benötigten Werkzeuge mit der aktuellen Image-Liste. Wählen Sie die Xcode-Installation im Workflow ausdrücklich aus, sofern das Projekt auf eine bestimmte verfügbare Version angewiesen ist.
  • Abhängigkeiten: Prüfen Sie, ob Lockfiles, Paketquellen und Installationsbefehle im neuen Lauf identisch behandelt werden. Fixieren Sie alte Versionen nicht vorsorglich, sondern nur, wenn ein reproduzierbarer Fehler dies begründet.
  • Cache: Kontrollieren Sie Cache-Schlüssel und wiederhergestellte Pfade. Ein einmaliger Lauf ohne Cache kann zur Diagnose beitragen, sollte aber nicht als pauschale dauerhafte Lösung gelten.
  • Skripte: Suchen Sie nach Annahmen über Systemversion, Verzeichnisse, Shell oder vorinstallierte Werkzeuge. Ersetzen Sie nur die Annahmen, die durch Logs oder Image-Angaben als Ursache belegt sind.
  • Architektur: Prüfen Sie, ob Abhängigkeiten oder Build-Skripte eine bestimmte Architektur voraussetzen. Übernehmen Sie keine Architekturannahme allein aus dem Namen des Runner-Labels.

Notieren Sie zu jeder Änderung den betroffenen Schritt und das Ergebnis des erneuten Laufs. So verhindern Sie, dass eine erfolgreiche Korrektur durch mehrere gleichzeitig vorgenommene Änderungen unklar bleibt. Besonders bei Caches gilt: Ein vollständiges Leeren kann einen Diagnoseversuch erleichtern, beweist aber nicht, dass der Cache die Ursache war. Ein gezielter Vergleich mit unverändertem Workflow und kontrollierter Cache-Behandlung ist aussagekräftiger.

Was ist beim Wechsel von macOS 14 auf macOS 15 oder macOS 26 zu prüfen? Prüfen Sie nicht nur das Betriebssystem. Maßgeblich sind die konkrete Image-Softwareliste, die verfügbare Xcode- und SDK-Umgebung, Architekturbedingungen, die Projektabhängigkeiten sowie das im Workflow angegebene Deployment-Ziel. Ein niedrigeres Deployment-Ziel garantiert nicht, dass ein Build mit einer neuen Werkzeugumgebung unverändert funktioniert; umgekehrt belegt eine neue Systemversion allein noch keine Inkompatibilität.

Vor der Freigabe: Build, Tests, Signierung und Artefakte abnehmen

Legen Sie vor dem Produktionseinsatz fest, welche Nachweise für Ihr Projekt erforderlich sind. Die Abnahme sollte den echten Workflow abbilden und nicht bei einem Minimal-Build enden. Welche Schritte gelten, hängt vom jeweiligen Veröffentlichungsweg ab; dokumentieren Sie deshalb die tatsächlichen Projektziele, statt einen generischen CI-Erfolg als Freigabe zu verwenden.

Prüfschritt Nachweis Entscheidung bei Abweichung
Projekt-Build Erfolgreicher Build mit dem vorgesehenen Quellstand und den relevanten Parametern Nicht umschalten, solange der Fehler ungeklärt ist
Testziele Ausgeführte Tests und nachvollziehbare Ergebnisse Fehlende oder veränderte Testausführung untersuchen
Archivierung Erwartetes Archiv beziehungsweise projektspezifisches Build-Artefakt Veröffentlichungsweg gesondert prüfen
Signierung Erfolgreicher Signierungsschritt im dafür vorgesehenen Workflow Geheimnis- und Berechtigungsbehandlung nicht durch bloßes „Build grün“ ersetzen
Übergabe Artefaktprüfung und geplanter nächster Veröffentlichungsschritt Freigabe erst nach Bestätigung der verantwortlichen Stelle

Halten Sie den Status „Build bestanden“ getrennt von „Veröffentlichungskette bestanden“. Der erste Status belegt nicht automatisch, dass Archiv, Signierung und Übergabe funktionieren. Wenn ein Projekt für einen Schritt ein echtes Gerät, eine grafische Sitzung oder eine besondere Interaktion mit lokaler Hardware benötigt, prüfen Sie, ob der gehostete Runner diesen konkreten Bedarf abdeckt. Die Fähigkeiten gehosteter Runner sollten nicht mit denen eines kontrollierten Mac-Systems gleichgesetzt werden; umgekehrt ist ein Remote Mac nicht automatisch ein Ersatz für jeden gehosteten CI-Schritt.

Für die Prüfung zählt der konkrete Ablauf: Wird das erwartete Artefakt erzeugt? Lässt es sich mit den vorgesehenen Projektmitteln prüfen? Sind die Signierungsschritte erfolgreich? Ist die Übergabe an den nächsten Prozess nachvollziehbar? Notieren Sie die Ergebnisse je Kandidaten-Runner und je relevantem Job. Eine erfolgreiche Testausführung in einem separaten Prüfworkflow ist kein Ersatz für die Abnahme des produktiven Veröffentlichungsjobs, wenn dieser eigene Bedingungen oder Berechtigungen verwendet.

Nach der Abnahme: Produktion umstellen und Rückfall festlegen

Schalten Sie die produktiven Workflows erst um, wenn die verantwortliche Person die vereinbarten Build-, Test- und Veröffentlichungsnachweise geprüft hat. Ändern Sie die betroffenen Runner-Labels gezielt und entfernen Sie macOS-14-Referenzen erst, wenn sie nicht mehr für einen notwendigen Vergleich oder einen dokumentierten Rückfall gebraucht werden. Prüfen Sie nach der Änderung die tatsächlich ausgelösten Jobs, damit ein nicht getroffener Workflow oder eine Matrix-Variante nicht unbemerkt auf dem alten Label verbleibt.

Legen Sie vor dem Umschalten Rückfallbedingungen fest. Dazu gehören ein nicht reproduzierbarer Fehler im kritischen Build, fehlende Tests, ein fehlerhaftes Artefakt oder eine nicht funktionierende Signierungs- beziehungsweise Übergabekette. Bestimmen Sie außerdem, wer bei einem solchen Ergebnis die Umstellung pausiert, welche Workflow-Version wiederhergestellt wird und wie offene Veröffentlichungen behandelt werden. Der Rückfall ist keine Erfolgskontrolle, sondern eine begrenzte Schutzmaßnahme; er sollte nicht dazu führen, die Ausmusterung dauerhaft zu ignorieren.

Entscheidung: gehosteten Runner weiterverwenden oder Remote Mac prüfen?

  • Wenn Ihr Projekt auf einem aktuellen gehosteten Image zuverlässig baut, testet und seine vorgesehene Veröffentlichungskette durchläuft, dann bleiben Sie beim gehosteten Runner und pflegen die Image-Prüfung als Teil Ihrer CI-Wartung.
  • Wenn Sie eine bestimmte, reproduzierbar festzulegende macOS-Umgebung benötigen, dann vergleichen Sie die verfügbaren Betriebsmodelle, bevor Sie die Ausführung verlagern; ein gehostetes Label ist nicht gleichbedeutend mit vollständiger Kontrolle über Image und Wartungszeitpunkt.
  • Wenn ein kontinuierlich verfügbarer Build-Knoten, ein eigener Wartungsprozess oder eine feinere Kontrolle über das Host-System benötigt wird, dann bewerten Sie Remote-Mac-CI anhand der konkreten Anforderungen, Verantwortlichkeiten und Sicherheitsvorgaben.
  • Wenn ein Projekt zwingend eine physische Schnittstelle oder eine nicht verfügbare grafische Sitzung voraussetzt, dann klären Sie diese Grenze ausdrücklich. Ein Remote-Mac-Angebot ist nicht automatisch für jeden solchen Bedarf geeignet.
  • Wenn der Build selten läuft und die gehostete Umgebung die benötigten Schritte erfüllt, dann kann ein zusätzlicher dauerhaft betriebener Knoten unnötige Verwaltungsarbeit schaffen.

Ein Wechsel vom gehosteten Runner auf einen selbst verwalteten Mac bringt ebenfalls Aufgaben mit sich: Das Team muss Systempflege und Updates verantworten, den Zugriff absichern und die Verfügbarkeit sowie den Zustand des Knotens überwachen. Für Signierungsgeheimnisse und Administrationszugänge sind Zugriffskontrolle und nachvollziehbare Zuständigkeiten Teil der Betriebsentscheidung; ein Mac im Rechenzentrum macht diese Verantwortung nicht überflüssig. Berücksichtigen Sie dabei Ihre Datenschutz- und DSGVO-Anforderungen sowie die internen Regeln für Zugangsdaten und Artefakte.

Wenn ein kontrollierbarer Mac für Ihren Ablauf infrage kommt, prüfen Sie zuerst, welche Angaben zu Mietkosten, Laufzeit und Bereitstellung tatsächlich verfügbar sind, statt mit allgemeinen Preisannahmen zu kalkulieren. Die aktuellen Konditionen von RUVCLOUD sollten dabei mit dem vorgesehenen Einsatzzeitraum und den betrieblichen Anforderungen verglichen werden. Für eine konkrete Anfrage steht außerdem die Bestellübersicht von RUVCLOUD bereit; daraus folgt jedoch nicht automatisch, dass ein Remote Mac für jedes CI-Team die passende Lösung ist.

Der Wechsel hat einen klaren Zweck: Die Ausmusterung des macOS-14-Images darf weder einen ungeprüften Produktionssprung noch eine überhastete Infrastrukturentscheidung auslösen. Wenn die gehosteten Runner Ihre freigegebene Kette weiterhin tragen, bleiben Sie dort; wenn feste Umgebungsanforderungen, dauerhafte Verfügbarkeit oder weitergehende Host-Kontrolle tatsächlich entscheidend sind, vergleichen Sie einen Remote Mac mit den zusätzlichen Betriebs- und Zugriffspflichten. Prüfen Sie in beiden Fällen den aktuellen GitHub-Zeitplan und entscheiden Sie anhand der nachgewiesenen Ergebnisse Ihres Projekts.