GitHub Actions arm64 Runner ohne feste UDID? Was tun für iOS CI 2026

Die GitHub-Dokumentation zu größeren Runnern weist darauf hin, dass macOS-Runner mit arm64 keine statische UUID beziehungsweise UDID bereitstellen. Für Intel-macOS-Runner führt GitHub eine Option mit statischer UDID auf. Das ist eine Aussage über die Kennung des Runner-Macs, nicht über ein iPhone, das Sie zum Testen verwenden. Prüfen Sie die aktuelle Dokumentation zu Runner-Architektur und UDID, bevor Sie Ihre Runner-Auswahl daran ausrichten.

Die entscheidende Frage lautet nicht: „Hat der Runner eine UDID?“ Sie lautet: Welcher konkrete Schritt verlangt welche Kennung? Ein Job kann den Quellcode kompilieren, einen Simulator starten, ein App-Bundle signieren oder eine App auf einem registrierten Gerät installieren. Diese Schritte haben unterschiedliche Voraussetzungen.

Ordnen Sie den Fehler zunächst einer der folgenden Aufgaben zu:

• Kompilieren: Ein Build, der kein Profil für die Installation auf einem registrierten Gerät benötigt, wird nicht allein durch die fehlende statische Mac-UDID verhindert.
• Simulatorprüfung: Simulatorläufe testen eine simulierte Umgebung. Sie sind kein Nachweis, dass ein echtes iPhone verbunden ist oder ein Profil für dieses Gerät vorliegt.
• Entwicklungssignierung: Hier müssen Sie prüfen, welches Provisioning-Profil der Signierschritt verwendet und ob die erforderlichen Geräte darin enthalten sind.
• Test auf einem iPhone: Dafür brauchen Sie das tatsächliche Testgerät, dessen Registrierung und eine Umgebung, die dieses Gerät erreichen kann.
• Veröffentlichung über den App Store: Eine für die Verteilung bestimmte Build-Pipeline ist nicht automatisch von der UDID des Mac-Build-Hosts abhängig. Trennen Sie den Upload-Schritt von der Entwicklungssignierung.

Ein fehlgeschlagener Schritt kann also eine echte Blockade anzeigen, ohne dass die gesamte iOS-CI unbrauchbar ist. Suchen Sie im Build-Protokoll nach der konkreten Fehlermeldung des Signier- oder Installationsschritts. Der Text „UDID fehlt“ reicht als Diagnose nicht aus.

Ja, das ist eine häufige Ursache für falsche Runner-Wechsel. Die Kennung des Mac-Hosts identifiziert den Rechner, auf dem der Job läuft. Die Kennung eines iPhones identifiziert ein Apple-Gerät, das für bestimmte Entwicklungs- oder Ad-Hoc-Abläufe zugelassen wird. Ein Mac-Host wird nicht dadurch zum registrierten iPhone, dass er eine feste UDID besitzt.

Apple beschreibt die Registrierung von Geräten im Entwicklerkonto und die Verwendung registrierter Geräte in entsprechenden Bereitstellungsabläufen. Ein Entwicklungsprofil ist von einem Ad-Hoc-Profil zu unterscheiden. Prüfen Sie deshalb zuerst, welcher Profiltyp tatsächlich für Ihren Build vorgesehen ist.

Daraus ergeben sich drei getrennte Prüfungen:

• Mac-Kennung: Wird sie ausdrücklich von einem Workflow oder einem Signierprozess verlangt? Falls ja, klären Sie, ob es um die statische Kennung des Build-Hosts geht.
• iPhone-UDID: Ist das Gerät, auf dem Sie installieren möchten, im Apple-Entwicklerkonto registriert und vom verwendeten Profil abgedeckt? Apple beschreibt die Registrierung eines einzelnen Geräts.
• Signiermaterial: Passen Zertifikat, Profil und App-ID zusammen, und greift der Workflow auf die vorgesehenen Zugangsdaten zu?

Die Apple-Verwaltung von Provisioning-Profilen ist hilfreich, wenn Sie kontrollieren müssen, welches Profil heruntergeladen oder aktualisiert wurde. Verwechseln Sie dabei nicht die Geräteauswahl im Profil mit dem Host, der den Build erzeugt.

Wenn ein Skript die Mac-Kennung in ein Feld für die Geräte-UDID einträgt, korrigieren Sie das Skript und prüfen Sie das Profil erneut. Wenn der Fehler tatsächlich die statische Host-UDID betrifft, dokumentieren Sie, welcher Schritt diese Anforderung stellt. Erst dann ist ein anderer Runner-Typ eine begründete Maßnahme.

