GitHub Actions macOS 26 Runner: arm64 oder Intel wählen? 2026

SECTION 01Schnelle Entscheidung: arm64 als Ausgangspunkt, Intel bei konkretem Bedarf

Symptom: Ihr Team muss ein Runner-Label für GitHub Actions auf macOS 26 festlegen.
Schnellste Lösung: Wählen Sie für neue Projekte und reguläre Builds mit Apple-Silicon-Ziel zunächst arm64; verwenden Sie Intel gezielt, wenn Sie Intel-Verhalten, eine dafür nötige Abhängigkeit oder ein entsprechendes Lieferziel prüfen müssen.

Wer beide Architekturen unterstützen muss, sollte die passenden Build- und Testjobs als Matrix ausführen. Ein erfolgreicher Build auf einem Host beweist nicht, dass alle Zielarchitekturen abgedeckt sind. Eine eigene Remote-Mac-Umgebung kommt erst dann in Betracht, wenn der Workflow dauerhaft verfügbare Ressourcen, mehr Kontrolle über den Host oder einen abweichenden Betriebsablauf erfordert.

Dieser Beitrag richtet sich an unabhängige Entwickler, die einen Runner für den täglichen iOS- oder macOS-Build wählen müssen.
Apple-Plattformteams erhalten eine Prüfmethode für Intel-Ziele und ältere Abhängigkeiten.
CI- und Plattformverantwortliche können daraus Regeln für Standardlabel, Matrixjobs und begründete Ausnahmen ableiten.

Letzte Aktualisierung: 02.11.2026. Die Angaben zu Labels und Architektur wurden anhand der GitHub-Ankündigung zur allgemeinen Verfügbarkeit von macOS 26, der Dokumentation zu gehosteten Runnern und der Xcode-27-Image-Ankündigung abgeglichen. Prüfen Sie vor einer Produktionsumstellung, ob Labels, Verfügbarkeit und Image-Inhalt weiterhin dem aktuellen Stand entsprechen.

SECTION 02Was die Labels aussagen – und was nicht

GitHub dokumentiert für macOS 26 ein arm64-Label und ein separates Intel-Label. Diese Zuordnung beschreibt die Architektur des Runner-Hosts. Sie ist nicht gleichbedeutend mit der Architektur Ihres Produkts, dem Format eines Build-Artefakts oder dem Umfang Ihrer Abnahmetests. GitHubs Anleitung zur Auswahl eines Runners ist daher vor allem als Auswahl der Ausführungsumgebung zu lesen.

Auch beim Artefakt ist eine getrennte Prüfung nötig. Ein Projekt kann beispielsweise für mehrere Plattformen oder Architekturen bauen, obwohl der Compiler auf nur einer Hostarchitektur läuft. Umgekehrt garantiert ein erfolgreicher Build auf einem Intel-Runner nicht, dass der ausgelieferte Build arm64 unterstützt. Apple beschreibt im Leitfaden zum Erstellen eines universellen macOS-Binärprogramms, wie ein universelles Binärprogramm für mehrere Architekturen erstellt wird. Für den CI-Entscheid zählt jedoch, ob Ihr Workflow die erforderlichen Scheiben tatsächlich erzeugt und prüft.

SECTION 03Für unabhängige Entwickler: den Standardjob am Lieferziel ausrichten

Wenn Sie allein oder in einem kleinen Team entwickeln, wählen Sie nicht nach einem abstrakten Leistungsvorteil, sondern nach dem Ziel, das Sie tatsächlich ausliefern. Für ein neues Projekt, dessen reguläre Entwicklung auf Apple Silicon ausgerichtet ist, ist arm64 ein sinnvoller Startpunkt. Das spart Ihnen aber keine Prüfung: Eine veraltete Binärabhängigkeit, ein Installationsskript mit Architekturannahmen oder eine Action ohne passende Unterstützung kann den Wechsel blockieren.

Führen Sie den bestehenden Workflow zunächst unverändert unter dem neuen Label aus. Vergleichen Sie nicht nur den Exit-Code, sondern auch die erzeugten Artefakte, Warnungen und Testergebnisse. Halten Sie fest, welche Abhängigkeiten aufgelöst wurden und ob ein Skript externe Programme mit fest codierten Pfaden oder Architekturannahmen startet. Bei einem Fehler sollten Sie zuerst feststellen, ob er aus der Toolchain, einer nativen Abhängigkeit oder der Runner-Konfiguration kommt. Ein pauschaler Rückwechsel auf Intel verdeckt die Ursache womöglich nur.

