Die am 15.10.2026 angekündigten GitHub-Actions-Images für Xcode 27 unterstützen die Labels xcode-27 und xcode-27-xlarge und laufen ausschließlich auf Apple-Silicon-Runnern (GitHub-Ankündigung). Das belegt jedoch nicht, dass jeder gewünschte Simulator im konkreten Job vorhanden ist.

Symptom → schnellster Weg: xcodebuild findet kein passendes Simulator-Ziel? Prüfen Sie zuerst das tatsächlich verwendete Runner-Image und die aktive Xcode-Toolchain. Vergleichen Sie danach Runtime, Geräteliste und Scheme-Destination. Installieren Sie nicht auf Verdacht Xcode neu und ändern Sie zunächst keine Projektkonfiguration.

Dieser Leitfaden ist für Sie, wenn Sie gerade einen GitHub-Actions-Workflow mit Xcode 27 eingerichtet haben und iOS-Simulator-Tests ausführen.
Er hilft Ihnen, Destination-Fehler von Problemen beim Simulatorstart oder beim Testlauf zu trennen.
Als CI- oder DevOps-Verantwortlicher können Sie danach entscheiden, ob ein kontrollierter Mac-Testlauf nötig ist.

Zuletzt aktualisiert am 17.10.2026. Abgeglichen mit der GitHub-Ankündigung zum Xcode-27-Runner, dem aktuellen Image-README und der Apple-Dokumentation zu Xcode-Komponenten. Runner-Inhalte können sich ändern.

Den tatsächlichen Runner statt nur das Workflow-Label prüfen

Ein häufiger Diagnosefehler: Sie lesen runs-on in der Workflow-Datei, nehmen das erwartete Image an und suchen anschließend nach einem Xcode- oder Simulatorfehler. Das Label ist wichtig, beweist aber allein nicht, welches Image den konkreten Job ausgeführt hat. Die verfügbaren Runner-Labels und Images sind in der GitHub-Referenz zu gehosteten Runnern beschrieben. Für den Inhalt des Xcode-27-Images ist das zugehörige Image-README die passende Prüfstelle.

Öffnen Sie den fehlgeschlagenen Job und notieren Sie die Runner-Informationen aus dessen Ausführung. Sichern Sie außerdem den Schritt, in dem der Fehler auftritt: Scheitert bereits der Aufruf von xcodebuild, wird der Build abgebrochen oder startet der Test erst gar nicht? Diese Unterscheidung verhindert, dass Sie einen späteren Testfehler als fehlendes Gerät behandeln.

GitHub beschreibt, wie Sie die Details eines konkreten Laufs über die Workflow-Run-Logs aufrufen. Nutzen Sie diese Logs, statt aus einer älteren erfolgreichen Ausführung oder allein aus der YAML-Datei auf die aktuelle Umgebung zu schließen. Die aktuelle Image-Dokumentation ist eine Momentaufnahme. Sie ist keine dauerhafte Zusage, dass jede Runtime oder Gerätekombination unverändert bleibt.

Fallbeispiel: Ein Team ändert sein Workflow-Label und sieht danach „No devices available“ in der Destination-Ausgabe. Der erste sinnvolle Schritt ist nicht, den Simulatornamen im Projekt zu ändern. Das Team prüft den Log des fehlgeschlagenen Jobs, bestätigt das Image und führt die Diagnoseschritte im selben Job erneut aus. So lässt sich feststellen, ob das Problem im Runner-Inhalt oder in der angeforderten Zielkonfiguration liegt.

Die aktive Xcode-Toolchain mit dem Image abgleichen

Ein Runner kann mehr als eine Xcode-Installation enthalten. Der Pfad, den der Job tatsächlich verwendet, ist deshalb wichtiger als die Annahme, die aus dem Runner-Label folgt. Apple beschreibt die Auswahl der Kommandozeilenwerkzeuge in der Dokumentation zu den Xcode-Command-Line-Tools.

