Startseite / Blog / iOS 27 Simulator
ENGINEERING_BLOG · 2026.10.03

iOS 27 Simulator-Runtime-Download fehlgeschlagen? 2026 beheben

Die iOS 27 Simulator-Runtime wird nicht geladen, die Installation bleibt stehen oder Xcode zeigt kein passendes Laufziel?

Schnellste Lösung: Ordnen Sie den Fehler zuerst dem Download, der Installation oder der Erkennung des Laufziels zu. Prüfen Sie dann die Xcode-Komponenten beziehungsweise Apples dokumentierten Kommandozeilenweg; löschen Sie weder Systemverzeichnisse noch installieren Sie Xcode neu, bevor die Ursache eingegrenzt ist.

Für wen dieser Leitfaden gedacht ist: Für unabhängige Entwicklerinnen und Entwickler, deren iOS-Projekt ohne passende Simulator-Runtime nicht startet.
Kleine Teams mit Remote Mac oder CI können damit die dort tatsächlich verwendete Xcode-Version und Runtime prüfen.
Wer Xcode gerade aktualisiert hat und kein Simulatorziel sieht, kann einen fehlenden Runtime-Eintrag von einer falsch ausgewählten Werkzeugkette unterscheiden.

SECTION 01 Fehlerphase vor dem Eingriff bestimmen

Behandeln Sie „Simulator funktioniert nicht“ nicht als eine einzige Fehlerklasse. Ein Download, der noch läuft, erfordert eine andere Reaktion als ein abgeschlossener Download mit abgebrochener Installation. Und wenn die Runtime installiert ist, aber kein Gerät als Ziel auftaucht, ist ein erneuter Download möglicherweise wirkungslos.

Führen Sie die Diagnose in dieser Reihenfolge:

  1. Download: Gibt es in Xcode einen laufenden, fehlgeschlagenen oder abgebrochenen Komponentenauftrag? Wird die iOS-Runtime überhaupt angeboten?
  2. Installation: Ist der Download abgeschlossen, aber die Installation nicht? Welche konkrete Meldung erscheint, und an welcher Stelle tritt sie auf?
  3. Erkennung: Wird die Runtime in der Simulator-Verwaltung angezeigt, aber nicht in der Zielliste des Projekts? Oder fehlt sie bereits in der Runtime-Liste?

Notieren Sie vor Änderungen die exakte Xcode-Version, den aktiven Entwicklerverzeichnispfad und die vollständige Fehlermeldung. Sichern Sie außerdem relevante Terminalausgaben, wenn Sie einen Kommandozeilenversuch unternommen haben. Diese Angaben erlauben Ihnen, einen Komponentenfehler von einer abweichenden Xcode-Auswahl zu trennen.

Prüfen Sie auch, ob Ihr installiertes Xcode die gewünschte Runtime unterstützt. Apple führt die verfügbaren Komponenten und die Anforderungen an Xcode auf den Seiten für zusätzliche Xcode-Komponenten und Xcode-Systemanforderungen auf. Da sich diese Angaben mit Xcode-Versionen ändern können, sollten Sie die aktuelle Apple-Dokumentation und die tatsächlich installierte Xcode-Version abgleichen, statt aus der Versionsnummer allein Kompatibilität abzuleiten.

SECTION 02 Downloadpfad und Auftragsstatus

Beginnen Sie in Xcode in der Komponentenverwaltung. Apple beschreibt dort, wie optionale Komponenten und Simulator-Runtimes verwaltet werden. Prüfen Sie, ob iOS als Plattform angeboten wird, ob die gewünschte Runtime aufgeführt ist und welchen Status Xcode für den Auftrag meldet. Ein Eintrag, der noch lädt, ist kein abgeschlossener Download. Ein fehlgeschlagener Auftrag ist wiederum nicht automatisch ein Beleg dafür, dass die Runtime grundsätzlich nicht verfügbar ist.

