Vor dem Aus von GitHub Actions macOS-14: Wie migrieren Sie iOS-CI? 2026

Die GitHub-Ankündigung bestätigt, dass die Labels macOS-14, macOS-14-large und macOS-14-xlarge am 02.11.2026 außer Betrieb genommen werden. GitHub nennt Ersatz-Labels als Empfehlungen. Diese Empfehlung belegt jedoch nicht, dass jedes Projekt mit dem Ersatz kompatibel ist. Prüfen Sie deshalb erst die Anforderungen Ihrer Release-Aufgaben und anschließend das tatsächliche Image. Die Ankündigung zum Auslaufdatum und zu den vorgeschlagenen Ersatz-Labels ist der maßgebliche Ausgangspunkt; verfügbare Images und deren Inhalt sollten Sie im offiziellen Runner-Images-Repository nachsehen.

Diese Migration betrifft laufende iOS-Veröffentlichungsworkflows. Sie ist weder eine vollständige Inventur sämtlicher Organisations-Runner noch eine Anleitung zur Behebung von Brownout-Ausfällen. Für die Planung zählen hier die produktiven Abläufe: Welche Jobs erzeugen ein auslieferbares Archiv? Welche verwenden Zertifikate oder App-Store-Zugangsdaten? Welche Aufgabe kann während der Umstellung nicht ausfallen?

Ein häufiger Planungsfehler ist, Betriebssystem, Runner-Größe, Prozessorarchitektur und Xcode als ein einziges Merkmal zu behandeln. Das Runner-Label bestimmt den angeforderten Ausführungstyp. Es sagt für sich genommen nicht, welche Xcode-Version Ihr Workflow tatsächlich auswählt oder welche Werkzeuge im Image enthalten sind. Gleichen Sie die Dokumentation zur Auswahl eines Runners und die Image-Informationen mit der tatsächlich ausgeführten Job-Konfiguration ab.

Auch organisatorische und technische Risiken sollten getrennt erfasst werden. Ein neuer Runner kann mit dem Projekt kompatibel sein, während ein Veröffentlichungsgeheimnis weiterhin zu weitreichend verfügbar ist. Umgekehrt kann eine sichere Freigaberegel die Veröffentlichung schützen, aber keine fehlende Xcode-Kompatibilität beheben. Behandeln Sie Umgebungswahl, Berechtigungen und Produktionsfreigabe als separate Prüfpunkte.

Welche Workflows müssen vor der Umstellung angepasst werden?

Suchen Sie nicht nur nach dem Text macOS-14. Prüfen Sie die vollständigen Workflow-Dateien und wiederverwendbaren Workflows auf Runner-Labels, Bedingungen, Matrix-Einträge und Verweise in zentralen Aktionen. Stellen Sie fest, welche Jobs tatsächlich ein Release erzeugen oder Signierungsdaten verwenden. Ein Label kann in einem gewöhnlichen Testjob stehen und zugleich in einem separaten, weniger auffälligen Veröffentlichungsjob vorkommen.

Bewerten Sie jede betroffene Aufgabe nach ihrer Auswirkung. Ein nicht signierter Kompilierungstest lässt sich meist leichter erneut ausführen als ein Upload-Job, der ein freigegebenes Archiv veröffentlicht. Die Reihenfolge der Migration sollte deshalb aus dem Risiko der Aufgabe folgen, nicht aus der Reihenfolge, in der Workflow-Dateien im Repository gefunden werden.

Erzeugen Sie eine Referenz aus einem echten, erfolgreichen Release-Workflow. Eine grüne Statusanzeige allein reicht nicht: Sie muss erkennen lassen, ob dieselbe Anwendung mit denselben Abhängigkeiten gebaut, korrekt archiviert und wie vorgesehen signiert wurde. Ohne diesen Vergleich können Sie nach dem Wechsel nicht zuverlässig unterscheiden, ob eine Abweichung vom Runner, einer veränderten Dependency-Auflösung oder einer Änderung an der Pipeline stammt.