Führen Sie die Prüfungen im fehlgeschlagenen Job aus, nicht nur lokal auf Ihrer Entwicklungsmaschine:

xcode-select -p
xcodebuild -version
xcrun simctl list devices available
xcrun simctl list runtimes

xcode-select -p zeigt das aktive Entwicklerverzeichnis. xcodebuild -version ergänzt die tatsächlich aufgerufene Xcode-Version. Die beiden simctl-Aufrufe liefern den Geräte- und Runtime-Bestand, den diese aktive Xcode-Installation meldet.

Vergleichen Sie diese Ausgaben mit dem Job-Log und dem README des Xcode-27-Images. Damit können Sie drei Ursachen auseinanderhalten:

  • Das Job-Image ist nicht das erwartete Image.
  • Das aktive Entwicklerverzeichnis verweist auf eine andere Xcode-Installation.
  • Die aktive Xcode-Version ist korrekt, enthält aber nicht die Runtime oder Zielplattform, die der Testlauf voraussetzt.

Die passende Korrektur hängt von diesem Befund ab. Wenn nur das aktive Entwicklerverzeichnis falsch ist, prüfen Sie die Xcode-Auswahl im Workflow anhand der Apple-Anleitung zur Konfiguration der Command-Line-Tools. Wenn Runtime oder Plattformkomponente fehlt, ändern Sie nicht vorschnell die Scheme-Einstellungen: Zuerst muss klar sein, ob die fehlende Komponente in diesem Runner überhaupt vorgesehen ist.

Scheme und xcodebuild-Destination gemeinsam untersuchen

Ein Destination-Fehler entsteht nicht zwingend dadurch, dass kein Simulator installiert ist. xcodebuild kann auch dann kein passendes Ziel finden, wenn Scheme, Test-Target oder Plattform nicht zu den angeforderten Filtern passen. Umgekehrt kann die Geräteliste Simulatoren enthalten, die nicht mit der konkreten Destination-Anforderung übereinstimmen.

Ermitteln Sie zunächst, welches Scheme und welches Test-Target der Workflow tatsächlich aufruft. Prüfen Sie anschließend die Destination-Parameter: Sie müssen zur Plattform, zum angeforderten Betriebssystem und zum Gerät passen, das der Runner anbietet. Achten Sie auf abweichende Gerätenamen, zu enge Versionsfilter und Testziele, die für eine andere Plattform eingerichtet sind.

Lassen Sie sich die vom aktiven Xcode angebotenen Ziele für das betroffene Scheme ausgeben:

xcodebuild -showdestinations -scheme "IhrScheme" -project "IhrProjekt.xcodeproj"

Bei einem Workspace verwenden Sie statt -project den im Workflow verwendeten Workspace-Parameter. Übernehmen Sie Scheme- und Projekt- beziehungsweise Workspace-Namen aus dem tatsächlichen Build-Aufruf. Ein lokal funktionierender Befehl ist kein Beleg dafür, dass der CI-Lauf dieselben Parameter oder dieselbe Projektstruktur verwendet.

Ordnen Sie die Ausgabe anschließend einer dieser Situationen zu:

  • Keine passende Destination vorhanden: Prüfen Sie Runtime, Plattform und Filter.
  • Geräte vorhanden, aber falsches Ziel ausgewählt: Vergleichen Sie die konkreten Namen und Bedingungen mit dem Workflow.
  • Destination vorhanden, Fehler erst danach: Die Auswahl hat funktioniert. Untersuchen Sie nun den Start oder den Testlauf, nicht mehr die Zielauflösung.

Diese Trennung ist entscheidend. Eine Meldung, dass xcodebuild kein passendes Ziel findet, ist ein anderes Problem als ein Simulator, der zwar ausgewählt wird, aber nicht startet. Apple erläutert die Rolle automatisierter Xcode-Tests in der Dokumentation zu Tests mit Xcode.

