Xcode 26.6 iOS Simulator-Download fehlgeschlagen: Remote-Mac-Reparatur 2026

Ein sichtbares iOS SDK beweist nicht, dass die passende iOS-Simulator-Runtime installiert ist. Der Compiler kann deshalb erfolgreich arbeiten, während simctl keine geeignete Runtime meldet. Diese drei Prüfungen liefern die schnellste Eingrenzung:

• Kann das Projekt kompilieren?
• Listet simctl eine iOS-Simulator-Runtime?
• Kann ein vorhandenes Simulatorgerät starten?

Öffnen Sie zunächst das Xcode, das Sie auch grafisch verwenden. Ersetzen Sie den Platzhalter durch den tatsächlichen Pfad:

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

Die Zuordnung von Xcode, Build und Simulator gehört zur normalen Build- und Run-Kette, die Apple in der Dokumentation zum Bauen und Ausführen einer App beschreibt.

Bewerten Sie die Ergebnisse nicht gemeinsam, sondern als Zustandsmatrix:

• Build funktioniert, Runtime fehlt: Das SDK ist vorhanden, die iOS-Simulator-Runtime fehlt wahrscheinlich.
• Runtime erscheint, Gerät startet nicht: Die Runtime ist bekannt, aber CoreSimulator oder der Gerätezustand ist fehlerhaft.
• Runtime erscheint nicht und xcodebuild verweist auf ein anderes Xcode: Zuerst liegt ein Toolchain-Fehler vor.
• Alle lokalen Prüfungen sind korrekt, Download scheitert: Untersuchen Sie Netzwerk, Proxy, DNS und den Apple-Komponentendienst.

Checkliste für die erste Beweissicherung

• [ ] Ausgabe von xcode-select -p gespeichert
• [ ] Ausgabe von xcodebuild -version gespeichert
• [ ] Ausgabe von xcrun simctl list runtimes gespeichert
• [ ] Ausgabe von xcrun simctl list devices gespeichert
• [ ] Exakte Xcode-Version und angeforderte Runtime notiert
• [ ] Fehlerzeit, Fehlercode und betroffene Download-Domain notiert

Löschen Sie zu diesem Zeitpunkt keine Systemverzeichnisse. Ohne diese Ausgangsdaten können Sie später nicht unterscheiden, ob ein Reparaturversuch geholfen oder nur den ursprünglichen Zustand verändert hat.

SDK ist installiert, aber die Simulator-Runtime fehlt – was ist zu tun?

Starten Sie den Download der zusätzlichen Plattformkomponente über die Xcode-Einstellungen oder über den dokumentierten xcodebuild-Weg. Ein erfolgreiches Kompilieren ist kein Grund, die Runtime-Prüfung zu überspringen. Entscheidend ist, dass simctl list runtimes danach einen passenden, verfügbaren Eintrag zeigt.

Auf einem Entwicklungs- oder CI-Knoten können mehrere Xcode-Installationen liegen. Die grafische Anwendung kann Xcode 26.6 öffnen, während xcode-select, xcrun oder der Runner auf ein anderes Developer Directory zeigen. Dann diagnostizieren Sie möglicherweise die falsche Installation.

Prüfen Sie zunächst den aktiven Pfad:

xcode-select -p
xcodebuild -version
xcrun --find simctl

Wenn der Pfad nicht zu Ihrer geöffneten Xcode-Installation gehört, wechseln Sie gezielt:

sudo xcode-select --switch /Applications/<Xcode-26.6.app>/Contents/Developer

Verwenden Sie auf einem gemeinsam genutzten Knoten nicht automatisch einen globalen Wechsel. Prüfen Sie vorher, ob andere CI-Jobs eine andere Xcode-Version benötigen. Besser ist eine explizite Zuordnung im jeweiligen Job oder Runner, sofern Ihre Pipeline das unterstützt.

Starten Sie danach Xcode einmal interaktiv mit dem vorgesehenen Benutzerkonto. Akzeptieren Sie die Lizenz nur, wenn dies im vorgesehenen Wartungsfenster erlaubt ist, und warten Sie, bis die Erstinitialisierung abgeschlossen ist. Wiederholen Sie anschließend alle drei Befehle aus dem ersten Abschnitt.

Warum bleibt Xcode 26.6 bei „Preparing“ stehen?

„Preparing“ beschreibt allein den sichtbaren Zustand der Oberfläche. Der Status beweist weder einen beschädigten Download noch einen allgemein bestätigten Apple-Ausfall. Apple-Developer-Forum-Berichte dokumentieren ähnliche Einzelfälle, sind aber keine Bestätigung einer flächendeckenden Störung; behandeln Sie sie deshalb als Fehlerhinweis aus einem Nutzerbericht, nicht als Diagnose.

Sammeln Sie während eines erneuten Versuchs:

• den Zeitpunkt mit Zeitzone,
• den Namen und Build der angeforderten Runtime,
• den vollständigen Fehlertext,
• die betroffene Domain,
• die Ausgabe des Kommandozeilenversuchs,
• Angaben zu Proxy, DNS und Firewall.