Gehen Sie bei einer Unterbrechung zunächst ohne Bereinigung vor:

  1. Erfassen Sie die Meldung und den sichtbaren Status des Auftrags.
  2. Kontrollieren Sie, ob die gewünschte Plattform in der Komponentenverwaltung angezeigt wird.
  3. Prüfen Sie, ob Xcode noch arbeitet oder den Vorgang als fehlgeschlagen beziehungsweise abgebrochen kennzeichnet.
  4. Starten Sie einen neuen Versuch erst, nachdem Sie den vorherigen Status dokumentiert haben.
  5. Bleibt derselbe Fehler bestehen, wechseln Sie nicht unmittelbar zu manuellen Eingriffen in Systemordner. Prüfen Sie stattdessen Xcode-Auswahl und Dokumentation.

Wenn Sie einen Terminalweg brauchen, halten Sie sich an Apples dokumentierte xcodebuild-Optionen zum Herunterladen und Installieren zusätzlicher Plattformkomponenten. Apple dokumentiert die Optionen zum Herunterladen und Exportieren einer Plattform-Runtime sowie zum späteren Import. Die konkrete Syntax und verfügbare Plattform sind an die verwendete Xcode-Version gebunden; gleichen Sie deshalb die Befehlsoptionen mit Apples Anleitung zum Herunterladen und Installieren zusätzlicher Komponenten ab. Ein plausibles Beispiel für die Art der Optionen ist xcodebuild -downloadPlatform iOS; verwenden Sie zusätzliche Argumente wie einen Exportpfad nur entsprechend der aktuellen Dokumentation und der Ausgabe von xcodebuild -help.

Der entscheidende Nachweis ist nicht, dass ein Befehl ohne sichtbare Fehlermeldung gestartet wurde. Notieren Sie den vollständigen Aufruf, das Arbeitsverzeichnis und die Rückmeldung des Prozesses. Ein Export ist noch keine Installation in jeder Xcode-Umgebung. Auch ein erfolgreich heruntergeladenes Paket beweist nicht, dass das gerade ausgewählte Xcode die Runtime bereits als verfügbares Ziel kennt. Beenden Sie den Downloadzweig erst dann, wenn Xcode oder die dokumentierte Kommandozeilenprüfung die Runtime im vorgesehenen Werkzeugkontext erkennen lässt.

SECTION 03 Installation und Xcode-Auswahl getrennt prüfen

Bei einem Installationsfehler sollten Sie nicht reflexartig denselben Download wiederholen. Trennen Sie drei Fragen: Wurde ein Download-Artefakt erzeugt? Ist der Installations- oder Importvorgang abgeschlossen? Und zeigt der Rechner auf die Xcode-Installation, in der Sie die Runtime später verwenden wollen?

Ermitteln Sie zunächst die aktive Kommandozeilen-Werkzeugauswahl mit Apples dokumentierten Einstellungen für Command Line Tools. Der Pfad ist wichtig, wenn mehrere Xcode-Installationen vorhanden sind: Eine Runtime kann in einer Werkzeugumgebung vorhanden sein, während eine andere für xcodebuild oder die Simulatorverwaltung aktiv ist. Verändern Sie die globale Auswahl nicht, bevor Sie den aktuellen Zustand festgehalten haben. Wenn Sie sie ändern müssen, notieren Sie den vorherigen Pfad, damit Sie bei unerwartetem Verhalten zurückwechseln können.

Verwenden Sie für einen Import nur den von Apple vorgesehenen Weg und nur für ein tatsächlich exportiertes, passendes Runtime-Paket. Die Xcode-Kommandozeilenreferenz beschreibt die verfügbaren Werkzeuge und Optionen. Eine Installation, die abbricht, sollte nicht durch manuelles Verschieben oder Löschen von Dateien in Systemverzeichnissen „repariert“ werden: Damit können Sie einen zweiten, schwerer nachvollziehbaren Fehler erzeugen und vorhandene Simulatorumgebungen beeinträchtigen.

Legen Sie vor einem weiteren Versuch einen kleinen Diagnosebestand an: Fehlermeldung, verwendete Xcode-Version, aktiver Entwicklerpfad, verwendeter Download- oder Importbefehl und dessen Ausgabe. Wenn Xcode ausdrücklich einen Komponentenauftrag als fehlgeschlagen meldet, können Sie den dokumentierten Download erneut anstoßen. Wenn dagegen ein Importfehler oder eine abweichende Entwicklerauswahl vorliegt, beheben Sie zuerst genau diesen Punkt. Stoppen Sie die Reparatur, sobald die Runtime in der richtigen Xcode-Umgebung erkannt wird; wiederholte Downloads bringen danach keinen zusätzlichen Beleg.