Simulator Runtime und Geräteangebot getrennt nachweisen

Prüfen Sie zuerst die Ausgabe von xcrun simctl list runtimes. Sie zeigt, welche Simulator-Runtimes die aktive Xcode-Installation meldet. Vergleichen Sie diese Liste mit der im Workflow angeforderten iOS-Version. Eine Runtime, die im aktuellen Image-README aufgeführt ist, beweist nicht automatisch, dass Ihr konkreter Job exakt dieses Image verwendet. Umgekehrt kann sich die README-Angabe mit einer Image-Aktualisierung ändern.

Danach prüfen Sie xcrun simctl list devices available. Damit sehen Sie, welche Geräte der aktiven Toolchain als verfügbar gemeldet werden. Gleichen Sie Gerätenamen, Betriebssystemversion und gegebenenfalls die im Workflow übergebene UDID mit der Ausgabe ab. Raten Sie nicht anhand einer lokal installierten Simulatorliste, welche Geräte der Runner bereitstellt.

Wenn eine Runtime fehlt, entscheidet zuerst der Ausführungskontext über den nächsten Schritt. Apple beschreibt den offiziellen Weg zum Herunterladen und Installieren zusätzlicher Xcode-Komponenten. Prüfen Sie anhand dieser Anleitung, ob die benötigte Komponente für die aktive Xcode-Version verfügbar ist. Ein Installationsschritt in einem verwalteten Runner ist aber nicht automatisch die beste Reparatur: Er kann zusätzliche Einrichtung erfordern und macht einen kurzlebigen Job nicht von selbst reproduzierbar. Wenn Sie diesen Weg testen, protokollieren Sie Installation und anschließende Runtime-Liste im selben Lauf.

Fehlt nur ein bestimmter Gerätetyp, obwohl die Runtime vorhanden ist, untersuchen Sie die Geräteausgabe und die Destination-Filter erneut. Ist ein Gerät vorhanden, scheitert aber beim Start, sichern Sie Start- und Testprotokolle. Ändern Sie nicht gleichzeitig Runtime, Gerätetyp und Scheme: Sonst bleibt unklar, welche Änderung das Ergebnis beeinflusst hat.

Fehlerklasse vor der nächsten Änderung festlegen

Bevor Sie den Workflow anpassen, ordnen Sie den Befund einer Fehlerklasse zu. Die folgende Tabelle dient als Diagnosehilfe; sie behauptet nicht, welche Geräte oder Runtimes in einem konkreten, veränderlichen Runner-Image vorinstalliert sind.

Beobachtung im Job Wahrscheinliche Prüfrichtung Nächster Nachweis
Erwartetes Runner-Image lässt sich im Log nicht bestätigen Tatsächlich verwendeter Runner oder Image-Auswahl Runner-Informationen und Job-Log sichern
xcode-select -p und erwarteter Entwicklerpfad weichen ab Aktive Toolchain oder Xcode-Auswahl Pfad und xcodebuild -version im selben Job dokumentieren
Runtime fehlt in simctl list runtimes Runtime nicht installiert oder falsche aktive Xcode-Installation Ausgabe mit Image-README und Xcode-Auswahl abgleichen
Runtime ist vorhanden, aber Destination fehlt Scheme, Plattform oder Destination-Filter xcodebuild -showdestinations für den Workflow-Aufruf ausführen
Destination wird angeboten, Simulator startet aber nicht Start- oder Laufzeitfehler statt Auswahlfehler Startprotokoll und Testergebnisse sichern

