Muss iOS 27 CI noch den Simulator installieren? Entscheidungsstand 2026

Eine iOS-27-CI-Pipeline scheitert nicht automatisch, nur weil auf dem Buildknoten kein Simulator installiert ist. Die schnellste Entscheidung lautet: Simulator nicht pauschal entfernen. Xcode 27 kann unterstützte UIKit-Interface-Builder-Dokumente im Toolchain-Modus ohne heruntergeladene Simulator-Runtime kompilieren. Für App-Host-Tests, UI-Tests und Laufzeitprüfungen bleibt jedoch ein vollständiger Simulator- oder Gerätepfad erforderlich.

Zu diesem Beitrag gehören Buildingenieure, die statische Prüfungen, Kompilierung und Artefakte ohne unnötige macOS-Abhängigkeiten ausführen möchten.
Ebenso angesprochen sind Testteams sowie DevOps- und Plattformverantwortliche, die Remote-Mac-Knoten, Caches und Wiederherstellung neu aufteilen müssen.

Stand der Prüfung: Zuletzt aktualisiert am 08.09.2026. Die technischen Aussagen wurden gegen die Xcode-27-Beta-6-Veröffentlichungshinweise, die Apple-Dokumentation zu Build-Einstellungen und XCTest sowie den aktuellen App-Store-Connect-Status abgeglichen. Xcode 27 und iOS 27 bleiben in diesem Stand Beta-Technologien.

[ SECTION_01 ] Die Entscheidung beginnt mit vier getrennten Abhängigkeiten

In der Praxis werden fünf Dinge häufig in einen Topf geworfen: SDK, Simulator-Runtime, simuliertes Gerät, Interface-Builder-Kompilierung und Test-Destination. Für die CI-Planung sind sie jedoch verschiedene Ebenen.

Das SDK liefert Header, Frameworks und Bibliotheken für die Kompilierung. Eine Simulator-Runtime stellt dagegen ein ausführbares iOS-System bereit. Ein simuliertes Gerät ist die konfigurierte Instanz, auf der eine App gestartet wird. Die Interface-Builder-Toolchain verarbeitet Storyboards und XIB-Dateien. Eine Test-Destination bestimmt schließlich, wo Xcode den Testprozess ausführt.

Für Xcode 27 ist die entscheidende bestätigte Änderung der Kompilierungspfad für UIKit-Interface-Builder-Dokumente. Apple beschreibt in den Xcode-27-Veröffentlichungshinweisen, dass diese Dokumente standardmäßig im Toolchain-Modus kompiliert werden können, ohne eine Simulator-Runtime herunterzuladen. Das ist eine Aussage über die Ressourcenkompilierung. Es ist keine Aussage darüber, dass jede iOS-CI-Aufgabe ohne Runtime auskommt.

Zusätzlich läuft Xcode 27 laut der offiziellen Tabelle zu den Xcode-Systemanforderungen ausschließlich auf Apple-Silicon-Macs. Ein Linux-Cloudserver oder ein gewöhnlicher Intel-Knoten ersetzt den benötigten macOS- und Xcode-Unterbau daher nicht.

[ SECTION_02 ] Buildingenieure sollten Compile-Time und Run-Time getrennt messen

Der erste Fehler ist eine globale Pipeline-Regel wie „Simulator immer installieren“ oder „Simulator vollständig löschen“. Beide Regeln ignorieren die konkrete Aufgabe.

Ein reiner Build kann typischerweise folgende Arbeit enthalten:

• Quellcode kompilieren.
• Swift- und Objective-C-Abhängigkeiten auflösen.
• Storyboards und XIB-Dateien in Ressourcen umwandeln.
• Statische Analyse und Linting ausführen.
• Ein Archiv oder ein für Tests vorbereitetes Produkt erzeugen.
• Build-Artefakte für einen späteren Testknoten bereitstellen.