Sichern Sie für den Referenzlauf mindestens die angeforderte Runner-Kennung und die tatsächlich protokollierte Umgebung. Halten Sie fest, wie der Workflow Xcode auswählt, welche Abhängigkeiten aufgelöst werden, welche Build-Konfiguration verwendet wird und welches Archiv entsteht. Erfassen Sie außerdem den Signierungs- und Exportweg sowie die nachgelagerte Upload-Stufe, soweit diese zur Veröffentlichung gehört. Für System- und Xcode-Kompatibilität ist die aktuelle Übersicht der Xcode-Systemanforderungen maßgeblich. Die Versionsangabe in einer Workflow-Datei sollten Sie mit der Auswahl im Lauf und den verfügbaren Tools im Image vergleichen.

Definieren Sie vor dem Pilotlauf, welche Ergebnisse gleich sein müssen und wo Unterschiede zulässig sind. Prüfen Sie etwa, ob das erwartete Scheme gebaut wurde, ob das Archiv für den vorgesehenen Zweck exportiert werden kann und ob Signatur sowie Berechtigungen den Release-Anforderungen entsprechen. Ein abweichender Zeitstempel oder ein neu erzeugter Build-Identifier ist nicht automatisch ein Fehler. Ein unerwartetes Bundle, ein fehlendes Entitlement oder ein anderes Signaturzertifikat ist dagegen ein Grund, die Freigabe anzuhalten.

Notieren Sie außerdem Aufgaben, die Sie während des Tests nicht versehentlich auslösen dürfen. Dazu zählen produktive Uploads, Benachrichtigungen an externe Empfänger und Schritte, die Release-Material überschreiben. Richten Sie eine isolierte Testbedingung ein, statt den Produktionsworkflow unverändert auf einen Test-Branch loszulassen. Regeln für geschützte Deployment-Umgebungen helfen dabei, den Zugriff auf Freigaben und Geheimnisse zu kontrollieren; die GitHub-Dokumentation zu Deployment-Umgebungen und Schutzregeln beschreibt diese Kontrollmöglichkeiten.

Nutzen Sie die von GitHub empfohlenen Ersatz-Labels als Kandidatenliste, nicht als pauschale Migrationsfreigabe. Ein Projekt, das ein bestimmtes Betriebssystem oder eine festgelegte Xcode-Werkzeugkette voraussetzt, muss genau diese Kombination am tatsächlichen Lauf prüfen. Die Bezeichnungen macOS-15 oder macOS-26 sind Such- und Auswahlhinweise, aber kein Nachweis, dass jede Projektabhängigkeit, jeder Simulator-Test und jede Signierungsstufe darauf funktioniert.

Vergleichen Sie vor dem Pilotlauf die Anforderungen mit den Image-Angaben. Prüfen Sie die Systemversion und Architektur, die installierten Xcode-Versionen sowie die Werkzeuge, die Ihre Skripte direkt aufrufen. Wenn der Workflow Xcode dynamisch auswählt oder auf eine vorinstallierte Standardversion zurückfällt, kann der Runner-Wechsel unbeabsichtigt auch die Toolchain ändern. Verifizieren Sie die effektive Auswahl daher im Log und machen Sie die gewünschte Auswahl dort nachvollziehbar.

Wie prüfen Sie einen Wechsel von macOS-14 zu macOS-15 oder macOS-26?

Führen Sie den bestehenden Release-Workflow zunächst in einer isolierten Variante mit dem vorgesehenen Ersatz-Label aus. Ändern Sie für diesen Test nicht gleichzeitig Abhängigkeiten, Build-Skripte und Xcode-Auswahl. Sonst wird die Ursache eines Fehlers schwer zuzuordnen sein. Erfassen Sie im Log den Runner, die Systemversion und die gewählte Xcode-Umgebung. Vergleichen Sie diese Angaben mit der offiziellen Image-Übersicht und den Xcode-Systemanforderungen von Apple.

Wenn das Projekt mehrere Xcode-Versionen unterstützt, testen Sie die produktiv verwendete Auswahl zuerst. Eine erfolgreiche Kompilierung auf einer anderen Version beweist nicht, dass die Release-Pipeline reproduzierbar ist. Ebenso ist ein grüner Simulatorlauf keine Abnahme für eine Verteilung, bei der Archive exportiert und signiert werden. Halten Sie deshalb für jede Kandidatenumgebung fest, was tatsächlich getestet wurde und welche Aufgaben noch offen sind.