Führen Sie die Eingrenzung mit dieser Checkliste im fehlgeschlagenen Workflow aus:

  • [ ] Job-Log des fehlgeschlagenen Laufs öffnen und tatsächliches Runner-Image notieren.
  • [ ] Den Fehler dem Schritt zuordnen: Build, Destination-Auflösung, Simulatorstart oder Testausführung.
  • [ ] xcode-select -p und xcodebuild -version sichern.
  • [ ] xcrun simctl list runtimes und xcrun simctl list devices available im selben Job protokollieren.
  • [ ] Scheme, Test-Target und Destination-Filter mit dem konkreten xcodebuild-Aufruf vergleichen.
  • [ ] xcodebuild -showdestinations für genau dieses Scheme ausführen und die Ausgabe speichern.
  • [ ] Nach einer Änderung denselben Commit und dieselben Testparameter erneut ausführen und Build, Simulatorstart sowie Testergebnis getrennt bewerten.

Ändern Sie pro Diagnoseversuch möglichst nur eine Ursache. Wenn Sie beispielsweise zugleich das Scheme, die Destination und die Xcode-Auswahl anpassen, kann ein erfolgreicher Lauf nicht zeigen, welche Änderung nötig war. Bewahren Sie den Log und die Testresultate vor und nach der Korrektur auf. Das schafft eine belastbare Grundlage für spätere Image-Änderungen.

Die Reparatur mit einem kontrollierten Wiederholungslauf bewerten

Ein einzelner grüner Lauf reicht nicht aus, wenn das Team nicht weiß, welche Umgebung ihn erzeugt hat. Wiederholen Sie den Job mit demselben Commit, demselben Scheme und derselben Destination. Halten Sie dabei das bestätigte Runner-Image und die Ausgaben der Diagnoseschritte fest. Prüfen Sie getrennt, ob der Build durchläuft, ob das ausgewählte Gerät startet und ob die Tests tatsächlich ausgeführt und beendet werden.

Die zwei folgenden Tabellen helfen dabei, den Fehlerbericht vollständig zu halten und die passende Folgeentscheidung zu treffen. Sie ersetzen weder den Job-Log noch die Prüfung der konkreten Umgebung.

Zu sichernder Befund Warum er für die Reproduktion zählt
Runner-Informationen und Image-README zum Prüfzeitpunkt Zeigt, auf welcher verwalteten Umgebung die Diagnose beruht
Aktiver Xcode-Pfad und Versionsausgabe Unterscheidet falsche Toolchain von fehlender Komponente
Runtime- und Geräteliste aus simctl Belegt das tatsächliche Angebot der aktiven Installation
Scheme, Test-Target und vollständiger Destination-Aufruf Macht die Zielanforderung des Workflows nachvollziehbar
Build-Log, Startmeldung und Testergebnis Trennt Kompilierung, Geräteauswahl und Testausführung
Ergebnis der Prüfung Konsequenz
Runner, Toolchain und Runtime passen; Destination-Filter sind falsch Filter oder Scheme gezielt korrigieren und erneut prüfen
Aktive Xcode-Installation ist falsch ausgewählt Toolchain-Auswahl im Workflow korrigieren
Benötigte Runtime lässt sich im Runner regelkonform bereitstellen Installation als Teil des Jobs testen und ihren Zustand protokollieren
Gewünschter Runtime- oder Host-Zustand ist im verwalteten Runner nicht verlässlich herstellbar Test auf einer kontrollierbaren Mac-Umgebung reproduzieren
Simulator-Tests laufen, aber reale Geräte müssen abgenommen werden Simulator-Ergebnis nicht als Ersatz für einen Gerätetest werten

Simulator-Tests prüfen nicht jede Eigenschaft eines echten iPhone oder iPad. Wenn Ihre Freigabe reale Geräte, Hardwareverhalten oder gerätespezifische Integration umfasst, muss dafür eine eigene Geräteabnahme vorgesehen werden. Ein erfolgreicher Simulatorlauf belegt nur, dass der geprüfte Test unter der dokumentierten Simulatorumgebung bestanden wurde.

Häufige Fragen

Warum findet der Xcode-27-Runner kein iOS-Simulator-Gerät?

