GitHub gab am 10.09.2026 bekannt, dass das Xcode-27-Runner-Image auf macOS 27 läuft und öffentlich als Preview verfügbar ist. Für Ihre Abnahme sind das zwei getrennte Feststellungen: die angekündigte Image-Basis und der Preview-Status. Die aktuelle Image-Liste und die Veröffentlichungsinformationen sollten Sie zusätzlich zum GitHub-Hinweis auf den Wechsel zu macOS 27 heranziehen.

Welche macOS-Version verwendet der Xcode-27-Runner? Laut GitHubs Ankündigung macOS 27. Das ist der veröffentlichte Stand des Images, aber noch kein Nachweis dafür, welche Umgebung ein konkreter Job tatsächlich gestartet hat.

Wie erkennen Sie die tatsächliche Xcode- und macOS-Version? Lassen Sie die Werte im Job ausgeben und speichern Sie sie als Abnahmeprotokoll. Ein Runner-Label beschreibt die Auswahl im Workflow; für den Nachweis im Lauf benötigen Sie zusätzlich die tatsächlichen Versionsausgaben. GitHub dokumentiert, wie Sie festlegen, auf welchem Runner ein Job läuft, und das Xcode-27-arm64-Image-Repository führt die Details des veröffentlichten Images auf.

Ein einfacher Diagnoseblock vor dem Build kann beispielsweise enthalten:

- name: Runner-Umgebung protokollieren
  run: |
    sw_vers
    xcodebuild -version
    xcode-select -p
    uname -a

Speichern Sie die Ausgabe mit Job-ID, Commit und Workflow-Version. Prüfen Sie außerdem die Veröffentlichungshistorie der Runner-Images, wenn Sie nachvollziehen müssen, ob sich das Image seit Ihrer letzten Abnahme verändert hat. Eine erfolgreiche Ausführung mit demselben Label beweist für sich genommen nicht, dass alle Bestandteile der Umgebung unverändert sind.

Die Plattformadministration sollte zuerst eine eindeutige Beweiskette für die Umgebung einrichten. Dokumentieren Sie nicht nur, welches Label in der Workflow-Datei steht, sondern auch die Laufzeitdaten aus dem Job. Ergänzen Sie den Nachweis um den Zeitpunkt der Ausführung, den Workflow und den Commit. So kann Ihr Team einen Fehler später einer konkreten Ausführung zuordnen, statt aus dem Label auf eine vermeintlich unveränderte Plattform zu schließen.

Legen Sie dafür eine unveränderbare oder kontrolliert abgelegte Abnahmeakte an. Sie sollte mindestens enthalten:

• Workflow-Datei oder deren versionierten Stand;
• angefordertes Runner-Label;
• Ausgaben von sw_vers, xcodebuild -version und xcode-select -p;
• Link oder Referenz auf die für den Lauf relevante Image-Veröffentlichung;
• Job-Ergebnis und Verweis auf erzeugte Artefakte.

Die GitHub-Dokumentation zur Auswahl eines Runners für einen Job ist für die Konfiguration der Runner-Auswahl relevant. Verwenden Sie sie aber nicht als Ersatz für die Versionsausgabe aus dem laufenden Job.

Was bedeutet der Preview-Status für Ihre Abnahme? Er bedeutet, dass Sie die ausgewiesene Preview-Eigenschaft in Ihrer Risikoentscheidung berücksichtigen sollten. Er ist weder ein Beleg für einen konkreten Ausfall noch eine Zusage zur Verfügbarkeit oder Wiederherstellung. Vermerken Sie deshalb getrennt, ob Ihr Team eine Preview-Umgebung für nichtproduktive Tests akzeptiert und welche Bedingungen für produktive Veröffentlichungen gelten.

Bevor Sie Jobs neu ausführen, erstellen Sie ein Inventar der Workflows, die das Xcode-27-Runner-Label verwenden. Suchen Sie nicht nur nach dem offensichtlichen Build-Workflow. Auch zeitgesteuerte Jobs, manuelle Release-Abläufe und Workflows für Zweige außerhalb des Hauptentwicklungswegs können auf demselben Runner laufen.

Ordnen Sie jeden Job seiner tatsächlichen Aufgabe zu. Ein Build, ein Unit-Test und eine Veröffentlichung haben unterschiedliche Auswirkungen, wenn die Umgebung abweicht. Markieren Sie mindestens diese Kategorien:

• Kompilierung und Erstellung von Build-Artefakten;
• Unit-Tests und Integrationstests;
• Tests mit iOS- oder macOS-Simulatoren;
• Archivierung und Export;
• Signierung, Upload und anschließende Freigabe.