Cache-Löschungen und das Entfernen installierter Runtimes sind keine neutralen Tests. Sie können vorhandene Simulatorziele oder lokal gespeicherte Testumgebungen beseitigen. Führen Sie solche Schritte nur aus, wenn Apples aktuelle Anweisungen oder eine klar belegte Fehlermeldung sie nahelegen, Sie die betroffene Umgebung identifiziert haben und Sie wissen, wie Sie sie wiederherstellen. Ohne diese Voraussetzungen lautet die sichere Entscheidung: Zustand sichern und nicht löschen.

SECTION 04 Fehlendes Laufziel von Projektfehlern abgrenzen

Wenn die Runtime installiert scheint, Ihr Projekt aber kein passendes Gerät anbietet, prüfen Sie die Erkennung getrennt vom Build. Xcode muss die Plattform-Runtime kennen, das Scheme muss für die passende Plattform vorgesehen sein, und die ausgewählte Entwicklerumgebung muss zu der Xcode-Installation passen, die Sie geöffnet haben.

Vergleichen Sie die sichtbaren Einträge in Xcode mit der dokumentierten Simulatorverwaltung. Apples Anleitung zum Hinzufügen und Verwalten zusätzlicher Simulatoren beschreibt die Simulatorseite der Verwaltung. Die konkrete Darstellung und verfügbare Auswahl hängt von der installierten Xcode-Version ab. Verwechseln Sie dabei nicht die Runtime mit einem konkreten simulierten Gerät: Eine vorhandene Runtime allein bedeutet nicht, dass jedes Modell automatisch als Laufziel angelegt oder verfügbar ist.

Für die Gegenprüfung in der Kommandozeile können Sie die von Apple bereitgestellte Simulatorwerkzeugkette verwenden, zum Beispiel xcrun simctl list runtimes und xcrun simctl list devices available. Führen Sie die Befehle in der Umgebung aus, in der Sie bauen oder testen, und bewahren Sie die Ausgabe auf. Die Apple-Referenz zu Xcode-Kommandozeilenwerkzeugen ist maßgeblich dafür, welche Optionen Ihre installierte Version unterstützt. Stimmen Runtime-Liste, Simulatorliste und Xcode-Zielliste nicht überein, prüfen Sie zuerst den aktiven Entwicklerpfad; ein Projektfehler ist damit noch nicht nachgewiesen.

Danach kontrollieren Sie in Xcode das Scheme und die angebotenen Ziele. Ein Scheme für ein anderes Plattformziel lässt sich nicht durch eine iOS-Runtime in ein iOS-Scheme verwandeln. Wenn die Runtime und ein geeignetes Simulatorziel in Xcode vorhanden sind, aber der Build weiterhin scheitert, untersuchen Sie erst dann Projektkonfiguration, Abhängigkeiten und Compilerfehler. Apple beschreibt den Ablauf zum Starten einer App auf simulierten oder physischen Geräten; die Zielliste ist ein eigener Prüfschritt vor der Bewertung eines App-Builds.

Damit vermeiden Sie einen häufigen Diagnosefehler: Ein leerer oder ungeeigneter Laufzielbereich ist nicht dasselbe wie ein fehlgeschlagener App-Build. Halten Sie fest, an welcher Stelle sich der Zustand ändert: Runtime nicht gelistet, Gerät nicht gelistet, Scheme ungeeignet oder Build mit konkreter Fehlermeldung abgebrochen. Erst diese Unterscheidung bestimmt den nächsten sinnvollen Eingriff.

SECTION 05 Remote Mac und CI als eigene Systeme prüfen

Bei einem Remote Mac reicht es nicht, Xcode auf Ihrem lokalen Rechner zu kontrollieren. Download, Installation und Tests laufen auf dem entfernten Mac, wenn dort der Buildprozess ausgeführt wird. Der lokale Rechner kann eine andere Xcode-Version, einen anderen Entwicklerpfad und eine andere Runtime-Auswahl verwenden. Daher müssen Versions- und Runtime-Nachweise direkt aus der ausführenden Umgebung stammen.