Ein passendes Gerät kann fehlen, wenn der konkrete Job ein anderes Image nutzt als angenommen, die aktive Xcode-Installation abweicht oder Runtime und Destination nicht zusammenpassen. Prüfen Sie zuerst den Job-Log und die Ausgaben von simctl und xcodebuild. Ein Simulator, der nach erfolgreicher Auswahl nicht startet, gehört dagegen in eine andere Fehlerklasse.

Wie prüfen Sie die installierte Runtime auf einem xcode-27-Runner?

Führen Sie xcrun simctl list runtimes im betroffenen Job aus und vergleichen Sie die Ausgabe mit der angeforderten Betriebssystemversion. Erfassen Sie zusätzlich xcode-select -p und xcodebuild -version, damit die Runtime-Liste eindeutig zur aktiven Xcode-Installation gehört. Gleichen Sie die Ergebnisse mit dem aktuellen Image-README ab; dessen Inhalt kann sich ändern.

Was kommt zuerst, wenn xcodebuild keine passende Destination meldet?

Prüfen Sie Scheme, Test-Target, Plattform und die Destination-Bedingungen, bevor Sie Xcode neu installieren oder Projektdateien ändern. xcodebuild -showdestinations zeigt, welche Ziele für das betreffende Scheme angeboten werden. Vergleichen Sie die Ausgabe mit dem tatsächlichen Workflow-Aufruf und der Geräteliste aus demselben Runner-Lauf.

Wann sollten Sie den Test auf einen Remote-Mac verlagern?

Erst wenn dokumentierte Wiederholungsläufe zeigen, dass das benötigte Runtime- oder Host-Setup im verwalteten Runner fehlt oder sich dort nicht verlässlich bereitstellen lässt. Ein Remote-Mac kann für eine kontrollierte macOS-Umgebung sinnvoll sein. Bewerten Sie trotzdem getrennt, ob der Test einen Simulator oder eine reale Geräteabnahme benötigt.

Eine kontrollierte Mac-Umgebung als gezielte Ausweichroute prüfen

GitHub-gehostete Runner bieten eine verwaltete, von GitHub aktualisierte Umgebung. Das vereinfacht den Einstieg, begrenzt aber Ihre Kontrolle über den genauen Image-Zustand und die dauerhaft verfügbare Toolchain. Wenn ein Job die benötigte Runtime erst einrichten muss, müssen Sie diesen Schritt zudem in den Ablauf aufnehmen und für den jeweiligen Lauf nachvollziehbar halten. Die Auswirkungen hängen von Ihrem Workflow ab; pauschale Aussagen zu Kosten oder Laufzeit wären ohne Messung nicht belastbar.

Ein Remote-Mac ist deshalb nicht automatisch die bessere Wahl für jede CI-Aufgabe. Wenn Sie eine kontrollierbare macOS-Umgebung für wiederholte Tests benötigen, können Sie eine solche Ausführung gezielt prüfen und die Umgebung mit vollständigen Logs abnehmen. Bei dauerhaft hoher Auslastung, Bedarf an physischen Schnittstellen oder einer langfristig unveränderten Infrastruktur kann ein eigener Mac passender sein. Für einen begrenzten Test oder eine temporäre Reproduktion kann Miete flexibler sein als ein sofortiger Hardwarekauf.

Wenn Sie nach dem Runner-, Toolchain- und Runtime-Abgleich einen unabhängigen Mac-Testlauf erwägen, finden Sie einen Überblick zu MACCOME auf der deutschen Serviceseite. Für eine Bewertung der verfügbaren Mac-Mietoptionen können Sie außerdem die Mac-mini-Angebote ansehen. Vergleichen Sie dabei Ihre tatsächlichen Anforderungen an Zugriff, Laufzeit und Wartung; setzen Sie Simulator-Tests auch auf einem Remote-Mac nicht mit einer Prüfung auf echten Apple-Geräten gleich.