Diese Schritte beweisen noch nicht, dass eine Anwendung gestartet wurde. Sobald xcodebuild eine Test-Destination auflösen, einen App-Host starten oder iOS-Systemverhalten beobachten muss, wechselt die Pipeline in die Laufzeit-Ebene. Apple beschreibt die verfügbaren Optionen und Ausführungswege in der Referenz für Xcode-Befehlszeilentools.

Ein Build-Log sollte deshalb nicht nur mit „BUILD SUCCEEDED“ enden. Es sollte zusätzlich beantworten:

1. Wurde eine Simulator-Destination angefordert?
2. Wurde eine Runtime oder ein simuliertes Gerät aufgelöst?
3. Wurde die Anwendung gestartet?
4. Wurde ein Test- oder Ergebnisbundle erzeugt?
5. Wurden Interface-Builder-Ressourcen ohne Rückfall auf den Simulator-Modus kompiliert?

Der entscheidende Nachweis ist die Wiederholung mit demselben Commit. Ein Lauf ohne Runtime kann erfolgreich sein, während ein späteres Testszenario eine fehlende Destination meldet. Umgekehrt kann ein vollständiger Knoten einen Build kaschieren, der unbemerkt auf Simulator-Komponenten zugreift.

[ SECTION_03 ] Storyboards, XIB-Dateien und der neue Toolchain-Modus

Teams mit Interface Builder sollten den neuen Modus nicht als automatische Projektmigration behandeln. Die Xcode-27-Voreinstellung betrifft den vorgesehenen Kompilierungspfad. Ein älteres Projekt kann jedoch eigene Build Settings, Skripte oder direkte ibtool-Aufrufe enthalten.

Die Prüfung erfolgt in vier Schritten:

1. Die effektiven Build Settings für jedes relevante Target ausgeben.
2. Den Wert von IBC_COCOATOUCH_COMPILER_MODE kontrollieren.
3. Den Build mit aktivierter und deaktivierter Simulator-Runtime wiederholen.
4. Die erzeugten Storyboard- und XIB-Ressourcen sowie Warnungen und Fehler vergleichen.

Die Apple-Referenz für Build Settings ist dabei wichtiger als eine pauschale Einstellung im Projekteditor. Maßgeblich ist der Wert, der in der tatsächlich verwendeten Konfiguration ankommt. Debug-, Release- und CI-Konfiguration können voneinander abweichen.

Ein erfolgreicher Build genügt außerdem nicht als Migrationsnachweis. Interface-Builder-Ressourcen können erst beim Start der App oder in einem UI-Test auffällig werden. Deshalb sollte der Vergleich mindestens einen App-Start, einen Test mit App-Host und einen relevanten UI-Fluss enthalten.

Wenn ein Projekt auf den Simulator-Modus zurückfallen muss, gehört die Ursache in eine dokumentierte Liste. Beispiele sind ein projektspezifischer Build-Schritt, eine nicht unterstützte Ressource oder ein Fehler in der Beta-Version. Zusätzlich werden das betroffene Target und der Rückweg zur Toolchain-Konfiguration notiert. Ohne diese Angaben bleibt die Pipeline zwar grün, ist aber bei der nächsten Xcode-Aktualisierung schwer nachvollziehbar.

Erfahrungsregel: Ein Build ohne Simulator ist erst dann für einen leichten Knoten geeignet, wenn die Pipeline ihren Runtime-Bedarf sichtbar protokolliert. Das Entfernen einer Runtime aus dem Image ist kein Ersatz für diese Prüfung.

[ SECTION_04 ] Unit-Tests werden nach ihrem Host und nicht nach ihrem Namen sortiert

„Unit Test“ beschreibt in vielen Projekten nicht dieselbe technische Last. Ein reiner Swift-Test für Parser, Datenmodelle oder Berechnungen kann ohne gestartete iOS-Anwendung auskommen. Ein Testtarget mit Test Host arbeitet dagegen möglicherweise innerhalb des App-Prozesses. Ein Integrationstest kann auf Verhalten von Foundation-, UIKit- oder anderen iOS-Systemdiensten angewiesen sein.