Nicht pauschal. Eine fehlende feste UDID des arm64-Macs bedeutet nicht, dass jede iOS-App nicht signiert werden kann. Relevant ist, ob Ihr Signierpfad ein Geräteprofil benötigt und ob die darin vorausgesetzten Testgeräte korrekt registriert sind. Der Runner-Host und die Geräteauswahl in einem Entwicklungs- oder Ad-Hoc-Profil sind verschiedene Sachverhalte.

Nutzen Sie diese Abgrenzung:

• Für einen Build, der nicht auf einem registrierten Gerät installiert werden soll, prüfen Sie zuerst die verwendete Signierart und das Ziel des Builds.
• Für eine Entwicklungssignierung mit anschließender Geräteinstallation prüfen Sie das Entwicklungsprofil, die registrierte iPhone-UDID und das verwendete Zertifikat.
• Für eine Ad-Hoc-Verteilung prüfen Sie das Ad-Hoc-Profil und die darin vorgesehenen Geräte.
• Für eine App-Store-Veröffentlichung prüfen Sie die Distributionssignierung und den Upload-Ablauf. Die Apple-Anleitung zum Hochladen eines Builds behandelt diesen Veröffentlichungsweg getrennt von einer Installation auf einem registrierten Testgerät.

Ein grüner Build ist daher kein vollständiger Nachweis für eine erfolgreiche Installation oder Veröffentlichung. Halten Sie die Ergebnisse getrennt fest: Kompilierung erfolgreich, Signatur verifiziert, Testinstallation auf dem vorgesehenen iPhone erfolgreich und Veröffentlichungsartefakt angenommen. Ein Fehler in einer Stufe darf nicht als Beleg für einen Fehler in allen anderen Stufen dienen.

Ein GitHub-hosted macOS Runner ist nicht automatisch mit dem iPhone verbunden, das Ihr Team lokal für Tests verwendet. Ein Simulatorlauf auf dem Runner belegt keine Installation auf einem physischen Gerät. Wenn Ihre Pipeline eine echte Geräteprüfung verlangt, brauchen Sie eine eingeplante Testumgebung, in der das Gerät erreichbar ist, und einen Ablauf, der die Verbindung und Installation nachweist.

Prüfen Sie vor der Auswahl der Umgebung:

• Ist ein physisches iPhone für diesen Test zwingend erforderlich, oder reicht zunächst ein Simulatorlauf?
• Ist die UDID dieses Testgeräts registriert und vom verwendeten Profil abgedeckt?
• Kann der Runner das Gerät tatsächlich erreichen, und ist die Geräteverbindung im Workflow dokumentiert?
• Können Sie nach dem Test nachweisen, dass genau das erwartete Artefakt auf dem vorgesehenen Gerät installiert wurde?

Wenn die Pipeline eine Geräteverbindung voraussetzt, die ein gehosteter Runner nicht bereitstellt, müssen Sie die Testinfrastruktur anpassen. Möglich ist ein selbstverwalteter Runner, der für den Zugriff auf die benötigten Geräte eingerichtet ist. GitHub beschreibt die Grundlagen in der Dokumentation zu selbst gehosteten Runnern. Das ist allerdings keine automatische Sicherheitsfreigabe: Ein Runner mit Zugriff auf Signiermaterial und Geräte braucht eine klare Isolation und Kontrolle der Workflows.

Insbesondere bei Pull Requests aus nicht vertrauenswürdigen Quellen darf ein dauerhaft verfügbarer selbstverwalteter Runner nicht unbedacht Zugang zu Produktionsgeheimnissen oder internen Ressourcen erhalten. GitHub weist in den Sicherheitshinweisen zu pull_request_target auf Risiken durch untrusted Code und privilegierte Abläufe hin. Bewerten Sie Workflow-Berechtigungen, Geheimniszugriff und Runner-Wiederverwendung gemeinsam. Ein erreichbarer Mac ist nicht automatisch eine sichere CI-Umgebung.

Gehen Sie die Pipeline in der Reihenfolge durch, in der der Fehler auftritt. So vermeiden Sie, eine Host-Kennungsfrage mit einem Geräteprofil- oder Verbindungsproblem zu beheben.