Die Versionsangabe ist ebenfalls Teil der Prüfung. GitHub veröffentlichte die allgemeine Verfügbarkeit des macOS-26-Runner-Images im Februar 2026; die Verfügbarkeit des Xcode-27-Images wurde in einer eigenen Ankündigung im Oktober 2026 bekannt gegeben. Verwechseln Sie diese beiden Aussagen nicht mit einer Garantie, dass jedes beliebige Label automatisch genau die von Ihrem Workflow erwartete Toolchain enthält. Prüfen Sie die Xcode-27-Veröffentlichungshinweise von Apple, bevor Sie eine feste Toolchain-Annahme in den Workflow schreiben.

SECTION 04Für Apple-Silicon-Teams: den vollständigen Workflow auf arm64 abnehmen

Ein arm64-Runner ist erst dann eine belastbare Standardwahl, wenn Ihr realer Arbeitsablauf funktioniert. Ein kurzer Kompiliertest prüft weder alle Abhängigkeiten noch Signierung, Tests und Veröffentlichung. Führen Sie deshalb nicht nur einen leeren Beispielbuild aus, sondern einen repräsentativen Workflow mit denselben Installations- und Buildschritten, die später in der CI laufen sollen.

Prüfen Sie insbesondere, ob Drittanbieter-Tools native Komponenten mitbringen und ob ein Skript stillschweigend Intel-spezifische Dateien erwartet. Bei einem Architekturfehler hilft es, den Build-Aufruf, die aufgelösten Abhängigkeiten und die betroffene Binärdatei gemeinsam zu betrachten. Apple führt in der technischen Notiz zum Beheben von Buildfehlern für Apple Silicon typische Ursachen und Diagnoseansätze auf. Nutzen Sie diese Quelle zur Einordnung konkreter Compiler- oder Linkerfehler, statt die Architektur des gesamten Projekts vorschnell als inkompatibel einzustufen.

Hinweis für die Abnahme: Lassen Sie den neuen Runner zunächst einen bestehenden Job parallel oder als klar gekennzeichnete Testausführung durchlaufen. Ändern Sie das Standardlabel erst, wenn Artefakt, Tests und benötigte Veröffentlichungsaufgaben geprüft sind und ein Rückweg dokumentiert ist.

Für die Wartung ist außerdem wichtig, zwischen einem Fehler im eigenen Build und einer Einschränkung des gehosteten Runner-Angebots zu unterscheiden. GitHub beschreibt in den Nutzungshinweisen für gehostete Runner die Betriebsbedingungen dieser Umgebung. Größere Runner haben eigene Fähigkeiten und Einschränkungen für macOS; übertragen Sie deren Regeln nicht ungeprüft auf alle Runner-Klassen. Wenn Ihr Job eine bestimmte Hostkontrolle benötigt, verifizieren Sie diese für das konkrete Angebot und den konkreten Workflow.

SECTION 05Für Teams mit Intel-Ziel und älteren Abhängigkeiten: die Ausnahme begründen

Wenn Ihre Anwendung Intel-Macs weiterhin unterstützt, brauchen Sie einen Test, der diese Zusage abbildet. Legen Sie fest, ob die CI ein Intel-Artefakt bauen, bestehende Tests auf Intel ausführen oder einen dort auftretenden Fehler reproduzieren soll. Das sind unterschiedliche Anforderungen: Ein erfolgreicher Compile-Schritt kann eine falsche Laufzeitannahme, eine nicht geladene Bibliothek oder einen Fehler in einer späteren Veröffentlichung nicht ausschließen.

Bei älteren Abhängigkeiten sollten Sie eine kleine Bestandsaufnahme vor dem Wechsel machen:

• Erfassen Sie native Binärdateien und prüfen Sie, für welche Architekturen sie tatsächlich vorliegen.
• Suchen Sie in Installations- und Buildskripten nach festen Pfaden, Architekturprüfungen und Annahmen über Werkzeuge.
• Prüfen Sie Drittanbieter-Actions und externe Buildschritte auf dokumentierte Architekturvoraussetzungen.
• Speichern Sie die konkrete Fehlermeldung, den betroffenen Schritt und das verwendete Runner-Label.
• Entscheiden Sie danach, ob der Intel-Job eine dauerhafte Produktprüfung oder nur eine zeitlich begrenzte Diagnoseausnahme ist.

Schlägt ein Schritt ausschließlich auf arm64 fehl, ist Intel als gezielter Diagnoseweg nützlich. Das ist jedoch keine ausreichende Begründung, sämtliche Jobs dauerhaft auf Intel zu legen. Umgekehrt sollten Sie eine notwendige Intel-Abnahme nicht aus dem Workflow entfernen, nur weil der arm64-Build besser in Ihre tägliche Entwicklung passt. Die Entscheidung folgt dem Supportversprechen und den nachgewiesenen Abhängigkeiten, nicht einer allgemeinen Vorliebe für eine Hostarchitektur.

SECTION 06Häufige Fragen zu Labels und Xcode 27