Wenn der Download in einer Umgebung mit restriktiver Namensauflösung oder ausgehendem Datenverkehr scheitert, ist ein lokaler Test auf einer anderen Verbindung aussagekräftiger als wiederholtes Klicken in Xcode.

Gehen Sie vom niedrigsten Risiko zum höchsten. Ein abbrechender Download kann mehrere Ursachen haben:

• Ein Proxy verändert oder blockiert die Verbindung.
• DNS liefert keine brauchbare Auflösung.
• Eine Firewall sperrt den Downloadpfad.
• Eine hosts-Datei überschreibt die Namensauflösung.
• Der Apple-Komponentendienst reagiert vorübergehend nicht.
• Xcode nutzt wegen einer falschen Auswahl ein anderes Developer Directory.

Prüfen Sie zuerst die lokale Umgebung. Vergleichen Sie die Auflösung und den Download mit dem normalen Netzwerkpfad Ihrer Organisation. Verändern Sie keine hosts-Einträge ohne vorherige Sicherung. Dokumentieren Sie jede Änderung und setzen Sie sie nach dem Test zurück, wenn sie nicht benötigt wird.

Nutzen Sie für den Kommandozeilentest die aktuelle Apple-Syntax. Die genaue Plattformbezeichnung und verfügbare Runtime müssen zur Dokumentation und zur installierten Xcode-Version passen:

xcodebuild -downloadPlatform iOS

Bei einem automatisierten Knoten sollten Sie die Ausgabe in eine Wartungsdatei schreiben. So bleibt nachvollziehbar, ob der Fehler vor dem Download, während der Übertragung oder beim Einbinden der Komponente auftritt.

Welche Bedeutung hat ein erneuter Versuch mit Xcode Components?

Die Xcode-Komponentenansicht ist ein offizieller Installationsweg. Wenn sie keinen Fortschritt zeigt, liefert der Kommandozeilenversuch zusätzliche Evidenz. Stimmen beide Wege mit einem Netzwerkfehler überein, wechseln Sie nicht sofort zu einer manuellen Verzeichnis-Kopie. Prüfen Sie erst eine unabhängige Verbindung oder verwenden Sie den offiziellen Export auf einem funktionierenden Mac.

Die Apple-Anleitung zum Hinzufügen zusätzlicher Simulatoren ist dabei die Referenz für den unterstützten Komponentenweg. Einzelne Forumsmeldungen zum Status „Preparing“ dürfen nicht in eine allgemeine Aussage über jede Installation umgedeutet werden.

Eine vorhandene Datei oder ein sichtbarer Eintrag in der Xcode-Oberfläche reicht nicht aus. Die Runtime muss in simctl erscheinen und ein Gerät muss sie tatsächlich verwenden können.

Prüfen Sie den Zustand erneut:

xcrun simctl list runtimes
xcrun simctl list devices

Wenn ein passendes Gerät vorhanden ist, starten Sie es mit seiner UDID:

xcrun simctl boot <DEVICE-UDID>
open -a Simulator

Interpretieren Sie die Fälle so:

• Die Xcode-Oberfläche zeigt eine Komponente, simctl aber keine Runtime: Der Import ist wahrscheinlich nicht abgeschlossen oder Xcode und simctl verwenden unterschiedliche Developer Directories.
• simctl listet die Runtime, der Start schlägt fehl: Prüfen Sie den Gerätestatus und erstellen Sie für die Diagnose ein neues Testgerät über die unterstützte Xcode-Oberfläche.
• Das Gerät startet, aber das Projekt scheitert: Der Fehler liegt wahrscheinlich in Projektkonfiguration, Signing, Abhängigkeiten oder dem Testprozess, nicht beim Runtime-Download.
• Nach einem Neustart verschwinden Einträge erneut: Behandeln Sie den Knoten als nicht vertrauenswürdige Basis und sichern Sie Logs, bevor Sie weiterarbeiten.

Entfernen Sie nicht sofort den gesamten CoreSimulator-Datenbestand. Dabei können Gerätezustände, lokale Testdaten und reproduzierbare Hinweise verloren gehen. Falls eine Bereinigung unvermeidbar ist, erstellen Sie zuerst eine Sicherung, notieren Sie die Wiederherstellungsschritte und führen Sie sie nur mit bestätigter Zustandsursache aus.

Wenn ein Mac die gewünschte Runtime zuverlässig laden kann, ist der offizielle Export- und Importweg für eingeschränkte Netzwerke sinnvoller als das Kopieren eines möglicherweise unvollständigen Runtime-Verzeichnisses.

Auf dem funktionierenden Mac wählen Sie die Plattformkomponente über den unterstützten Xcode- oder xcodebuild-Pfad aus. Verwenden Sie einen eindeutig benannten Exportordner:

xcodebuild -downloadPlatform iOS -exportPath <EXPORT-ORDNER>

Übertragen Sie das erzeugte Paket auf den Zielknoten. Nutzen Sie dafür eine gesicherte Verbindung und prüfen Sie vor dem Import:

• Quelle und Xcode-Version,
• Plattformname,
• Runtime-Build,
• Architekturvariante,
• Dateigröße und Prüfsumme,
• vollständige Übertragung.

Importieren Sie anschließend mit dem von Ihrer Xcode-26.6-Installation unterstützten Parameter:

xcodebuild -importPlatform <EXPORT-PAKET>

Da Apple die Komponenten- und Kommandozeilenparameter aktualisieren kann, vergleichen Sie die lokal angezeigte Hilfe mit der aktuellen Dokumentation zum Herunterladen und Installieren von Xcode-Komponenten. Verwenden Sie keine aus Foren kopierten Parameter, wenn sie nicht zur installierten Version passen.

Nach dem Import führen Sie nicht nur eine Dateiprüfung aus. Prüfen Sie die Runtime mit simctl, booten Sie ein Testgerät und starten Sie anschließend einen minimalen Testlauf. Erst diese Kette zeigt, dass der Import funktional abgeschlossen ist.

Ein Remote-Mac ist erst wieder für CI geeignet, wenn der Zustand auch nach einer getrennten Sitzung und einem Neustart reproduzierbar bleibt. Führen Sie die Abnahme in dieser Reihenfolge aus:

1. Öffnen Sie eine neue SSH-Sitzung und protokollieren Sie die aktive Xcode-Auswahl.
2. Prüfen Sie die Runtime-Liste mit xcrun simctl list runtimes.
3. Erstellen oder starten Sie ein Testgerät mit einer passenden Runtime.
4. Führen Sie einen kleinen Simulator-Test aus.
5. Starten Sie ein repräsentatives Projekt aus Ihrer Pipeline.
6. Trennen Sie SSH, verbinden Sie sich erneut und wiederholen Sie die Runtime-Prüfung.
7. Starten Sie den Remote-Mac neu und wiederholen Sie Geräte- und Projekttest.
8. Bewahren Sie Download-, Import- und Testprotokolle als Knoten-Nachweis auf.

Muss Xcode nach einem fehlgeschlagenen iOS-Simulator-Download neu installiert werden?

Nein, nicht als erster Schritt. Wenn das aktive Xcode korrekt ist, die Erstinitialisierung abgeschlossen wurde und nur die Runtime fehlt, genügt der unterstützte Download oder Import. Wenn simctl die Runtime kennt, ist eine Neuinstallation von Xcode noch weniger plausibel. Erst bei beschädigter Xcode-Basis, widersprüchlichen Developer Directories oder einem nicht reproduzierbaren Zustand nach Sicherung kommt ein Neuaufbau infrage.

Für eine belastbare Entscheidung hilft diese Matrix:

Wenn Sie regelmäßig mehrere Testknoten vorbereiten, dokumentieren Sie Runtime-Build, Xcode-Pfad, Importquelle und Abnahmetest in der Pipeline. Das verhindert, dass ein scheinbar erfolgreicher Download später als nicht reproduzierbare Testumgebung endet.

Für einen neu bereitgestellten Remote-Mac können Sie die Umgebung vor der Aufnahme in CI mit der Xcode-Entwicklungsumgebung für Remote-Arbeit abgleichen. Wenn ein eigener Knoten dauerhaft umgebaut wurde, sollten Sie außerdem die aktuellen Mietoptionen für Remote-Macs gegen den Zeitaufwand für weitere Reparaturversuche stellen. Eine weitere sinnvolle Prüfung ist die Xcode-Umgebung nach der Mac-Miete, bevor Sie Signing und Simulator-Tests in eine Pipeline übernehmen.

Ein bereits mehrfach umgeschaltetes, bereinigtes oder teilweise neu installiertes System hat einen entscheidenden Nachteil: Sie können nicht mehr sicher sagen, welche Komponente den Fehler verursacht. Ein lokaler Mac oder ein bestehender Server bleibt sinnvoll, wenn Sie dauerhaft hohe Last, physische Geräteanschlüsse oder langfristig unveränderte Hardware benötigen.

Für einen kurzfristigen Testknoten, eine isolierte Xcode-Installation oder die Wiederholung von Download, Import und Simulator-Test ist ein gemieteter Remote-Mac dagegen häufig der kontrollierbarere Weg. Ihr aktueller Ansatz hat bei einem beschädigten Knoten drei konkrete Nachteile: wiederholte Runtime-Downloads kosten Zeit und Bandbreite, globale Xcode-Wechsel können andere CI-Jobs stören, und destruktive CoreSimulator-Bereinigung zerstört die Vergleichsbasis. Mit CALMVPS können Sie zunächst einen sauberen Mac als Referenzknoten verwenden, den Ablauf reproduzieren und erst danach entscheiden, ob der alte Knoten repariert oder ersetzt wird.

Die richtige Reihenfolge bleibt dabei unverändert: Beweise sichern, Toolchain ausrichten, Runtime offiziell laden oder importieren, Simulator und echtes Projekt testen, anschließend SSH-Sitzung und Neustart wiederholen. Erst wenn diese Kette auf dem sauberen Knoten funktioniert, gehört die Umgebung in eine produktive CI/CD-Pipeline.