1. Fehlerstelle eingrenzen. Notieren Sie Job, Schritt und vollständige Fehlermeldung. Unterscheiden Sie Build, Signierung, Simulatorstart, Geräteinstallation und Upload.
2. Angeforderte Kennung bestimmen. Prüfen Sie, ob das Skript eine statische UDID des Mac-Hosts erwartet oder eine UDID eines registrierten iPhones. Kontrollieren Sie Variablen, Signierskripte und Profilzuordnung.
3. Signiermaterial abgleichen. Identifizieren Sie den verwendeten Profiltyp, das Zertifikat und die App-ID. Verifizieren Sie, dass das Profil zum vorgesehenen Installations- oder Veröffentlichungsweg passt.
4. Gerätetest nachweisen. Wenn ein echtes Gerät erforderlich ist, kontrollieren Sie Registrierung, Verbindung und tatsächliche Installation. Ein erfolgreicher Simulatorlauf ersetzt diesen Nachweis nicht.
5. Runner-Anforderung belegen. Falls der Ablauf eine feste Mac-UDID braucht, gleichen Sie die Anforderung mit der aktuellen GitHub-Dokumentation ab. Für arm64-Runner beschreibt GitHub keine statische UDID; die Intel-Option ist auf die dort genannten Runner und Bedingungen begrenzt.
6. Sicherheitsgrenzen prüfen. Dokumentieren Sie, welche Workflows auf den Runner gelangen, welche Geheimnisse verfügbar sind und wie ein Runner nach einem Job bereinigt oder erneut freigegeben wird.
7. Erst danach einen Pilotbetrieb entscheiden. Vergleichen Sie den bestehenden gehosteten Ablauf mit einem dedizierten oder selbstverwalteten Mac anhand derselben Build-, Signier- und Geräteprüfungen.

Arbeiten Sie die folgende Checkliste für jede betroffene Pipeline ab:

• [ ] Der fehlschlagende Schritt und seine konkrete Fehlermeldung sind dokumentiert.
• [ ] Die verlangte Kennung ist eindeutig als Mac-Host-UDID oder iPhone-UDID identifiziert.
• [ ] Der Profiltyp entspricht dem Installations- oder Veröffentlichungsziel.
• [ ] Ein echter Gerätetest weist Registrierung, Verbindung und Installation getrennt nach.
• [ ] Die aktuelle GitHub-Dokumentation bestätigt, dass der gewählte Runner die erforderliche Host-Kennung bereitstellt.
• [ ] Geheimniszugriff und Workflow-Vertrauensgrenzen sind geprüft.
• [ ] Der Vergleich zwischen gehostetem Runner und dediziertem Mac nutzt dieselben Abnahmekriterien.

Behalten Sie einen gehosteten Runner zunächst bei, wenn Ihre Jobs nur kompilieren, Simulatorprüfungen ausführen oder Builds für den vorgesehenen App-Store-Ablauf vorbereiten. Die fehlende statische UDID des arm64-Hosts ist allein kein Grund, diese Aufgaben zu migrieren.

Prüfen Sie eine Alternative gezielt, wenn ein Workflow nachweislich eine feste Mac-Kennung verlangt. GitHub führt eine statische UDID-Option für Intel-macOS-Runner auf; prüfen Sie die aktuelle Dokumentation zu den Bedingungen und der Verfügbarkeit, bevor Sie darauf planen. Diese Option ist keine universelle Lösung für alle Apple-Plattform-Aufgaben und ersetzt weder ein registriertes iPhone noch eine physische Geräteverbindung.

Ein dedizierter oder selbstverwalteter Mac kann sinnvoll sein, wenn Sie eine kontrollierbare Host-Umgebung, Zugriff auf angeschlossene Testgeräte oder einen abgegrenzten Signierablauf benötigen. Dafür übernehmen Sie zusätzliche Verantwortung für Berechtigungen, Wartung, Sicherheitsupdates und die Isolation von Workflows. Entscheiden Sie anhand konkreter Fehlermeldungen und Abnahmen, nicht anhand der Annahme, dass „arm64“ und „UDID“ grundsätzlich unvereinbar seien.

Wenn Sie einen dedizierten Remote-Mac als Testoption prüfen, klären Sie vorab, ob die konkrete Umgebung Ihren Host-Kennungsbedarf erfüllt und ob die erforderliche Geräteverbindung tatsächlich möglich ist. Eine Mietlösung darf nicht als Zusage für eine bestimmte UDID oder angeschlossenes iPhone interpretiert werden, solange dies nicht für die gewählte Konfiguration bestätigt wurde. Bei CALMVPS können Sie die verfügbaren Preis- und Mietoptionen prüfen und anschließend anhand Ihrer Abnahmekriterien bewerten, ob ein Remote-Mac-Pilot für die betroffene Pipeline passt.

Für seltene Tests oder einen zeitlich begrenzten Engpass kann ein gemieteter Mac gegenüber einem dauerhaft vorgehaltenen Rechner die passendere Option sein. Wenn Sie dagegen ausschließlich Simulatorprüfungen und normale Builds ausführen, vermeiden Sie einen Wechsel allein wegen der fehlenden festen UDID. Wenn der Engpass tatsächlich Host-Kennung, Gerätezugriff oder eine kontrollierte Signierumgebung betrifft, vergleichen Sie die laufende Lösung mit einem gezielten Mac-Pilot und bestätigen Sie die Anforderungen vor der Buchung über die CALMVPS-Bestellseite.