Unterstützt der GitLab Hosted macOS Runner Xcode 27? Unternehmensauswahl 2026

Stand 05.09.2026 sollten Sie Xcode 27 nicht vollständig auf den GitLab Hosted macOS Runner migrieren: GitLab listet offiziell noch kein Xcode-27-Image. Ihre umsetzbare Wochenentscheidung lautet deshalb: stabile Toolchains und nicht sensible Prüfungen im Hosted-Pool belassen, während Sie für Xcode-27-Tests, private Abhängigkeiten und Produktionssignierung einen dedizierten selbstverwalteten Mac-Knoten aufbauen. Apple stellt Xcode 27 bereits als Beta-Reihe bereit, während GitLab den Hosted-macOS-Dienst weiterhin als Beta führt und die veröffentlichten Images bei macOS 15/Xcode 16 sowie macOS 26/Xcode 26 liegen (GitLab-Imageübersicht, Apple Xcode 27 Release Notes).

Diese Entscheidung gilt für Sie, wenn Sie eine Xcode-27-Adaptionsplanung für GitLab CI/CD erstellen und die tatsächliche Image-Grenze kennen müssen. Sie richtet sich außerdem an IT-Verantwortliche, die Signaturdaten, interne Abhängigkeiten und Netzwerkzugriffe prüfen, sowie an technische Leiter und Einkaufsteams, die Hosted-Compute mit den vollständigen Kosten eines selbstverwalteten Mac vergleichen.

SECTION 01 GitLab Hosted macOS Runner Xcode 27: Versionsstatus

Der relevante Meilenstein ist nicht die bloße Veröffentlichung einer neuen Xcode-Version, sondern ihre Verfügbarkeit in einem Image, das Ihr Runner tatsächlich auswählen und reproduzierbar verwenden kann. Am 05.09.2026 sind drei Zustände getrennt zu bewerten:

• Apple veröffentlicht Xcode 27 als Beta-Reihe.
• GitLab kennzeichnet Hosted Runner auf macOS als Beta-Dienst.
• Die öffentlich aufgeführten Hosted-Images enthalten macOS 15 mit Xcode 16 sowie macOS 26 mit Xcode 26, nicht jedoch ein Xcode-27-Image.

Diese drei Aussagen beschreiben unterschiedliche Lebenszyklen. Aus der Xcode-27-Beta folgt nicht, dass GitLab das passende Image bereits anbietet. Aus dem Beta-Status des Hosted-Dienstes folgt ebenso wenig ein bestätigter Termin für Xcode 27. GitLab beschreibt in der offiziellen Dokumentation den jeweils verfügbaren Imagebestand; eine spätere Ergänzung, eine Änderung des Dienststatus oder ein Wechsel der Compute-Regeln muss deshalb unmittelbar vor Ihrer Migration erneut geprüft werden. Die allgemeine Dokumentation zu GitLab Hosted Runnern trennt dabei den Hosted-Dienst von einzelnen Betriebssystem- und Toolchain-Images.

Die Antwort auf die Frage nach dem Supportzeitpunkt lautet daher: Ein belastbares Datum ist öffentlich nicht bestätigt. Weder Medienberichte noch Community-Spekulationen sollten als Beschaffungsgrundlage dienen. Für Ihre Planung zählt erst ein offiziell dokumentiertes Image, anschließend ein eigener Pipeline-Test mit Compiler, Simulator Runtime, Abhängigkeiten, Signatur und Archivierung.

Meilensteinmodell für die Versionsentscheidung

Aktueller Meilenstein: Xcode 27 ist als Beta verfügbar, im GitLab-Hosted-Imagekatalog aber nicht aufgeführt.

Freigabemeilenstein: GitLab dokumentiert ein Xcode-27-Image und dessen Lebenszyklus eindeutig.

Technischer Abnahmemeilenstein: Ihre reale Pipeline baut, testet, archiviert und signiert mit demselben Image reproduzierbar.

Produktionsmeilenstein: Sicherheits-, Netzwerk- und Wiederherstellungsprüfungen sind für den vorgesehenen Runner-Typ abgeschlossen.

Bis zum Freigabemeilenstein ist ein selbstverwalteter Mac die kontrollierbare Ausweichroute. Der Host kann entweder physisch im Unternehmen stehen oder als dedizierte Remote-Mac-Ressource betrieben werden. Entscheidend sind nicht die Bezeichnung „Cloud“ oder „lokal“, sondern Zugriff, Isolation, Betriebspflichten und Nachweisbarkeit.