Die folgenden Antworten ergänzen die Auswahlregeln um die häufigsten Unsicherheiten bei Label, Produktziel und Toolchain. Prüfen Sie vor einer produktiven Festlegung weiterhin die jeweils verlinkten offiziellen Dokumente, weil sich Runner-Labels und Image-Inhalte ändern können.

Worin unterscheiden sich die macOS-26-Runner für arm64 und Intel?

Die Labels bezeichnen unterschiedliche Runner-Architekturen: GitHub ordnet macos-26 einem arm64-Runner und macos-26-intel einem Intel-Runner zu. Das sagt zunächst etwas über den Host aus, nicht automatisch darüber, welche CPU-Architekturen Ihr fertiges Programm unterstützt. Prüfen Sie deshalb zusätzlich Build-Einstellungen, eingebundene Binärdateien und Tests auf dem jeweils relevanten Ziel.

Welches Runner-Label passt für die CI eines iOS-Projekts?

Wenn Ihre reguläre Entwicklung und Ihre Abhängigkeiten auf Apple Silicon ausgelegt sind, starten Sie mit macos-26 und führen den vollständigen Projektworkflow aus. Wechseln Sie nicht allein wegen eines erfolgreichen Builds zur Annahme, Intel sei abgedeckt. Wenn Ihr Produkt Intel-Macs unterstützt oder dort ein Fehler reproduziert werden muss, ergänzen Sie gezielte Intel-Builds und Tests mit macos-26-intel.

Für welche Prüfungen ist ein macos-26-intel-Runner sinnvoll?

Nutzen Sie ihn, wenn Intel-Unterstützung Teil Ihres Lieferumfangs ist, ein Fehler nur auf Intel auftritt oder eine native Abhängigkeit dort ausdrücklich geprüft werden muss. Er eignet sich außerdem für einen gezielten Vergleich des Build- und Testverhaltens. Verwenden Sie ihn nicht pauschal für jeden Job, wenn weder Zielgruppe noch Abhängigkeiten eine Intel-Prüfung verlangen.

Welches Runner-Label sollte ein Workflow mit Xcode 27 verwenden?

Entscheidend sind die von GitHub bereitgestellte Xcode-27-Umgebung, die passende macOS-Version und die Architektur, die Ihr Job tatsächlich abdecken soll. Prüfen Sie die aktuelle Image-Ankündigung und die Apple-Veröffentlichungshinweise, bevor Sie das Label festschreiben. Beginnen Sie für Apple-Silicon-Ziele mit arm64; ergänzen Sie Intel nur, wenn Projektanforderungen oder Abnahmekriterien es begründen.

SECTION 07Für Release-Verantwortliche: Signierung getrennt von der Architektur prüfen

Signierung, Registrierung von Testgeräten und Runner-Architektur werden in CI-Konfigurationen oft zu einem einzigen Problem vermischt. Behandeln Sie sie als getrennte Prüfbereiche. Ein Runner-Label beantwortet die Frage, auf welchem Host ein Job läuft; es beantwortet nicht automatisch, welche Zugangsdaten, Profile, Berechtigungen oder Geräteeinträge ein Release-Schritt benötigt.

Gehen Sie für den Releasepfad den konkreten Workflow durch. Identifizieren Sie zunächst, an welcher Stelle Signierung und Veröffentlichung stattfinden und welche Geheimnisse dieser Job lesen darf. Prüfen Sie anschließend, ob der betroffene Build-Schritt tatsächlich architekturabhängig ist oder ob ein Fehler beispielsweise aus einer fehlenden Berechtigung, einem Profil oder einer falschen Projekteinstellung stammt. Vergleichen Sie die notwendigen Anforderungen mit den offiziellen Vorgaben von Apple und GitHub, statt eine Einschränkung eines bestimmten Angebots auf sämtliche gehosteten Runner zu übertragen.

Wenn Ihr Veröffentlichungsprozess bestimmte Hostmerkmale oder eine dauerhaft eingerichtete Umgebung voraussetzt, dokumentieren Sie den Nachweis am konkreten Label. Halten Sie außerdem fest, wer die Freigabe bei einer Änderung des Images erneut prüft. So bleibt die Release-Abnahme nachvollziehbar, selbst wenn ein Wechsel der Toolchain oder der Runner-Klasse später Anpassungen nötig macht.

SECTION 08Für CI-Plattformverantwortliche: Standard, Matrix und Ausnahmen festlegen

Für eine Teamrichtlinie reicht „arm64 ist Standard“ allein nicht. Sie brauchen eine Zuordnung zwischen Projektversprechen und CI-Abdeckung. Ein Projekt ohne Intel-Support kann einen schlanken arm64-Standard nutzen. Ein Produkt mit mehreren unterstützten Architekturen braucht dagegen eine explizite Matrix oder getrennte, nachvollziehbare Jobs. Eine Intel-Ausnahme sollte einen Eigentümer und einen konkreten Prüfzweck haben, damit sie nicht dauerhaft als ungeprüfter Altbestand bestehen bleibt.