Weisen Sie jedem Job einen verantwortlichen Bereich zu. Der CI-Verantwortliche bestätigt die Runner-Auswahl und Protokollierung. Das Anwendungsteam bewertet Build und Tests. QA prüft relevante Simulatorläufe. Release-Verantwortliche übernehmen die Prüfung von Signatur und Upload. So wird ein grüner Gesamtstatus nicht fälschlich als pauschale Produktionsfreigabe interpretiert.

Ein konkreter Fall: Ein Pull-Request-Workflow kompiliert erfolgreich, aber der Release-Workflow verwendet andere Umgebungsvariablen oder einen anderen Schritt zur Bereitstellung von Signaturmaterial. Wenn beide Läufe nicht getrennt betrachtet werden, sieht das Team zwar einen erfolgreichen Build, hat aber keinen Nachweis für den späteren Veröffentlichungsweg. Halten Sie solche Abhängigkeiten in der Workflow-Inventarliste fest.

Hinweis: Behandeln Sie „Job erfolgreich“, „Artefakt erstellt“ und „Release abgeschlossen“ als unterschiedliche Zustände. Ein grüner Build ist kein Beleg dafür, dass ein signiertes Artefakt hochgeladen oder für Nutzer freigegeben wurde.

Führen Sie die ersten Vergleichsläufe in einem isolierten Zweig oder einem nichtproduktiven Workflow aus. Wählen Sie Projekte, die unterschiedliche Abhängigkeiten und Build-Arten abbilden. Eine einzelne erfolgreiche Anwendung sagt nur etwas über diesen Lauf, diesen Commit und diesen Abhängigkeitsstand aus. Sie beweist nicht, dass sämtliche Repositories oder externen Pakete mit dem neuen Image funktionieren.

Bleiben Abhängigkeiten und Builds auf macOS 27 reproduzierbar? Das lässt sich nur anhand Ihrer eigenen Projekte belegen. Prüfen Sie die Abhängigkeitsauflösung, den Compilerlauf, die Testergebnisse und die erzeugten Artefakte in derselben Revision. Notieren Sie Abweichungen, statt lediglich den abschließenden Status zu übernehmen.

Eine brauchbare Abnahmefolge ist:

1. Wählen Sie je eine repräsentative Anwendung für die wichtigsten Build-Arten Ihres Teams.
2. Fixieren Sie Commit und Abhängigkeitsstand, damit ein Vergleich nicht unbemerkt andere Eingaben enthält.
3. Starten Sie den isolierten Workflow mit dem Xcode-27-Runner und protokollieren Sie macOS-, Xcode- und Image-Informationen.
4. Prüfen Sie, ob Abhängigkeiten ohne manuelle Änderungen aufgelöst werden.
5. Vergleichen Sie Compiler- und Testresultate sowie die erwarteten Artefakte.
6. Wiederholen Sie den Lauf für die für Ihr Team kritischen Projekte und dokumentieren Sie bekannte Abweichungen.

Notieren Sie auch, welche Caches eingesetzt werden und ob sie vom vorherigen Lauf stammen. Andernfalls kann ein erfolgreicher Job unklar lassen, ob er die benötigten Werkzeuge und Abhängigkeiten frisch bezogen oder vorhandene Zwischenergebnisse wiederverwendet hat. Das ist besonders wichtig, wenn ein Fehler nur auf einem sauberen Runner auftritt.

Die Abnahmeakte sollte deshalb keine bloße Liste grüner Jobs sein. Erfassen Sie für jeden ausgewählten Workflow mindestens den Commit, die Umgebungsnachweise, den Teststatus, Hinweise zu Warnungen und den Artefaktverweis. Erklären Sie Abweichungen, die Ihr Team akzeptiert. Wenn eine Build-Ausgabe gegenüber der bisherigen Baseline anders ausfällt, muss die verantwortliche Anwendungsmannschaft beurteilen, ob das erwartbar ist oder eine weitere Untersuchung erfordert.

Kann die Änderung auf macOS 27 iOS-Build, Signierung oder Upload beeinflussen? Das kann nicht allein aus dem erfolgreichen Build abgeleitet werden. Prüfen Sie jeden Abschnitt der Release-Kette mit dem tatsächlichen Projekt, den vorgesehenen Zertifikaten und den im Team konfigurierten Berechtigungen. Für die Xcode-Systemanforderungen ist Apples Dokumentation zu unterstützten Systemen maßgeblich; vergleichen Sie diese Anforderungen mit der verwendeten Umgebung.

Führen Sie die Abnahme in der Reihenfolge aus, in der Ihre Release-Pipeline die Schritte tatsächlich durchläuft:

• Simulator: Starten Sie die für Ihr Projekt vorgesehenen Tests und sichern Sie deren Ergebnis. Halten Sie fest, welcher Simulator und welche Testkonfiguration im Lauf ausgewählt waren.
• Archivierung: Erzeugen Sie ein Archiv aus dem freigegebenen Commit. Prüfen Sie, ob es sich mit dem erwarteten Build-Schritt erzeugen und anschließend weiterverarbeiten lässt.
• Signierung: Kontrollieren Sie, ob die tatsächlich konfigurierte Identität und die erwarteten Berechtigungen verwendet wurden. Dokumentieren Sie den Status, aber geben Sie keine Zertifikate, Schlüssel oder Geheimnisse in Protokollen aus.
• Upload: Führen Sie den vorgesehenen Upload-Weg aus und erfassen Sie dessen Ergebnis getrennt vom Archivierungsstatus.

Apple beschreibt die Vorbereitung einer App für die Verteilung in der Dokumentation zur App-Distribution mit Xcode. Für den Upload von Builds zu App Store Connect verwenden Sie Apples Anleitung zum Hochladen von Builds. Falls Ihr Ablauf macOS-Code signiert, prüfen Sie zusätzlich die Apple-Dokumentation zur Verteilung signierten Codes. Diese Quellen legen nicht fest, welche Identitäten oder Zugriffsrechte Ihr Unternehmen verwendet; das müssen Sie anhand Ihrer eigenen Konfiguration prüfen.

Führen Sie Simulatorprüfung, Archivierung, Signierung und Upload in der Abnahmedokumentation als getrennte Prüfpunkte. Wenn Ihr Team nur einen Teil davon in einem sicheren Testablauf ausführen kann, kennzeichnen Sie die nicht geprüften Schritte ausdrücklich. Leiten Sie aus „Archiv erfolgreich“ keine Aussage über einen abgeschlossenen Store-Upload ab.

Die Betriebs- und Sicherheitsteams müssen entscheiden, ob die Änderungen und die Preview-Eigenschaft für den jeweiligen Workflow akzeptabel sind. Diese Bewertung hängt davon ab, welche Daten und Zugangsdaten ein Job verarbeitet, welche Freigaben er besitzt und wie wichtig eine kontrollierte Systembasis für die Veröffentlichung ist. Ersetzen Sie eine konkrete Prüfung nicht durch eine pauschale Aussage zur Sicherheit.

Prüfen Sie bei jedem betroffenen Workflow:

• Welche Geheimnisse und Signaturinformationen sind erreichbar?
• Welche Berechtigungen benötigt der Job tatsächlich?
• Welche Artefakte werden erzeugt und wo werden sie abgelegt?
• Wer darf den Workflow auslösen und wer darf ein Release freigeben?
• Welcher bereits geprüfte Weg übernimmt den Job, wenn die Abnahme fehlschlägt?

Für Teams mit Anforderungen an Datenschutz und DSGVO gehören diese Fragen in die übliche interne Risiko- und Datenschutzbewertung. Dieser Leitfaden ersetzt weder eine rechtliche Prüfung noch interne Richtlinien. Halten Sie fest, welche Daten verarbeitet werden und welche Personen oder Systeme Zugriff darauf haben. Vermeiden Sie, dass Diagnoseschritte versehentlich Signaturgeheimnisse oder personenbezogene Daten in breit zugängliche Jobprotokolle schreiben.

Definieren Sie den Rückfallweg vor der Freigabe. Er muss benennen, welcher bereits geprüfte Workflow oder welcher dedizierte Mac-Build-Kanal die Veröffentlichung übernimmt und wer die Umschaltung freigeben darf. Behaupten Sie keine Wiederherstellungszeit, die Ihr Team nicht getestet hat. Unterscheiden Sie in Ihrem Betriebshandbuch zwischen einem erreichbaren Build-Knoten, einem erfolgreichen CI-Lauf und einer tatsächlich abgeschlossenen Veröffentlichung. Diese Zustände erfordern unterschiedliche Nachweise.

Für die Produktionsentscheidung zählt nicht allein, ob ein Runner technisch einen Build ausführen kann. Entscheidend ist, ob Ihre Organisation die erforderliche Baseline kontrollieren, die kritischen Release-Schritte nachweisen und einen belastbaren Rückfallweg betreiben kann. Die folgende Bedingungsliste unterstützt die Zuweisung, ersetzt jedoch nicht die Ergebnisse Ihrer Abnahme.