Die Einteilung sollte daher nach diesen Fragen erfolgen:

• Ist Test Host gesetzt?
• Wird ein Anwendungsexecutable gestartet?
• Welche SDK- und Destination-Werte verwendet der Test?
• Entsteht ein Testbundle, das später auf einem anderen Knoten ausgeführt werden kann?
• Prüft der Test nur Swift-Logik oder ein Verhalten der iOS-Plattform?

Apple empfiehlt für Testausführung und Ergebnisanalyse die Prüfung der konkreten Destination und des erzeugten Ergebnisbundles. Die entsprechenden Hinweise stehen in der Dokumentation zu Tests und Testergebnissen.

Für einen leichten Buildknoten kommen vor allem Tests infrage, die keine App starten und keine iOS-Runtime benötigen. Das muss nicht bedeuten, dass sie dauerhaft aus dem vollständigen Testlauf entfernt werden. Ein Team kann dieselben Logiktests früh und schnell auf dem Buildknoten ausführen und die plattformnahen Tests später auf dem Testknoten wiederholen.

[ SECTION_05 ] UI-Automatisierung bleibt an einen vollständigen Testknoten gebunden

XCTest-UI-Tests prüfen nicht nur kompilierte Dateien. Sie starten die zu testende Anwendung, finden UI-Elemente und führen Interaktionen aus. Dafür braucht der Lauf eine Test-Destination mit Runtime und simuliertem Gerät oder ein physisches Gerät.

Der neue Interface-Builder-Modus ersetzt diese Laufzeit nicht. Er kann den Weg zur kompilierten Ressource verändern, aber keine App ausführen. Die Pipeline muss daher zwischen „für Tests bauen“ und „Tests ausführen“ unterscheiden.

Für die Abnahme werden Test Plan, Zielgerät und Ergebnisbundle gemeinsam betrachtet. Apple beschreibt in der Anleitung zur Organisation von Tests mit Test Plans, wie Tests nach Konfigurationen und Zielumgebungen strukturiert werden können. Das hilft bei der Trennung von schnellen Logiktests, App-Host-Tests und UI-Szenarien.

Bei parallelen UI-Läufen sind außerdem Simulator-Klone, temporäre Daten, Logs und Medienartefakte zu beobachten. Eine allgemeine Kapazitätszahl lässt sich aus der Xcode-Dokumentation nicht ableiten. Deshalb sollte das Team keine feste Knotenanzahl aus Blogwerten übernehmen. Die passende Parallelität wird aus eigenen Laufzeiten, Wiederholungsfehlern, Arbeitsspeicherverbrauch und Wiederherstellungstests bestimmt.

[ SECTION_06 ] Die passende Topologie hängt von der Verantwortlichkeit ab

Die folgende Matrix ist als Entscheidungshilfe gedacht. Sie ersetzt nicht den Lauf mit dem realen Projekt, grenzt aber die Zuständigkeiten sauber ein.

CI-Aufgabe oder Team	Simulator-Runtime auf dem Buildknoten	Geeignete Knotenstrategie	Abnahmekriterium
Statische Analyse und Swift-Logik	Nicht grundsätzlich erforderlich	Leichter Buildknoten	Kein App-Start, keine Destination-Anforderung
Reine Kompilierung mit unterstützten UIKit-Dokumenten	Nicht grundsätzlich erforderlich	Leichter Buildknoten	Toolchain-Modus im Log bestätigt
Storyboard- und XIB-Kompilierung in altem Projekt	Projektabhängig	Zunächst Doppelprüfung	Keine unerwartete Rückfallbedingung
build-for-testing	Häufig ohne gestartete Runtime möglich	Buildknoten mit Artefaktübergabe	Identische Tools und Produkte auf beiden Knoten
Unit-Test mit App-Host	Erforderlich	Vollständiger Testknoten	App-Prozess und Destination nachgewiesen
UI-Test mit XCTest	Erforderlich	Vollständiger Testknoten	App-Start, Interaktion und Ergebnisbundle
Plattform- und Kompatibilitätstest	Erforderlich	Testknoten oder physisches Gerät	Zielversion und Laufzeit dokumentiert
Release-Validierung	Je nach Prüfschritt erforderlich	Getrennter Test- und Releasepfad	Vergleich mit Referenzlauf und Rückfallplan

