Wie lässt sich die Simulator-Runtime von Xcode 27.2 RC offline installieren? Leitfaden 2026

Laden Sie die Simulator-Runtime von Xcode 27.2 RC auf einem verbundenen Mac mit dem von Apple dokumentierten xcodebuild-Ablauf herunter, übertragen Sie das Paket und importieren Sie es auf dem Ziel-Mac. Setzen Sie es erst ein, wenn das ausgewählte Xcode die Runtime erkennt und ein Testlauf Ihres Projekts erfolgreich ist.

Diese Anleitung richtet sich an CI-Ingenieure mit netzwerkbeschränkten Runnern, an Verantwortliche für Mac-Build-Umgebungen und an Entwickler, die iOS-Simulator-Tests auf einem Remote Mac ausführen. Sie hilft, Download, Übertragung und Abnahme voneinander zu trennen.

Zuletzt geprüft am 29.10.2026 anhand der Xcode-Veröffentlichungsseite, der Release Notes für Xcode 27.2 und der Apple-Dokumentation zum Download und Import zusätzlicher Komponenten. Verfügbarkeit und Kompatibilität der konkreten Runtime müssen Sie auf dem Zielsystem erneut prüfen.

Xcode 27.2 RC Simulator-Runtime offline installieren: zuerst den Engpass bestimmen

Eine Offline-Installation ist sinnvoll, wenn der Ziel-Mac eine passende Runtime benötigt, sie aber nicht direkt herunterladen kann. Sie löst dagegen weder ein falsches Deployment Target noch einen Fehler im Projekt. Wir prüfen daher vor dem Transfer, ob tatsächlich die Runtime fehlt.

Xcode 27.2 RC ist in Apples Veröffentlichungsinformationen als Release Candidate aufgeführt. Daraus folgt nicht automatisch, dass jede gewünschte Simulator-Runtime für diesen Xcode verfügbar oder auf jedem Zielsystem verwendbar ist. Maßgeblich sind die verfügbaren Download-Optionen, die Release Notes und das Ergebnis auf dem Ziel-Mac. Apples Release-Informationen und die Hinweise zu Xcode 27.2 sind dafür der Ausgangspunkt.

Drei Begriffe dürfen dabei nicht vermischt werden: Das SDK stellt Schnittstellen und Build-Werkzeuge für eine Plattform bereit. Die Simulator-Runtime enthält die Umgebung, in der ein simuliertes Betriebssystem läuft. Ein Simulator-Gerät ist ein konkretes Testziel innerhalb dieser Umgebung. Ein vorhandener Runtime-Download beweist also nicht, dass ein passendes Gerät bereitsteht oder das Projekt darin startet. Apples Erläuterungen zum Hinzufügen zusätzlicher Simulatoren und zum Ausführen einer App auf simulierten oder physischen Geräten helfen, diese Ebenen auseinanderzuhalten.

Für unabhängige Entwickler: erst das konkrete Testziel festlegen

Wenn nur ein einzelnes Projekt auf einem Remote Mac getestet werden soll, beginnen Sie nicht mit einem Pakettransfer. Notieren Sie zunächst das benötigte Plattformziel und prüfen Sie, welcher Xcode tatsächlich ausgewählt ist. Ein Mac kann mehrere Xcode-Installationen enthalten; für die Runtime-Erkennung zählt die aktive Auswahl, nicht nur der Name eines Ordners.

Prüfen Sie auf dem Ziel-Mac die Werkzeugkette und die vorhandenen Simulator-Komponenten. xcodebuild -version zeigt die ausgewählte Xcode-Version. xcrun simctl list runtimes listet erkannte Runtimes; xcrun simctl list devices available zeigt verfügbare Simulator-Geräte. Falls die Ausgabe nicht zum erwarteten Xcode passt, kontrollieren Sie zunächst die Auswahl mit xcode-select -p. Die Optionen von xcodebuild sind in Apples Referenz für Xcode-Kommandozeilenwerkzeuge beschrieben.

Hinweis: Verwenden Sie für die Prüfung dieselbe Xcode-Auswahl, mit der später gebaut oder getestet wird. Eine Runtime, die unter einer anderen Installation sichtbar ist, belegt noch nicht, dass der CI-Aufruf sie ebenfalls verwenden kann.