Entscheidungsbedingungen für die Runner-Wahl:

• Wenn Ihr Projekt primär für Apple Silicon gebaut und dort abgenommen wird und die erforderlichen Abhängigkeiten auf arm64 laufen, wählen Sie macos-26 als Ausgangspunkt.
• Wenn Intel-Macs Teil Ihres Lieferziels sind oder Sie eine Intel-spezifische Laufzeitprüfung brauchen, ergänzen Sie macos-26-intel für die betroffenen Builds und Tests.
• Wenn beide Architekturen unterstützt werden müssen, führen Sie getrennte Matrixjobs aus und werten Sie Ergebnisse und Artefakte pro Architektur aus.
• Wenn ein Fehler nur auf einer Architektur auftritt, begrenzen Sie den entsprechenden Runner zunächst auf die Reproduktion und benennen Sie die Abhängigkeit oder Prüfung, die den Sonderfall rechtfertigt.
• Wenn Ihr Job eine dauerhafte Umgebung, Kontrolle über den Host oder einen anderen Betriebsablauf erfordert, vergleichen Sie gehostete Runner mit einem Remote-Mac-Betriebsmodell; wechseln Sie nicht bloß wegen des Labels.

So führen Sie die Entscheidung ein

1. Ziel festhalten: Notieren Sie, welche Plattformen und CPU-Architekturen Ihr Produkt tatsächlich unterstützen soll.
2. Abhängigkeiten inventarisieren: Prüfen Sie native Bibliotheken, Buildskripte, Drittanbieter-Actions und externe Werkzeuge auf Architekturvoraussetzungen.
3. Runner-Label gezielt setzen: Verwenden Sie für den ersten repräsentativen Lauf das Label, das zum vorgesehenen Host passt; dokumentieren Sie Ausnahmen mit ihrem Prüfzweck.
4. Vollständigen Workflow ausführen: Nehmen Sie Installation, Build, relevante Tests und benötigte Release-Schritte auf, nicht nur einen isolierten Compileraufruf.
5. Ergebnisse nach Ebenen bewerten: Halten Sie Hostarchitektur, Build-Ziel, Artefakt und Testabdeckung getrennt fest.
6. Änderung kontrolliert ausrollen: Ändern Sie das Standardlabel erst nach einer überprüften Ausführung und halten Sie einen Rückweg für fehlgeschlagene Jobs fest.
7. Verantwortung zuweisen: Bestimmen Sie, wer Labels, Image-Ankündigungen und Toolchain-Anforderungen erneut prüft, wenn sich Projekt oder Runner-Angebot ändern.

Die Stärke gehosteter Runner liegt darin, dass Ihr Team keinen eigenen CI-Host betreiben muss. Die Kehrseite ist, dass Sie die Umgebung nicht in jeder Hinsicht selbst verwalten und ein Label allein keine dauerhaft eingerichtete Maschine verspricht. Ein Remote Mac bringt seinerseits Aufwand für Zugangskontrolle, Pflege, Geheimnisse und Wiederherstellung mit sich. Berücksichtigen Sie bei externem Zugriff außerdem, welche Quelltexte, Schlüssel und personenbezogenen Testdaten in der Umgebung verarbeitet werden; Datenschutz- und DSGVO-Anforderungen gehören in die Betriebsentscheidung, nicht erst in die spätere Freigabe.

Wenn Sie Ihren Job nach diesen Prüfungen weiterhin auf einem GitHub-hosted Runner ausführen können, bleiben Sie bei dieser Lösung. Wenn der Workflow dagegen regelmäßig eine kontrollierbare, kontinuierlich verfügbare Mac-Umgebung benötigt, lesen Sie zunächst den Überblick zu den Remote-Mac-Möglichkeiten von MACNOX und vergleichen Sie die für Ihr Vorhaben relevanten Mietbedingungen und Preisangaben. Eine Anmietung lohnt sich nicht automatisch für jeden Build: Für einfache, kurzlebige CI-Jobs kann ein gehosteter Runner die wartungsärmere Wahl bleiben. Für einen gezielten Testbetrieb oder einen kontrollierbaren Mac-Knoten können Sie anschließend die MACNOX-Bestelloptionen prüfen und die tatsächliche Eignung vor einer längerfristigen Umstellung mit Ihrem Projektworkflow abgleichen.

SECTION 09FAQ

SECTION 10Weiterlesen

• ARM64-Kompatibilität und Produktionsfreigabe für neue macOS-Build-Runner prüfen
• Runner-Architektur, Netzwerkzugriff und CI-Aufgaben im Unternehmen gezielt abgrenzen