Für die Übergabe zwischen den Knoten ist Apples technische Beschreibung von Build For Testing und Test Without Building relevant. Der Buildknoten erzeugt die vorbereiteten Artefakte. Der Testknoten führt sie mit einer passenden Destination aus. Toolchain, SDK, Signierung und Pfade müssen dabei zusammenpassen.

[ SECTION_07 ] Drei Betriebsmodelle für DevOps- und Plattformteams

Ein gemeinsamer Pool

Ein gemeinsamer Pool ist sinnvoll, wenn das Projekt klein ist, die Pipeline selten läuft und die Simulator-Runtime bereits zuverlässig eingerichtet ist. Der Betrieb ist einfacher. Dafür bleiben alle Builds an die schwerere Umgebung gebunden. Caches, simulierte Geräte und Testdaten können sich gegenseitig beeinflussen.

Dieses Modell eignet sich nicht als erste Wahl, wenn reine Builds einen großen Anteil der Pipeline ausmachen und der Testknoten regelmäßig durch UI-Szenarien blockiert wird.

Getrennter Build- und Testpool

Der Doppelpool ist die robuste Standardoption für Teams mit gemischten Lasten. Der leichte Remote-Mac-Buildknoten übernimmt Quellcodeprüfung, Kompilierung und Artefakterzeugung. Der vollständige Testknoten erhält die Simulator-Runtimes, Test Plans und UI-Automatisierung.

Die Trennung reduziert nicht automatisch jede Wartezeit. Sie schafft aber eine überprüfbare Grenze: Ein Build braucht keine Runtime, ein Testlauf schon. Für die Plattform bedeutet das zwei getrennte Initialisierungs- und Wiederherstellungsprofile. Das sollte in der Konfiguration von Remote-Mac-Entwicklungsumgebungen als technische Anforderung dokumentiert werden.

Migration vorerst verschieben

Eine Verschiebung ist korrekt, wenn das Projekt viele alte Build-Skripte verwendet, die Beta-Version bekannte Fehler zeigt oder Testartefakte nicht reproduzierbar zwischen Knoten übertragen werden. In diesem Fall bleibt der bestehende vollständige Knoten aktiv. Ein separater Versuchsknoten prüft die neue Aufteilung ohne Eingriff in die Produktionspipeline.

Diese Entscheidung ist kein Scheitern. Sie verhindert, dass ein scheinbar kleiner Xcode-Wechsel die Release-Abnahme oder die Wiederherstellung nach einem Knoten-Neustart gefährdet.

[ SECTION_08 ] FAQ für die konkrete CI-Planung

Kann ein iOS-Projekt mit Xcode 27 im CI ohne heruntergeladenen Simulator gebaut werden?

Ja, aber nur für die jeweils bestätigten Buildpfade. UIKit-Interface-Builder-Dokumente können im Toolchain-Modus ohne Simulator-Runtime kompiliert werden. Der Build darf daraus nicht ableiten, dass Tests ebenfalls ohne Runtime laufen. Ein separater build-for-testing- und Testlauf muss den tatsächlichen Ressourcenbedarf des Projekts zeigen.

Welche iOS-CI-Aufgaben benötigen weiterhin eine Simulator-Runtime?

Sobald eine Anwendung gestartet, eine UI bedient oder iOS-Plattformverhalten geprüft wird, gehört die Aufgabe auf einen vollständigen Testknoten. Das betrifft App-Host-Tests, XCTest-UI-Tests und Kompatibilitätsprüfungen gegen eine bestimmte iOS-Version. Reine Swift-Logiktests können dagegen häufig früher im Buildpool laufen, sofern sie keinen App-Prozess benötigen.