Erst wenn klar ist, dass die Runtime fehlt und die betreffende Plattform im Projekt tatsächlich getestet werden muss, lohnt sich der Offline-Ablauf. Für eine reine Kompilierungsprüfung ohne Simulator kann der zusätzliche Runtime-Transfer unnötig sein. Wenn dagegen UI- oder Integrationstests ein Simulator-Gerät benötigen, ist das bloße Vorhandensein eines passenden SDKs kein Ersatz.

Für CI-Ingenieure: iOS-Simulator-Runtime auf einem verbundenen Mac laden

Apple dokumentiert den Download und Import zusätzlicher Xcode-Komponenten über xcodebuild. Der genaue Plattformname, verfügbare Builds und akzeptierte Optionen können von der installierten Xcode-Version abhängen. Führen Sie deshalb xcodebuild -help mit dem Xcode aus, der den Download erledigen soll, und gleichen Sie die Syntax mit Apples Dokumentation zu zusätzlichen Xcode-Komponenten ab.

Der übliche Ablauf besteht aus diesen Schritten:

1. Download-Mac auswählen. Verwenden Sie einen Mac, auf dem die benötigte Xcode-Version verfügbar ist und der die erforderlichen Apple-Downloads erreichen darf. Prüfen Sie mit xcode-select -p, ob die richtige Installation aktiv ist.
2. Download-Optionen bestätigen. Lesen Sie die lokale Hilfe von xcodebuild und prüfen Sie, ob die gewünschte Plattform und ein passender Build angeboten werden. Verlassen Sie sich nicht auf ein Kommando aus einer Anleitung für eine andere Xcode-Version.
3. Runtime in einen festgelegten Ordner exportieren. Die von Apple dokumentierte Befehlsfamilie verwendet -downloadPlatform; für den Export kann -exportPath eingesetzt werden. Ein Beispiel in Platzhalterform lautet: xcodebuild -downloadPlatform iOS -exportPath <freigegebener-Zielordner>. Ersetzen Sie die Plattform und den Pfad nur nach Prüfung der lokalen Optionen.
4. Abschluss und Paketbestand protokollieren. Notieren Sie Xcode-Version, Download-Quelle, Plattformangabe, Zeitpunkt und Ergebnis. Bewahren Sie die von xcodebuild erzeugten Dateien unverändert auf, bis Import und Tests abgeschlossen sind.
5. Paket kontrolliert übertragen. Nutzen Sie einen von Ihrer Organisation freigegebenen Übertragungsweg. Übertragen Sie nicht einfach einen beliebigen Ordner aus einer Xcode-Installation, wenn Apple für den Ablauf einen exportierten Download vorsieht.

xcodebuild -downloadPlatform sollte nicht als allgemeiner Cache-Export verstanden werden. Der exportierte Download ist ein Übertragungsartefakt für den dokumentierten Importweg. Er ist keine Zusage, dass beliebige Xcode-Versionen dieselbe Runtime nutzen oder dass jedes Paket auf jedem Mac funktioniert. Für die tatsächliche Verfügbarkeit sind die lokale Kommandohilfe und Apples aktuelle Komponenten-Dokumentation entscheidend.

Für netzwerkisolierte Runner: Runtime importieren und nachweisen

Auf einem Runner ohne direkten Zugriff auf die Download-Quelle wählen Sie zuerst das Xcode aus, das den Job ausführen soll. Prüfen Sie anschließend dessen lokale xcodebuild-Hilfe auf die Importoption. Apples dokumentierter Ablauf verwendet -importPlatform; die konkrete Eingabe muss dem exportierten Paket und der für diesen Xcode geltenden Syntax entsprechen. Verwenden Sie keinen Importbefehl, dessen Parameter Sie nicht anhand der lokalen Hilfe oder der Apple-Dokumentation geprüft haben.

Ein typischer Importaufruf hat diese Platzhalterform: xcodebuild -importPlatform <pfad-zum-exportierten-paket>. Nach dem Import zählt nicht die Rückmeldung allein. Prüfen Sie die Runtime erneut mit xcrun simctl list runtimes und kontrollieren Sie mit xcrun simctl list devices available, ob das benötigte Simulator-Ziel verfügbar ist. Die Runtime muss im Zusammenhang mit dem aktiven Xcode erscheinen.