SECTION 02 Umgebungssteuerung und Reproduzierbarkeit

Ein auswählbares Hosted-Image bedeutet nicht, dass Sie dessen Aktualisierungsfenster, vorinstallierte Werkzeuge oder jede Simulator Runtime frei bestimmen. Der Vorteil liegt in der geringeren Hostpflege; die Grenze liegt bei der Abhängigkeit vom veröffentlichten Imagebestand. Ein selbstverwalteter Mac erlaubt dagegen die Installation einer benötigten Xcode-Version und zusätzlicher Werkzeuge, überträgt aber die Verantwortung für Patchstand, Bereinigung, Monitoring und Wiederherstellung an Ihr Team.

Für die Entscheidung zwischen Hosted macOS und selbstverwaltetem Mac sollten Sie deshalb nicht nur den Image-Namen vergleichen. Erstellen Sie eine Toolchain-Liste mit:

• Xcode-Version und Buildnummer;
• benötigten Simulator Runtimes;
• Swift- und Paketmanager-Abhängigkeiten;
• Ruby-, Python- oder Node-Werkzeugen, sofern Ihre Pipeline sie verwendet;
• privaten Binärdateien und internen Zertifikatsketten;
• Cache-Verhalten und Artefakt-Aufbewahrung;
• erwarteten Änderungen durch automatische Image-Aktualisierungen.

Halten Sie diese Liste in der Pipeline-Konfiguration oder in einem versionierten Betriebsdokument fest. Ein selbstverwalteter Mac ist erst dann reproduzierbar, wenn seine Installation nicht vom Gedächtnis einer einzelnen Person abhängt. Umgekehrt ist ein Hosted Runner erst dann geeignet, wenn die von GitLab gelieferte Umgebung exakt zu Ihren Abnahmetests passt.

Die praktische Prüfung erfolgt mit demselben Commit und denselben Eingabedaten. Vergleichen Sie nicht nur den erfolgreichen Status, sondern auch erzeugte Archive, Testberichte, Build-Logs und verwendete Toolchain-Versionen. Ein sauberer Einzelbuild beweist weder stabile Wiederholbarkeit noch eine ausreichende Cache-Strategie.

Wenn Sie für die Mac-Seite noch keine kontrollierte Umgebung besitzen, hilft eine Dokumentation zur Isolation von Xcode-27-AI-Agent-Umgebungen bei der Abgrenzung von Identitäten, Arbeitsbereichen und sensiblen Befehlen. Sie ersetzt jedoch nicht Ihre eigene GitLab-Pipeline-Abnahme.

SECTION 03 Signierung, Identitäten und Aufgabenisolation

Für normale Kompilierungs- und Testaufgaben kann ein Hosted Runner attraktiv sein, weil die Hostbereitstellung nicht vollständig bei Ihnen liegt. Eine Produktionssignierung ist eine andere Risikoklasse. Hier müssen Sie prüfen, wie Zertifikate, Provisioning Profiles, Keychain-Inhalte, Apple-Konten und temporäre Arbeitsverzeichnisse in Ihrer Sicherheitsrichtlinie behandelt werden.

Die zentrale Frage ist nicht, ob ein macOS-Runner technisch einen Signaturbefehl ausführen kann. Entscheidend ist, ob der konkrete Ausführungspfad Ihre Anforderungen an Geheimniszugriff, Nachvollziehbarkeit, Bereinigung, Rollenbindung und Wiederherstellung erfüllt. Ein temporärer Hosted-Auftrag kann für nicht sensible Prüfungen geeignet sein, während ein dedizierter selbstverwalteter Knoten die bessere Grenze für die finale Signierung bildet.

Für die Produktionsfreigabe sollten Sie diese Nachweise verlangen:

1. Welche Identität darf den Signaturjob starten?
2. Wie werden Zertifikat und Provisioning Profile injiziert?
3. Wie lange verbleiben Schlüsselmaterial und temporäre Dateien auf dem Knoten?
4. Wie wird ein fehlgeschlagener oder abgebrochener Auftrag bereinigt?
5. Welche Person oder welcher Dienst darf den Keychain-Zugriff genehmigen?
6. Wie wird ein kompromittierter Knoten isoliert und ersetzt?
7. Welche Logs belegen den verwendeten Commit, das Image und das Signaturprofil?