Öffnen Sie auf dem Remote Mac ein Terminal oder die dort vorgesehene Konsole und erfassen Sie xcodebuild -version, xcode-select -p sowie die Ausgabe der Simulatorabfrage. Prüfen Sie anschließend, ob die GUI-Xcode-Installation und die Kommandozeilen-Werkzeugauswahl auf dasselbe erwartete Xcode zeigen. Apple erklärt die Auswahl der Kommandozeilenwerkzeuge in der Dokumentation zu Command Line Tools. Die Versionsausgabe allein weist die installierte Runtime nicht nach; dafür brauchen Sie zusätzlich die Runtime- und Gerätelisten.

Für CI gilt dieselbe Regel, mit einer zusätzlichen Grenze: Entscheidend ist der Runner, der den Test tatsächlich ausführt, nicht die Entwicklungsmaschine, von der Sie den Auftrag gestartet haben. Erfassen Sie die Xcode-Auswahl und Runtime-Liste im Buildprotokoll oder in einem temporären Diagnosejob. Wenn der Runner verwaltet wird und Sie keine Berechtigung zum Installieren von Komponenten oder Ändern des Entwicklerpfads haben, übermitteln Sie die Ausgaben an die zuständige Umgebungsverwaltung. Wiederholte Projektänderungen sind keine passende Reaktion auf eine fehlende System-Runtime.

Ein dauerhaftes CI-System kann zudem einen anderen Zustand aufweisen als ein frisch gestarteter oder neu bereitgestellter Remote Mac. Verlassen Sie sich deshalb nicht auf frühere erfolgreiche Läufe, wenn sich die ausgewählte Xcode-Version oder die Runner-Umgebung geändert hat. Sichern Sie eine funktionierende Runtime-Liste zusammen mit dem Buildprotokoll, damit ein späterer Vergleich erkennen lässt, ob sich die Werkzeugkette oder das Projekt verändert hat.

Wenn Sie eine Remote-Entwicklungsumgebung nutzen, können Sie bei Zugriffs- oder Zuständigkeitsfragen die Hilfe für Remote-Mac-Nutzer heranziehen. Dieser Verweis ersetzt keine Prüfung der tatsächlichen Xcode- und Runtime-Ausgaben auf dem Ausführungsrechner. Er hilft Ihnen nur dabei, den Zuständigen für die Umgebung zu finden, wenn Installation oder Werkzeugauswahl nicht in Ihrer eigenen Verantwortung liegen.

SECTION 06 Abnahme-Checkliste und häufige Fragen

Verwenden Sie die folgende Checkliste erst, nachdem Sie die Fehlerphase bestimmt haben. Sie dient als Abnahmekriterium und nicht als Aufforderung, alle Systemkomponenten pauschal neu zu installieren.

  • [ ] Die genaue Xcode-Version und der aktive Entwicklerpfad sind dokumentiert.
  • [ ] Der Status des Runtime-Auftrags ist in Xcode oder in der dokumentierten Kommandozeilenausgabe eindeutig.
  • [ ] Die iOS-Runtime erscheint in der Runtime-Abfrage der Umgebung, in der der Test ausgeführt wird.
  • [ ] Ein passendes simuliertes Gerät ist in der Simulatorverwaltung und als Xcode-Laufziel sichtbar.
  • [ ] Das aktive Scheme zielt auf iOS und verwendet das erwartete Simulatorziel.
  • [ ] Das Projekt wurde mit diesem Ziel gebaut und gestartet; Fehlermeldungen sind getrennt von Runtime-Installationsmeldungen erfasst.
  • [ ] Bei Remote Mac oder CI stammen die Prüfprotokolle vom tatsächlichen Ausführungsrechner und nicht nur vom lokalen Arbeitsplatz.
  • [ ] Sie haben Systemverzeichnisse und vorhandene Runtimes nicht ohne belegten Grund entfernt.