Führen Sie den ersten Kandidatenlauf außerhalb des produktiven Veröffentlichungswegs aus. Verwenden Sie den realen Projektstand und die relevanten Workflow-Schritte, aber trennen Sie den Test von Produktionsgeheimnissen und extern wirksamen Veröffentlichungsschritten. Behalten Sie die Reihenfolge der Release-Aufgaben soweit wie möglich bei. So prüfen Sie die echte Pipeline und nicht nur eine künstlich vereinfachte Kompilierung.

Arbeiten Sie die folgenden Punkte ab und speichern Sie die Belege pro Pilotlauf:

• [ ] Der isolierte Workflow verwendet das vorgesehene Ersatz-Label; das tatsächliche Runner-Image ist im Log erkennbar.
• [ ] Die erwartete Systemumgebung und die verwendete Xcode-Version stimmen mit der dokumentierten Projektanforderung überein.
• [ ] Abhängigkeiten werden über den vorgesehenen Mechanismus aufgelöst; unerwartete Änderungen oder nicht verfügbare private Quellen sind dokumentiert.
• [ ] Build und erforderliche Tests laufen mit denselben relevanten Einstellungen wie der Release-Pfad.
• [ ] Das Archiv wird mit dem vorgesehenen Scheme erzeugt und lässt sich für den vorgesehenen Verteilungsweg exportieren.
• [ ] Signatur, Provisioning-Profil und relevante Entitlements werden geprüft; Geheimnisse sind im Testworkflow nicht unnötig offengelegt.
• [ ] Upload oder Veröffentlichung sind entweder sicher isoliert oder ausdrücklich deaktiviert.
• [ ] Fehlermeldungen, Laufprotokolle und Vergleichsergebnisse sind einem konkreten Commit und einer Runner-Umgebung zugeordnet.

Für Archive und Export darf die Abnahme nicht bei „Build erfolgreich“ enden. Prüfen Sie den erzeugten Inhalt und den Signierungsweg entsprechend Apples Dokumentation zum Erstellen signierten und verteilbaren Codes. Die konkrete Projektkonfiguration bleibt entscheidend: Die Dokumentation ersetzt weder die Prüfung Ihrer App noch die Freigabe durch Ihre Release-Verantwortlichen.

Behandeln Sie Signierungsdaten als eigene Sicherheitsgrenze. Ein Pilot ist kein Anlass, Zertifikate oder Zugangsdaten pauschal für alle Testjobs freizugeben. Verwenden Sie Zugriffsbeschränkungen für produktive Geheimnisse, prüfen Sie die Berechtigungen beteiligter Aktionen und halten Sie Ausgaben so, dass vertrauliche Werte nicht in Logs erscheinen. Die GitHub-Hinweise zur sicheren Verwendung von Actions erläutern Risiken durch nicht vertrauenswürdige Eingaben und Berechtigungen.

Schalten Sie zuerst nur Aufgaben um, deren Abnahme abgeschlossen und deren Rückweg praktisch ausführbar ist. Beginnen Sie nicht mit dem empfindlichsten Veröffentlichungsschritt, nur weil er geschäftlich am wichtigsten ist. Ein risikoärmerer Build-Job kann zeigen, ob Routing und Image wie erwartet arbeiten. Für die eigentliche Freigabe bleibt aber der vollständige, signierte Release-Weg maßgeblich.

Legen Sie vor jeder Freigabestufe eine klare Stop-Bedingung fest. Dazu gehören ein nicht reproduzierbares Archiv, eine unerwartete Xcode-Auswahl, eine fehlerhafte Signatur oder ein nicht kontrollierter Zugriff auf Produktionsgeheimnisse. Bei einem dieser Befunde bleibt die betreffende Aufgabe auf dem zuletzt verifizierten Weg. Vergrößern Sie den Umfang erst, wenn die Abweichung verstanden und die Abnahme dokumentiert ist.