Die Antworten müssen zu Ihrer Unternehmensrichtlinie und zu Ihren Prüfanforderungen passen. Ein selbstverwalteter Mac reduziert die Abhängigkeit von einem fremden Ausführungsmodell, erzeugt aber neue Pflichten: physische oder logische Zugangskontrolle, Patchmanagement, Runner-Registrierung, Schlüsselrotation, Backup der Konfiguration und dokumentierte Löschung.

Wenn Ihre Organisation eine detaillierte Signaturarchitektur benötigt, sollten Sie die Sicherheitsanforderungen für iOS-Signaturknoten gemeinsam mit dem Security-Team gegen die tatsächliche Runner-Konfiguration prüfen. Für sensible Produktionsjobs gilt als konservative Standardentscheidung: dedizierter, auditierter Knoten statt gemeinsamer Ausführungspool.

SECTION 04 Private Netzwerke und Datenabgrenzung

Ein Hosted Runner kann Ihren GitLab-Code erreichen und trotzdem nicht die gesamte interne Build-Kette erreichen. Private Paketregister, interne APIs, geschützte Artefaktspeicher, feste Ausgangsadressen, Proxy-Regeln oder IP-Allow-Lists erzeugen jeweils eigene Randbedingungen. Die erfolgreiche Quellcodeübertragung ist deshalb kein Beweis für vollständige Netzwerkkonnektivität oder erfüllte DSGVO-Anforderungen.

Erstellen Sie vor der Auswahl eine Netzwerkflusskarte. Sie sollte mindestens Repository, Paketquellen, Artefaktspeicher, Apple-Dienste, Testsysteme, interne APIs, Proxy, DNS und Zielsysteme enthalten. Kennzeichnen Sie dabei, welche Verbindung eingehend, ausgehend, authentifiziert oder nur über eine feste Adresse zulässig ist.

Ein selbstverwalteter Mac ist für private Abhängigkeiten häufig leichter in vorhandene Sicherheitszonen einzubinden. Das bedeutet jedoch nicht, dass er automatisch sicher ist. Ein dauerhaft erreichbarer Buildknoten kann bei falscher Segmentierung einen größeren Schaden verursachen als ein kurzlebiger Auftrag. Beschränken Sie daher ausgehende Ziele, trennen Sie Test- und Signaturaufgaben und dokumentieren Sie die erlaubten Endpunkte.

Für jeden fehlgeschlagenen Pipeline-Schritt benötigen Sie eine verwertbare Ursache: DNS-Auflösung, TLS-Prüfung, Authentifizierung, fehlende Route, abgelehnte IP-Adresse oder abgelaufene Zugangsdaten. Lassen Sie die Netzwerkflusskarte, die Endpunktliste und die Fehlerprotokolle durch das zuständige Sicherheitsteam bestätigen. Erst diese Signatur macht aus einer technischen Vermutung eine belastbare Beschaffungsentscheidung.

SECTION 05 Kapazität, Warteschlange und Wiederherstellung

Die Kapazität eines Mac-Buildsystems lässt sich nicht aus der Chipbezeichnung oder einem einzelnen sauberen Build ableiten. Für Hosted Runner müssen Sie Wartezeit, Ausführungszeit und abgerechnete Compute-Nutzung getrennt erfassen. GitLab beschreibt die Berechnung der Compute Minutes und die Abrechnungslogik in einer eigenen Dokumentation; die dort geltenden Regeln können sich unabhängig vom Xcode-Image ändern (GitLab Compute Minutes).

Bei selbstverwalteten Macs zählen dagegen produktive Auslastung, Leerlauf, Wartungsfenster, Cache-Treffer, Strom- und Unterbringungskosten, administrative Arbeitszeit sowie die Wiederanlaufzeit nach einem Fehler. Ein Knoten mit niedriger Rechnung kann wirtschaftlich schlechter sein, wenn er häufig manuell repariert wird oder bei einem Ausfall keine Ausweichkapazität vorhanden ist.

Testen Sie mit einer realistischen Auftragsmischung:

1. Pull-Request-Kompilierung;
2. Unit- und UI-Tests;
3. Archivierung;
4. Signierung in einem separaten kontrollierten Job;
5. Wiederholung bei Cache-Treffern und Cache-Verlust;
6. Verhalten nach Neustart oder Runner-Ausfall.