Nach erfolgreicher Erkennung führen Sie einen echten Projektlauf auf dem gewünschten Simulatorziel aus. Prüfen Sie, ob der Build abgeschlossen wird und die App im Simulator startet. Das bestätigt, dass Werkzeugkette, Runtime, Simulatorziel und Projekt in dieser Teststrecke zusammenarbeiten. Es ersetzt jedoch keinen Test auf einem physischen iPhone: Gerätefunktionen, Verhalten unter realen Hardwarebedingungen und bestimmte Integrationen müssen auf einem echten Gerät geprüft werden. Apple unterscheidet ausdrücklich zwischen simulierten und physischen Geräten in seiner Anleitung zum Ausführen einer App auf Geräten.

Häufige Fragen

Was tun, wenn Xcode 27 den Runtime-Download nicht startet?
Prüfen Sie zuerst, ob die Runtime in der Komponentenverwaltung angeboten wird und ob der Auftrag als aktiv, abgebrochen oder fehlgeschlagen angezeigt wird. Gleichen Sie die installierte Xcode-Version mit Apples aktueller Komponenten- und Systemdokumentation ab. Ein dokumentierter xcodebuild-Download ist eine Alternative, wenn die Komponentenverwaltung den Vorgang nicht ermöglicht. Löschen Sie keine Systemdateien, solange der Fehler nicht auf eine konkrete beschädigte Installation hinweist.

Warum ist nach der Installation kein Simulator als Laufziel verfügbar?
Runtime und Simulatorgerät sind unterschiedliche Bestandteile der Auswahl. Prüfen Sie, ob die Runtime in der Werkzeugumgebung sichtbar ist, ob ein passendes simuliertes Gerät existiert und ob das Scheme auf iOS ausgerichtet ist. Wenn die Runtime auf der Kommandozeile erscheint, in Xcode aber nicht, vergleichen Sie zunächst die Entwicklerpfade und die ausgewählte Xcode-Installation. Eine leere Zielliste belegt für sich genommen keinen Projektfehler.

Wie finden Sie heraus, welche Runtime ein Kommandozeilen-Download bereitgestellt hat?
Bewahren Sie den vollständigen Downloadbefehl und seine Ausgabe auf. Prüfen Sie anschließend die Runtime-Liste mit der Simulatorwerkzeugkette derselben Xcode-Auswahl. Ein Exportpfad oder ein erfolgreicher Downloadstart belegt nicht automatisch, dass der Import abgeschlossen und die Runtime verfügbar ist. Folgen Sie bei Download- und Importoptionen der aktuellen Apple-Dokumentation für Ihre installierte Xcode-Version.

Was ist zu tun, wenn ein Remote Mac eine vorhandene Runtime nicht erkennt?
Führen Sie die Prüfungen auf dem Remote Mac selbst aus: Xcode-Version, Entwicklerpfad, Runtime-Liste und verfügbare Simulatorgeräte. Vergleichen Sie diese Ergebnisse mit der lokalen Maschine, aber behandeln Sie lokale Ausgaben nicht als Beleg für den entfernten Zustand. Wenn Ihnen Installationsrechte fehlen, geben Sie die Protokolle an die zuständige Umgebungsverwaltung weiter, statt auf dem Projekt oder lokalen Rechner nach einem vermeintlichen Runtime-Fehler zu suchen.

Wenn die Fehler nur auf dem Remote Mac auftreten, vergleichen Sie zuerst dessen Xcode-Auswahl und Runtime-Liste mit den Ergebnissen Ihrer lokalen Umgebung. Für gelegentliche Tests kann eine vorhandene lokale Mac-Umgebung genügen; bei einem Team, das wiederholt auf eine zugängliche macOS-Testumgebung angewiesen ist, kann ein gemieteter Mac den Aufwand für einen ausschließlich dafür angeschafften Rechner vermeiden. Das ist nicht automatisch die richtige Wahl, wenn Sie dauerhaft hohe Last, lokale Anschlüsse oder vollständige Kontrolle über physische Hardware benötigen. Wenn ein zeitlich begrenzter Remote-Mac-Zugang zu Ihrem Ablauf passt, können Sie die Mietoptionen von VPSNIX prüfen; klären Sie vorab, welche Xcode- und Runtime-Konfiguration für Ihren konkreten Test erforderlich ist.