• Wenn das Team den Preview-Status akzeptiert, der isolierte Lauf bestanden ist und die betroffenen Jobs keine nicht geprüften Release-Schritte enthalten, dann können Sie diese geeigneten Aufgaben zunächst auf dem verwalteten Runner belassen.
• Wenn die Produktion eine feste, kontrollierbare macOS- und Xcode-Baseline verlangt, dann verwenden Sie für Veröffentlichungen einen dedizierten Mac-Kanal, den Ihr Team tatsächlich geprüft hat.
• Wenn manche Jobs auf dem verwalteten Runner zuverlässig abgenommen sind, während Signierung oder Upload strengere Kontrollen brauchen, dann teilen Sie die Workflows auf: nichtkritische Prüfungen bleiben dort, sensible Release-Schritte laufen über den geprüften Kanal.
• Wenn kein Rückfallweg praktisch ausgeführt und dokumentiert wurde, dann geben Sie den Preview-Runner nicht als alleinigen Produktionspfad frei.

Bei einem dedizierten Knoten müssen Sie auch Verantwortlichkeiten für Aktualisierung, Zugang, Protokollierung und Wiederherstellung festlegen. Der Begriff „dediziert“ allein belegt weder eine bestimmte Verfügbarkeit noch eine bestimmte Sicherheitswirkung. Prüfen Sie, wer Änderungen an der Umgebung vornehmen darf, wie Sie die installierte Toolchain dokumentieren und wie Sie nach einem fehlgeschlagenen Update zum zuvor geprüften Zustand zurückkehren.

Für den Einkauf sollten Sie außerdem Beschaffung und Betrieb getrennt kalkulieren. Ein eigener Mac bindet Kapital und erfordert interne Zuständigkeiten für Wartung und Erneuerung; ein gemieteter Remote-Mac verschiebt Teile der Hardwarebereitstellung, verlangt aber eine Prüfung der tatsächlich angebotenen Umgebung, Zugriffswege und Vertragsbedingungen. Ohne verifizierte Preis- und Konfigurationsdaten ist ein konkreter TCO-Vergleich nicht belastbar. Wenn ein Kauf als Alternative geprüft wird, können Sie die Informationen zur Bestellung eines Mac mini M4 als Ausgangspunkt für Ihre Beschaffungsfragen nutzen. Vergleichen Sie die dort verfügbaren Angaben mit Ihrem Bedarf, statt Annahmen über Ausstattung oder Kosten in die CI-Abnahme einzurechnen.

Ist die öffentliche Preview für eine Unternehmensveröffentlichung geeignet? Nur dann, wenn Ihre Organisation den Preview-Status akzeptiert, die relevanten Workflows erfolgreich und nachvollziehbar geprüft hat und der Rückfallweg funktioniert. Ein pauschales Ja wäre ebenso wenig begründet wie ein pauschales Nein: Maßgeblich sind Ihre Kontrollanforderungen und die Nachweise für den konkreten Release-Pfad.

Bevor Sie freigeben, sollte das Protokoll mindestens festhalten:

• tatsächliches Runner-Image, macOS-Version und Xcode-Version;
• betroffene Workflows und zuständige Teams;
• Ergebnisse für Abhängigkeiten, Kompilierung und Tests;
• getrennte Ergebnisse für Simulator, Archiv, Signierung und Upload;
• geprüfte Berechtigungen und Umgang mit Geheimnissen;
• akzeptierte Abweichungen, Freigabeverantwortliche und getesteten Rückfallweg.

Die entscheidende Abgrenzung lautet: Ein unverändertes Runner-Label ist kein unveränderter Systemnachweis. Ein erfolgreicher Build ist keine bestandene Release-Abnahme. Und eine bestandene Abnahme eines Repositorys ist keine pauschale Kompatibilitätsaussage für alle Unternehmensprojekte. Halten Sie die Freigabe deshalb an konkrete Workflows und Commits gebunden und wiederholen Sie die Prüfung, wenn sich Image-Basis, Xcode-Version oder Ihre Release-Konfiguration ändern.

Wenn Ihre aktuelle Runner-Lösung zwar schnell verfügbar ist, aber eine Preview-Basis, weniger Einfluss auf die Systembaseline und einen zusätzlichen Prüfaufwand für produktive Signatur- und Upload-Schritte mit sich bringt, kann ein Mac-Kanal mit den von Ihnen benötigten Kontrollen die passendere Ergänzung sein. Ein eigener Mac ist sinnvoll, wenn Sie dauerhafte Hardwarekontrolle benötigen; ein gemieteter Mac kann für zeitlich begrenzte oder zusätzliche CI-Kapazität interessant sein, sofern die konkrete Umgebung zu Ihren Anforderungen passt. Prüfen Sie die tatsächlich verfügbaren Versionen, Konfigurationen, Zugriffswege und Wiederherstellungsnachweise, bevor Sie entscheiden. Für eine solche Prüfung können Sie die aktuell belegbaren Angaben zu den Remote-Mac-Angeboten von KVMNODE mit Ihrer Abnahmeliste abgleichen; nicht verifizierte Eigenschaften sollten nicht als Produktionszusage gelten.