Diese Aufzählung beschreibt ein Testdesign, keine vorweggenommene Kapazitätszahl. Verwenden Sie Ihre tatsächlichen Jobs, weil ein einzelner Build weder Spitzenlast noch Parallelität abbildet. Erfassen Sie mindestens Queue-Zeit, Laufzeit, Fehlerrate, Cache-Zustand, Wiederanlaufdauer und manuelle Eingriffe.

Für Hosted Runner können Sie mit einem Verbrauchsmodell arbeiten:

Gesamtkosten = Compute-Nutzung × veröffentlichter Abrechnungssatz + Zusatzdienste

Für selbstverwaltete Mac-Knoten lautet das Modell:

Gesamtkosten = Hardware oder Mietkosten + Betrieb + Wartung + Sicherheitsaufwand + Ausfallrisiko

Die Variablen müssen aus Ihrer Rechnung, Ihrem Mietangebot oder eigenen Betriebsdaten stammen. Tragen Sie keine scheinpräzise Knotenzahl ein, bevor Sie die reale Jobverteilung und das gewünschte Spitzenverhalten gemessen haben. Das GitLab Runner Fleet Dashboard kann bei der Sichtbarkeit der Runner-Flotte helfen; es ersetzt jedoch keine Kosten- und Wiederherstellungsanalyse.

SECTION 06 Entscheidungsbedingungen für den Runner-Pool

Die folgende Verzweigung ist für eine erste Architekturentscheidung verwendbar:

• Wenn Ihre Pipeline die aktuell verfügbaren Xcode-Versionen verwendet, keine privaten Endpunkte benötigt und keine produktiven Signaturgeheimnisse berührt, dann wählen Sie zunächst den Hosted Runner.
• Wenn Xcode 27 erforderlich ist, aber noch kein offizielles Hosted-Image vorliegt, dann wählen Sie einen selbstverwalteten Mac für einen begrenzten Proof of Concept.
• Wenn der Job auf interne Paketregister, feste Ausgangsadressen oder geschützte Unternehmensdienste zugreifen muss, dann wählen Sie einen entsprechend segmentierten selbstverwalteten Knoten.
• Wenn der Auftrag ein App-Store-Archiv mit produktiven Signaturidentitäten erzeugt, dann führen Sie ihn auf einem dedizierten, auditierten Vertrauensknoten aus.
• Wenn die Last stark schwankt und die stabile Toolchain bereits im Hosted-Pool verfügbar ist, dann kombinieren Sie Hosted Runner für elastische Validierung mit selbstverwalteten Macs für kontrollierte Jobs.
• Wenn Ihr Team keine laufende Hostpflege, Schlüsselverwaltung oder Wiederherstellung übernehmen kann, dann ist ein dauerhaft selbstverwalteter Knoten nur nach geklärtem Betriebsmodell sinnvoll.
• Wenn ein einzelner Mac zum unverzichtbaren Produktionsengpass würde, dann planen Sie eine dokumentierte Rückfallkapazität, bevor Sie die Migration freigeben.

Damit ist auch die Frage nach einer separaten GitLab-Runner-Instanz für Xcode 27 beantwortet: Für einen kontrollierten Xcode-27-Test ist ein eigener Runner sinnvoll, sobald Sie Image, Zugriffsrechte, Tags und Signaturgrenzen von der bestehenden Flotte trennen müssen. Eine zusätzliche Registrierung allein löst jedoch kein fehlendes Xcode-27-Image im Hosted-Dienst. Für die Installation eines selbstverwalteten macOS-Runners können Sie die offizielle GitLab-Installationsdokumentation für macOS als technische Referenz verwenden; die dort beschriebene Runner-Installation ersetzt weder die Auswahl eines geeigneten Xcode-Standes noch die Sicherheitsabnahme.

SECTION 07 TCO- und Beschaffungsmatrix

Vergleichen Sie nicht nur die sichtbare Hosted-Rechnung mit dem Kaufpreis eines Mac. Bei einem selbstverwalteten System gehören Installation, Ersatz, Überwachung, Zertifikatsverwaltung, Patchfenster, Netzwerkfreigaben und Ausfallbehandlung in dieselbe Betrachtung. Bei Hosted Runnern gehören Verbrauchsregeln, Wartezeiten, Abhängigkeit von verfügbaren Images und mögliche Pipeline-Anpassungen in die Bewertung.