Kann der Interface-Builder-Toolchain-Modus bestehende Storyboards und XIB-Dateien beeinflussen?

Der Modus verändert den Kompilierungspfad für unterstützte UIKit-Dokumente. Besonders geprüft werden müssen ältere Projekte, eigene Build Settings und direkte ibtool-Aufrufe. Die Kontrolle umfasst Logs, erzeugte Ressourcen und einen tatsächlichen App-Start. Bei einem Rückfall in den Simulator-Modus werden Target, Auslöser und Wiederherstellungsschritt dokumentiert.

Wie sollten Remote-Mac-Buildknoten und Testknoten getrennt werden?

Der Buildpool verarbeitet Aufgaben ohne gestartete iOS-Laufzeit. Der Testpool hält Simulator-Runtimes, simulierte Geräte und Testdaten bereit. Als Übergabepunkt dienen vorbereitete Testartefakte. Vor der produktiven Umstellung läuft derselbe Commit auf beiden Wegen. Die Plattform vergleicht Ergebnisbundles, Toolchain, Signierung und Verhalten nach einem Neustart.

[ SECTION_09 ] Der Release-Verantwortliche entscheidet mit einem Doppel-Lauf

Die finale Entscheidung sollte nicht aus einer einzelnen grünen Pipeline entstehen. Ein realer Commit mit Storyboard oder XIB, App-Host-Test und UI-Test bildet die bessere Grundlage.

Dafür werden folgende Schritte ausgeführt:

1. Referenzknoten und Kandidatenknoten mit derselben Xcode-27-Version vorbereiten.
2. Das Projekt ohne Änderungen auf beiden Knoten auschecken.
3. Reinen Build und build-for-testing separat ausführen.
4. Die vorbereiteten Artefakte mit test-without-building auf dem vollständigen Testknoten starten.
5. App-Host- und UI-Tests mit dem vorgesehenen Test Plan ausführen.
6. Logs, Ergebnisbundles, Ressourcenfehler und Destination-Auflösung vergleichen.
7. Einen Neustart des Testknotens und die Wiederherstellung der Simulatorumgebung prüfen.
8. Bei Abweichungen den Produktionspfad unverändert lassen und den Rückfall dokumentieren.

Erst wenn der reine Build wiederholt durchläuft, keine versteckte Runtime anfordert und die Artefakte auf dem vollständigen Testknoten korrekt getestet werden, ist eine Auslagerung sinnvoll. Der Simulator wird damit nicht aus der Organisation entfernt. Er wird nur dort betrieben, wo die Laufzeit tatsächlich gebraucht wird.

Für Teams, die eine physische Alternative gegen laufende Infrastrukturkosten abwägen, kann auch ein Mac-mini-Bestellmodell für Entwicklungsteams als Vergleichspunkt dienen. Ein eigener Rechner bietet dauerhafte Kontrolle, bindet aber Kapital, Wartung und Wiederherstellungsverantwortung. Ein Remote Mac lässt sich dagegen für einen abgrenzbaren Build- oder Testzeitraum einsetzen.

Die Entscheidung gegen einen Simulator auf jedem Knoten ist daher sinnvoll, die pauschale Entfernung aus allen Knoten jedoch nicht. Der bessere Weg ist ein rückfallfähiger Doppel-Lauf mit klarer Trennung zwischen Kompilierung und Ausführung.

Wenn für die Prüfung eines echten Projekts kurzfristig ein isolierter Build- oder Testknoten benötigt wird, kann NOVAKVM eine passend befristete Remote-Mac-Umgebung bereitstellen. Das erlaubt die Validierung von Toolchain-Modus, Simulator-Test und Wiederherstellung, ohne die bestehende Produktionsmaschine sofort umzubauen.