Ein Rückweg ist nur belastbar, wenn er den alten Runner nicht als dauerhafte Lösung voraussetzt. Da die macOS-14-Labels am 02.11.2026 enden sollen, ist ein Fallback auf genau diese Labels keine tragfähige Betriebsstrategie nach dem Auslaufdatum. Halten Sie stattdessen einen geprüften alternativen Runner oder eine gesondert abgenommene Mac-Ausführung bereit. Prüfen Sie auch, ob bei einem Rückfall doppelte Veröffentlichungen, konkurrierende Jobs oder widersprüchliche Release-Artefakte entstehen könnten. GitHub beschreibt mit Concurrency-Gruppen, wie gleichzeitig laufende Jobs innerhalb eines Workflows kontrolliert werden können; entscheiden Sie bewusst, ob wartende oder abgebrochene Läufe zu Ihrem Release-Prozess passen.

Nicht jeder Job benötigt dieselbe Ausführungsumgebung. Trennen Sie gewöhnliche Builds, Simulatorprüfungen und signierte Veröffentlichungen nach ihren Anforderungen. Wenn ein Job auf einem Kandidaten scheitert, dokumentieren Sie zunächst die konkrete Ursache: fehlende Werkzeugversion, inkompatible Abhängigkeit, benötigte Signierungsberechtigung, Netzwerkzugriff oder eine Anforderung an kontinuierliche Verfügbarkeit. „Läuft nicht auf macOS-15“ ist für eine Architekturentscheidung zu ungenau.

Für einen Job, der auf einem gehosteten Ersatz-Runner nicht abgenommen werden kann, prüfen Sie eine gesonderte Mac-Ausführung anhand derselben Release-Evidenz. Relevant sind die benötigte macOS- und Xcode-Umgebung, der Umgang mit Signierungsdaten, Zugriffsrechte, Netzwerkpfade, Job-Routing und die Wiederherstellung nach einem fehlgeschlagenen Lauf. Ein Remote Mac ist nicht automatisch die richtige Wahl: Er muss die Anforderungen des konkreten Workflows erfüllen, und die Organisation muss Betrieb, Zugriff und Sicherheitsverantwortung klären.

MESHLAUNCH bietet Remote Macs als reale Mac-Hosts mit Root-Zugriff und Zugriff über VNC, SSH oder eine Webkonsole an; die verfügbaren Mietzeiträume sind wöchentlich, monatlich oder quartalsweise. Diese Angaben beantworten nicht automatisch Fragen zu einer konkreten Konfiguration, Region, Lieferbedingung oder Leistung. Verifizieren Sie solche Punkte vor einer Beschaffung anhand der jeweils aktuellen Angebotsinformationen. Für einen ersten Abgleich können Sie die MESHLAUNCH-Angebotsübersicht prüfen; wenn ein Mac mini als Kandidat infrage kommt, sehen Sie sich auch die Informationen zum Mac mini M4 an.

Bei dauerhaft hoher, planbarer Auslastung kann ein eigener Mac wirtschaftlich oder organisatorisch besser passen; bei sporadischen Tests kann ein gehosteter Runner ausreichend sein. Eine zusätzliche gemietete Mac-Umgebung kann dagegen für zeitlich begrenzte Migrationstests oder einzelne Aufgaben interessant sein, sofern Zugriff, Signierung und Workflow-Integration in der Abnahme tatsächlich funktionieren. Vergleichen Sie nicht nur Miet- oder Kaufkosten: Berücksichtigen Sie auch Wartung, Ausfallbehandlung, Zugriffskontrolle, Kapazitätsplanung und den Aufwand, einen Fallback regelmäßig zu testen.

Freigabeentscheidung: Geben Sie eine Aufgabe erst für den neuen Runner frei, wenn deren effektive Umgebung, Build, Tests, Archiv und Signierung nachweisbar geprüft sind. Wenn ein kritischer Release-Job nicht besteht, halten Sie ihn aus der Produktionsumstellung heraus und klären Sie zuerst eine getestete Alternative. GitHub-Runner binden Sie an bereitgestellte Images und deren Lebenszyklus; bei einer eigenen oder gemieteten Mac-Umgebung kommen dafür Betriebs-, Zugriffs- und Sicherheitsprüfungen hinzu. Wenn Sie für die Migration eine zeitlich begrenzte Test- oder Ausweichkapazität benötigen, kann ein gemieteter Mac von MESHLAUNCH eine sinnvolle Option sein – aber erst, nachdem der reale Release-Workflow und die erforderlichen Rahmenbedingungen auf genau dieser Umgebung abgenommen wurden.