Für eine interne Einkaufsfreigabe können Sie zusätzlich diese Kostenvariablen dokumentieren:

Wenn Sie eine dedizierte Remote-Mac-Ressource als selbstverwalteten Knoten prüfen, sollten Sie Mietmodelle für Mac-Umgebungen nicht nur nach der Monatsgebühr bewerten. Fordern Sie die Angaben zu Root-Zugriff, Lieferweg, Standort, Laufzeit, Neustart, Netzwerkzugriff und Support so an, dass sie direkt in Ihre TCO-Tabelle übernommen werden können. Nicht jede Mietlösung erfüllt automatisch Ihre Anforderungen an Signierung oder private Daten.

SECTION 08 Beschaffungsentscheidung für 2026

Für die meisten Unternehmen ist ein gemischter Runner-Pool die belastbarste Übergangslösung. Der Hosted-Pool übernimmt vorhandene, stabile Toolchains und nicht sensible Prüfungen. Ein selbstverwalteter Mac übernimmt den Xcode-27-Pilot, interne Abhängigkeiten und Jobs, deren Signatur- oder Netzwerkgrenzen nicht in den Hosted-Prozess passen.

Die Entscheidung sollte an Meilensteine gebunden bleiben:

• Jetzt: GitLab-Imagekatalog, Hosted-Status, Apple Release Notes und Compute-Regeln erneut dokumentieren.
• Diese Woche: reale Xcode-27-Aufträge auf einem getrennten selbstverwalteten Runner definieren.
• Vor der Produktionsfreigabe: Signatur-, Netzwerk-, Queue- und Wiederherstellungstests mit echten Pipeline-Aufträgen durchführen.
• Bei offizieller Image-Erweiterung: Hosted-Runner erneut abnehmen, nicht automatisch umstellen.
• Bei wechselnder Last: Hosted-Kapazität und selbstverwaltete Grundkapazität anhand von Unternehmensrechnungen und Testprotokollen neu kalkulieren.

Ein reiner Hosted-Ansatz ist aktuell wegen der dokumentierten Xcode-27-Lücke keine ausreichende Produktionsstrategie. Ein ausschließlich selbstverwalteter Ansatz kann dagegen unnötige Fixkosten, Wartungsaufwand und ungenutzte Kapazität erzeugen, wenn ein Teil Ihrer Builds bereits sicher und wirtschaftlich elastisch im Hosted-Pool laufen kann.

Wenn Sie heute nur eine Entscheidung treffen, markieren Sie jeden Job nach vier Eigenschaften: Xcode-27-Abhängigkeit, Signatursensitivität, privater Netzwerkbedarf und Lastschwankung. Hosted Runner sind dort sinnvoll, wo die stabile Toolchain verfügbar und das Risiko begrenzt ist. Einen dedizierten Mac sollten Sie dort einsetzen, wo Version, Netzwerk oder Signatur nicht delegiert werden können.

Ein vollständig eigener Mac im Büro wirkt auf den ersten Blick kontrollierbar, bringt aber Beschaffung, Ersatzteile, lokale Erreichbarkeit, Stromversorgung, Patchfenster und Ausfallwiederherstellung mit. Eine generische Cloud-Alternative kann an fehlender Apple-Hardware, eingeschränkter Toolchain-Kontrolle oder nicht passenden Signatur- und Netzwerkgrenzen scheitern. Wenn Sie für einen Xcode-27-PoC kurzfristig eine reale Apple-Silicon-Umgebung mit Root-Zugriff benötigen, kann die Miete eines dedizierten Mac über VPSNIX den Test schneller starten als der Kauf und die interne Inbetriebnahme; sie ersetzt jedoch nicht Ihre Sicherheitsfreigabe und ist bei dauerhaft hoher, planbarer Auslastung nicht automatisch die günstigste Lösung.

Entscheiden Sie daher nicht nach dem Etikett „Hosted“ oder „selbstverwaltet“, sondern nach dem Nachweis: offizielles Image, reproduzierbarer Build, kontrollierte Identitäten, erreichbare private Endpunkte, gemessene Queue und dokumentierte Wiederherstellung. Sobald diese Nachweise vorliegen, können Sie den Xcode-27-Knoten erweitern oder einen später offiziell unterstützten Hosted Runner ohne unkontrollierte Produktionsmigration neu bewerten.