Danach folgt die Projektabnahme. Führen Sie den Build- oder Testbefehl aus, den der CI-Job tatsächlich verwendet. Ein allgemeines xcodebuild-Kommando kann etwa ein anderes Scheme, eine andere Konfiguration oder ein anderes Ziel verwenden als die Pipeline. Ein bestandenes Testziel ist deshalb aussagekräftiger als die bloße Runtime-Auflistung.

Achtung: Eine erfolgreiche Dateiübertragung ist keine Installationsbestätigung. Wenn der Import fehlschlägt oder kein passendes Gerät auftaucht, veröffentlichen Sie den Runner nicht als einsatzbereit. Sichern Sie die relevante Fehlermeldung und prüfen Sie Paketstatus, aktive Xcode-Auswahl und Runtime-Liste getrennt.

Damit ist auch die Frage beantwortet, wie sich eine Installation für macOS CI bestätigen lässt: Die Runtime muss vom vorgesehenen Xcode erkannt werden, das benötigte Simulator-Gerät muss verfügbar sein und der reale Projekt-Test muss mit dem vorgesehenen Build-Aufruf durchlaufen. Erst diese Kombination ist eine belastbare Abnahme.

Für Teams mit mehreren Xcode-Versionen: Kompatibilität pro Kombination prüfen

Eine Runtime ist kein universelles, versionsunabhängiges Verzeichnis, das ohne Prüfung zwischen allen Xcode-Installationen geteilt werden kann. Wenn mehrere Xcode-Versionen auf einem Host oder über mehrere Runner verteilt eingesetzt werden, dokumentieren Sie für jede Kombination, welcher Xcode ausgewählt ist und welche Runtime er erkennt. Ein Dateipfad auf dem Datenträger reicht als Beleg nicht aus.

Apples Systemanforderungen für Xcode sollten Sie für das Hostsystem heranziehen. Prüfen Sie zusätzlich die Release Notes und die verfügbaren Komponenten für genau die Xcode-Version, die im Job verwendet wird. Die Versionsangabe im Paketnamen ersetzt diese Prüfung nicht. Selbst wenn ein Import technisch gelingt, muss das Ziel in der konkreten Toolchain verfügbar sein.

Arbeiten Sie bei abweichenden Ergebnissen in einer festen Reihenfolge:

• Ermitteln Sie, welches Xcode die Shell und der CI-Job verwenden.
• Listen Sie die installierten Runtimes und verfügbaren Simulator-Geräte mit diesem Xcode auf.
• Vergleichen Sie das benötigte Projektziel mit den tatsächlich angebotenen Zielen.
• Prüfen Sie die Release Notes und Systemanforderungen, bevor Sie eine andere Kombination ausprobieren.
• Testen Sie die korrigierte Kombination mit dem Projekt und erfassen Sie den Ausgang.

Wenn die Runtime unter einem Xcode sichtbar ist, aber unter dem Xcode des CI-Aufrufs fehlt, ist das zunächst ein Auswahl- oder Kompatibilitätsproblem. Installieren Sie das Paket nicht wiederholt, ohne diese Abweichung zu klären. Andernfalls entstehen schwer nachvollziehbare Runner-Zustände.

Für Plattformverantwortliche: Verteilung, Berechtigungen und Bereinigung regeln

Ein zentraler Download kann wiederholte Abrufe auf einzelnen Hosts vermeiden. Er ist aber kein automatisch gültiger, versionsübergreifender Cache. Legen Sie fest, wer Pakete herunterladen, prüfen, freigeben und importieren darf. Für produktive Runner sollte der freigegebene Bestand von temporären Downloads und persönlichen Entwicklerordnern getrennt sein.

Behandeln Sie den Transfer als Änderung an der Build-Umgebung. Erfassen Sie mindestens die Herkunft des Pakets, die verwendete Xcode-Version, die Plattform, den Importstatus und das Ergebnis der Projektabnahme. Halten Sie außerdem fest, auf welchen Runnern die Änderung gilt. So können Teams nach einem fehlgeschlagenen Build unterscheiden, ob die Ursache im Projekt, in der Toolchain oder in einer veränderten Runtime liegt.

Zugriffsrechte gehören ebenfalls in den Ablauf. Das Importieren von Komponenten und die Verwaltung einer Xcode-Installation können administrative Berechtigungen erfordern. Vergeben Sie diese nicht pauschal an jeden CI-Prozess. Beschränken Sie Schreibzugriffe auf die vorgesehenen Wartungsschritte und prüfen Sie, ob Protokolle oder Testdaten vertrauliche Informationen enthalten. Richten Sie Aufbewahrung und Löschung nach den internen Datenschutz- und DSGVO-Vorgaben aus.

Räumen Sie temporäre Dateien erst auf, wenn Import und Abnahme abgeschlossen sind und die erforderlichen Protokolle gesichert wurden. Entfernen Sie alte Runtimes nicht allein deshalb, weil eine neue Runtime sichtbar ist: Zuerst muss geklärt sein, ob noch ein anderer Build oder ein älterer Testlauf davon abhängt. Halten Sie diese Bereinigung in derselben Änderungsdokumentation fest.

Abnahmecheckliste für den Runner

Verwenden Sie diese Liste vor der Freigabe eines geänderten CI-Hosts. Jeder Punkt sollte sich auf dem Zielsystem nachvollziehen lassen:

• [ ] Das aktive Xcode entspricht der für den Job vorgesehenen Installation.
• [ ] Die lokale Hilfe von xcodebuild wurde für Download und Import geprüft.
• [ ] Das Paket stammt aus dem dokumentierten Downloadablauf und seine Herkunft ist erfasst.
• [ ] Der Import wurde auf dem Ziel-Mac abgeschlossen.
• [ ] xcrun simctl list runtimes zeigt die erwartete Runtime unter dem ausgewählten Xcode.
• [ ] xcrun simctl list devices available zeigt ein passendes Simulator-Ziel.
• [ ] Das Projekt wurde mit dem tatsächlichen CI-Scheme und dem vorgesehenen Testziel ausgeführt.
• [ ] Ergebnis und gegebenenfalls Fehlerprotokolle sind in der Umgebungsänderung dokumentiert.
• [ ] Temporäre Pakete und nicht mehr benötigte Runtime-Dateien wurden gemäß der internen Richtlinie behandelt.

Fällt ein Prüfschritt aus, grenzen Sie den Fehler ein, bevor Sie den Runner wieder freigeben. Eine fehlende Runtime erfordert einen anderen Eingriff als ein nicht verfügbares Simulator-Gerät; ein Projektfehler wiederum wird durch erneuten Import nicht behoben.

Wenn Sie die Einrichtung für mehrere Hosts dokumentieren, können Sie die passenden DebugMac-Leitfäden zur Mac-Umgebung als ergänzenden Einstieg nutzen. Für ein dauerhaftes Betriebsmodell sollten Sie zusätzlich festhalten, wer Xcode aktualisiert, wer Runtime-Pakete freigibt und wie ein Runner nach einer fehlgeschlagenen Änderung auf einen bekannten Zustand zurückgesetzt wird.

Eine lokale Linux- oder Windows-Umgebung kann für plattformübergreifende Aufgaben sinnvoll sein, führt aber nicht dieselbe macOS-Werkzeugkette und dieselben Simulator-Komponenten aus. Auch ein eigener Mac bindet Budget und Wartungszeit und ist für einen kurzfristigen Testbedarf nicht immer passend. Wenn ein Projekt regelmäßig einen erreichbaren macOS-Runner benötigt, aber kein eigenes Gerät beschafft werden soll, kann ein gemieteter Remote Mac von DebugMac die Wartung der Hardware aus dem Team nehmen. Das ist keine Abkürzung für die beschriebene Versions- und Projektabnahme: Prüfen Sie die Umgebung zuerst anhand Ihrer Toolchain und Tests. Für einen zeitlich begrenzten Bedarf können Sie anschließend die Remote-Mac-Umgebung von DebugMac prüfen. Für dauerhaft hohe Last oder erforderliche physische Schnittstellen kann ein eigener Mac weiterhin die geeignetere Wahl sein.