Wie führt man auf dem Mac mehrere iOS-Simulatoren aus? Xcode-Tests auf mehreren Geräten, Speicherverbrauch und Build-Effizienz im Praxistest

Ein Simulatorfenster lässt sich öffnen, aber sobald weitere Geräte und ein Build dazukommen, wird der Mac spürbar langsamer.
Schnellste Lösung: Starten Sie mehrere iOS-Simulatoren über Xcode, wählen Sie die Geräte nach Ihren Testfällen aus und messen Sie Speicherverbrauch, Build-Zeit und Testlauf getrennt. Mehr Simulatoren ermöglichen mehr Geräteabdeckung, garantieren aber keinen schnelleren Build.

Dieser Leitfaden richtet sich an iOS-Entwickler, die Geräte- oder Systemvarianten vergleichen und Regressionen nachvollziehbar prüfen möchten.
Wenn Sie Build, Tests und Simulatoren parallel ausführen, hilft Ihnen die Messmethode, Ressourcenengpässe von Projektproblemen zu unterscheiden.
Auch wenn Sie eine lokale und eine entfernte Mac-Umgebung abwägen, erfahren Sie, welche Messwerte für einen belastbaren Vergleich nötig sind.

Mehrere iOS-Simulatoren auf dem Mac: Was die Messung aussagen muss

Xcode kann Apps sowohl auf simulierten als auch auf physischen Geräten ausführen. Mehrere Simulatoren eignen sich für parallele oder vergleichende Tests; sie sind jedoch keine Zusage für kürzere Kompilierzeiten. Die Apple-Dokumentation zum Ausführen von Apps auf simulierten oder physischen Geräten beschreibt die grundsätzliche Geräteauswahl. Daraus folgt keine allgemeine Leistungsangabe für eine bestimmte Mac-Konfiguration.

Für Ihre Entscheidung sind drei Vorgänge getrennt zu betrachten:

• Simulatorstart: Die virtuelle Geräteumgebung wird geöffnet und beansprucht Ressourcen, auch wenn gerade kein Test läuft.
• Build: Xcode kompiliert und verknüpft das Projekt. Das Ergebnis hängt unter anderem vom Projektzustand, den Build-Einstellungen und der verfügbaren Systemleistung ab.
• Testausführung: Die App wird auf ausgewählten Geräten gestartet und Testfälle werden ausgeführt. Je nach Testart können mehrere Simulatoren gleichzeitig arbeiten oder nacheinander geprüft werden.

Wer diese Zeiten zusammenwirft, kann nicht erkennen, ob ein langsamer Durchlauf durch den Build, den Simulatorstart oder den Test selbst verursacht wurde. Notieren Sie daher für jeden Messlauf die drei Phasen separat. Apple beschreibt in der Dokumentation zum Ausführen von Tests und Interpretieren der Ergebnisse, wie Testläufe und Resultate in Xcode nachvollziehbar geprüft werden können.

Bei der Auswahl der Testgeräte zählt nicht die größtmögliche Zahl geöffneter Fenster. Relevant ist, welche Unterschiede Ihre Anwendung tatsächlich abdecken muss: etwa unterstützte Gerätegrößen, relevante iOS-Laufzeitumgebungen oder Funktionen, die sich auf einzelnen Gerätetypen anders verhalten. Simulatoren ersetzen zudem nicht in jedem Fall einen Test auf physischer Hardware. Wenn ein Fehler mit Sensoren, tatsächlicher Geräteleistung oder einem Hardwareanschluss zusammenhängt, planen Sie dafür einen passenden Test auf einem realen Gerät ein.

Geräteauswahl und Start in Xcode

Legen Sie zunächst fest, welche Tests parallel laufen müssen und welche Gerätevarianten lediglich in der Regression geprüft werden. Die Liste sollte sich aus Produktanforderungen und Fehlerhistorie ergeben. Ein weiteres geöffnetes Gerät bringt wenig, wenn es denselben Testpfad und dieselbe relevante Geräteklasse wie ein bereits berücksichtigtes Gerät abdeckt.

Gehen Sie für einen reproduzierbaren Start wie folgt vor:

1. Laufzeitumgebungen prüfen. Öffnen Sie Xcode und kontrollieren Sie, welche Simulator-Laufzeiten und Geräte verfügbar sind. Falls eine benötigte Laufzeit fehlt, orientieren Sie sich an Apples Anleitung zum Laden und Installieren zusätzlicher Xcode-Komponenten. Vermerken Sie, welche Laufzeit Sie für den Test verwenden.
2. Geräteauswahl festhalten. Wählen Sie die benötigten Geräte in Xcode aus und notieren Sie den angezeigten Gerätetyp sowie die verwendete Laufzeit. Verwenden Sie in Vergleichsläufen dieselbe Kombination.
3. Simulatoren starten. Öffnen Sie die ausgewählten Geräte über Xcode beziehungsweise die Simulator-App. Prüfen Sie für jedes Fenster, ob tatsächlich das vorgesehene Gerät gestartet wurde.
4. Projektzustand dokumentieren. Halten Sie den verwendeten Projektstand, das Build-Schema und relevante Build-Einstellungen fest. Wenn sich Projekt oder Einstellungen zwischen den Läufen ändern, ist der Leistungsvergleich nicht mehr aussagekräftig.
5. Start und Test auseinanderhalten. Warten Sie, bis die Geräte betriebsbereit sind, und erfassen Sie den Startzeitpunkt getrennt vom Beginn des Builds und der Tests. So wird Simulator-Startzeit nicht versehentlich als Kompilierzeit gewertet.
6. Testplan ausführen. Verwenden Sie auf den ausgewählten Simulatoren denselben Testumfang. Prüfen Sie anschließend in Xcode die Resultate und sichern Sie das Protokoll.

Für automatisierte Abläufe können Sie zusätzlich die Xcode-Kommandozeilenwerkzeuge verwenden. Apples Referenz zu den Xcode-Kommandozeilenwerkzeugen erläutert deren Einsatz. Ein Kommandozeilenlauf kann die Wiederholbarkeit verbessern, ersetzt aber nicht die Dokumentation der verwendeten Geräte und Build-Einstellungen. Ein aussagekräftiges Protokoll sollte zeigen, welche Ziele gewählt wurden, welcher Befehl ausgeführt wurde und welche Zeitmessung Sie anschließend ausgewertet haben.

Hinweis: Installierte Laufzeit, ausgewähltes Gerät und aktives Simulatorfenster sind nicht dasselbe. Prüfen Sie vor dem Messlauf jedes gestartete Gerät, statt aus dem Fenstertitel oder einer früheren Auswahl auf die aktuelle Testumgebung zu schließen.

Arbeitsspeicher erfassen, statt eine feste Simulatorzahl anzunehmen

Der Speicherbedarf mehrerer Simulatoren lässt sich ohne klar beschriebene Testumgebung nicht auf eine allgemeingültige Zahl reduzieren. Das Ergebnis verändert sich, wenn Sie andere Geräte oder Laufzeiten verwenden, die App unterschiedliche Daten lädt oder nebenbei weitere Aufgaben ausführen. Auch ein Build während des Tests kann die Speichernutzung beeinflussen. Deshalb wäre eine pauschale Aussage wie „so viele Simulatoren passen auf jeden Mac“ keine belastbare Kauf- oder Betriebsgrundlage.

Verwenden Sie die Aktivitätsanzeige und erfassen Sie mindestens diese Zustände:

• Ausgangszustand: Starten Sie den Mac mit dem für Ihre Tests üblichen Hintergrundbetrieb. Erfassen Sie den Arbeitsspeicher, bevor Simulatoren geöffnet werden.
• Nach jedem Simulatorstart: Öffnen Sie die Geräte einzeln und notieren Sie den veränderten Zustand. So sehen Sie, ob zusätzliche Geräte jeweils ähnliche oder deutlich unterschiedliche Auswirkungen haben.
• Während der Testausführung: Messen Sie erneut, wenn App, Testdaten und Xcode parallel aktiv sind. Dieser Zustand entspricht eher Ihrer tatsächlichen Arbeitslast als ein bloß geöffnetes Simulatorfenster.
• Während des Builds: Erfassen Sie einen separaten Build-Lauf, wenn Sie normalerweise gleichzeitig kompilieren und Tests ausführen.
• Nach dem Schließen: Beobachten Sie, ob sich die Situation nach dem Beenden der Simulatoren und Testprozesse normalisiert.

In der Aktivitätsanzeige sind der Speicherdruck und der verwendete Swap hilfreiche Hinweise auf die aktuelle Systembelastung. Apple erläutert diese Anzeigen in der Anleitung zum Prüfen von Speicherdruck und Swap auf dem Mac. Ein einzelner Wert für den von einem Prozess belegten Speicher sagt für sich genommen nicht, ob Ihre Testkonfiguration stabil läuft. Berücksichtigen Sie den Gesamtzustand und prüfen Sie, ob die Reaktionsfähigkeit während der realistischen Arbeitslast erhalten bleibt.

Vergleichen Sie außerdem nicht nur den Zustand direkt nach dem Start. Eine App kann beim Laden größerer Testdaten oder beim Ausführen bestimmter Testfälle zusätzlichen Speicher benötigen. Umgekehrt kann ein untätiger Simulator weniger repräsentativ sein als ein aktiver Testlauf. Notieren Sie, welche App-Aktion während der Messung stattfand, und vermeiden Sie andere nicht vorgesehene Aufgaben im Hintergrund.

Bei knappen Ressourcen sollte die erste Reaktion nicht sein, sofort zusätzliche Hardware anzunehmen. Schließen Sie nicht benötigte Simulatoren, stoppen Sie unbeteiligte Prozesse und wiederholen Sie denselben Test. Bleibt der Speicherdruck unter derselben Arbeitslast hoch oder verschlechtert sich die Stabilität, reduzieren Sie die gleichzeitige Gerätezahl oder teilen Sie die Tests in Gruppen auf. Erst der wiederholte Vergleich zeigt, ob die Änderung den Engpass tatsächlich behebt.

Build-Effizienz und Testdauer getrennt vergleichen

Mehr parallel laufende Simulatoren erhöhen die Testabdeckung, nicht automatisch die Build-Geschwindigkeit. Beim Kompilieren konkurrieren Prozesse um Ressourcen; außerdem ist ein Erst-Build nicht direkt mit einem inkrementellen Build vergleichbar. Änderungen am Projekt, am Cache-Zustand oder an den Build-Einstellungen können die gemessene Zeit ebenfalls beeinflussen.

Vergleichen Sie drei Messwerte separat:

• Erst-Build: Erfassen Sie den Build nach dem für Ihren Ablauf vorgesehenen sauberen Ausgangszustand. Notieren Sie, ob und wie vorherige Build-Artefakte entfernt wurden.
• Inkrementeller Build: Ändern Sie einen festgelegten Teil des Projekts und erfassen Sie den anschließenden Build. Apple beschreibt in seiner Anleitung zum Verbessern der Geschwindigkeit inkrementeller Builds, wie sich diese Build-Art untersuchen lässt.
• Testlauf: Messen Sie die Zeit für dieselben Tests auf derselben Geräteauswahl, ohne die Dauer des Builds dazuzuzählen.

Halten Sie Code, Scheme, Build-Einstellungen, Geräteauswahl und parallele Aufgaben zwischen den Vergleichsläufen konstant. Erfassen Sie die Zeiten aus Xcode-Protokollen oder einem nachvollziehbaren Zeitprotokoll. Wiederholen Sie den Lauf, wenn währenddessen ein anderes Projekt kompiliert, ein größeres Hintergrundupdate läuft oder ein Test unerwartet fehlschlägt. Solche Abweichungen machen die Zuordnung des Engpasses schwieriger.

Achten Sie beim Auswerten auf das Muster, nicht nur auf die Gesamtdauer. Wenn der Build ohne zusätzliche Simulatoren bereits langsam ist, bringt eine andere Geräteauswahl allein wahrscheinlich keine Erklärung. Wenn der Build erst bei gleichzeitigen Tests länger dauert und zugleich der Arbeitsspeicherdruck steigt, ist die Konkurrenz um Systemressourcen ein plausibler Prüfpunkt. Wenn der Build stabil bleibt, aber die Testphase länger wird, untersuchen Sie Testparallelisierung, App-Start und Testablauf, statt die Kompilierung verantwortlich zu machen.

Bei automatisierten Testläufen empfiehlt es sich, Ergebnisse und Fehler pro Zielgerät zu prüfen. Ein erfolgreicher Build auf einem Simulator belegt nicht, dass alle ausgewählten Tests erfolgreich waren. Trennen Sie daher Buildstatus, Testergebnis und Laufzeit in Ihrem Bericht. Für ein Team sind diese Angaben besonders nützlich, wenn jemand einen langsamen Lauf wiederholen oder einen Fehler auf einer bestimmten Laufzeit eingrenzen muss.

Geräteauswahl nach Ressourcen und Testziel abwägen

Nutzen Sie die folgenden Auswahloptionen, statt eine feste Zahl gleichzeitig geöffneter Simulatoren als Richtwert zu übernehmen:

• Alle benötigten Geräte parallel starten: Wählen Sie diese Variante, wenn Ihre Tests unterschiedliche Geräteeigenschaften parallel abdecken müssen, der Speicherdruck unter der realistischen Arbeitslast stabil bleibt und die Builds nicht auffällig länger dauern. Der Vorteil ist ein direkter Vergleich innerhalb desselben Testfensters. Der Nachteil ist die zusätzliche Konkurrenz um Ressourcen.
• Tests in kleinere Gerätegruppen aufteilen: Wählen Sie diese Variante, wenn parallele Geräte die Bedienbarkeit oder Teststabilität beeinträchtigen. Der Vorteil ist eine besser kontrollierbare Last. Der Nachteil: Sie benötigen getrennte Durchläufe und müssen darauf achten, dass jeder relevante Testpfad weiterhin ausgeführt wird.
• Simulatoren bei Bedarf einzeln starten: Wählen Sie diese Variante, wenn Fehler gezielt auf einer Geräte- oder Laufzeitkombination reproduziert werden sollen. Sie reduzieren damit unnötige parallele Last, verlieren aber den unmittelbaren Vergleich mehrerer aktiver Geräte.
• Lokalen und entfernten Mac vergleichen: Wählen Sie diese Prüfung, wenn Ihre Teamabläufe, parallelen Aufgaben oder der Zugriff auf eine gemeinsam verwaltete Umgebung wichtiger sind als ein einzelner lokaler Lauf. Treffen Sie die Entscheidung anhand dokumentierter Konfigurationen und derselben Testaufgabe, nicht anhand einer unbelegten Leistungsannahme.

Entscheidungscheckliste für Ihren nächsten Testlauf:

• [ ] Sind die Gerätevarianten durch konkrete Anforderungen, Fehlerberichte oder Testfälle begründet? Wenn nicht, streichen Sie redundante Ziele aus der parallelen Gruppe.
• [ ] Bleibt der Mac während Simulatorstart, Build und Testausführung reaktionsfähig? Wenn nicht, schließen Sie zunächst unbeteiligte Prozesse und wiederholen Sie denselben Lauf.
• [ ] Steigen Speicherdruck oder Swap-Nutzung während derselben Testaufgabe deutlich an? Wenn ja, reduzieren Sie die parallele Gerätezahl oder teilen Sie die Testgruppe und messen Sie erneut.
• [ ] Bleibt der Build vergleichbar, während nur die Testphase länger wird? Wenn ja, untersuchen Sie Testablauf und Parallelisierung, statt den Build als Ursache anzunehmen.
• [ ] Werden nur einzelne Geräte für die Fehlerreproduktion benötigt? Wenn ja, starten Sie diese gezielt, statt alle Simulatoren dauerhaft geöffnet zu lassen.
• [ ] Sind die lokalen Ressourcen trotz angepasster Gerätegruppen weiterhin ein Engpass oder braucht das Team eine gemeinsam verfügbare Umgebung? Wenn ja, vergleichen Sie eine entfernte Mac-Umgebung anhand derselben dokumentierten Messbedingungen.
• [ ] Benötigen Sie für einen Fehler reale Hardware oder physische Schnittstellen? Wenn ja, planen Sie einen Test auf einem geeigneten physischen Gerät ein; ein Simulator allein genügt dann nicht.

Eine praxistaugliche Reihenfolge für die Anpassung lautet: zuerst nicht benötigte Simulatoren schließen, danach Tests in Gruppen teilen, anschließend unnötige Hintergrundaufgaben beenden und zuletzt den gesamten Messlauf wiederholen. Ändern Sie jeweils nur einen wesentlichen Faktor. Wenn Sie gleichzeitig Gerätezahl, Build-Einstellungen und Testumfang verändern, lässt sich nicht erkennen, welche Maßnahme den Unterschied bewirkt hat.

Für die endgültige Auswahl zählen drei Kriterien: Abdeckung, Stabilität und Durchsatz. Abdeckung beantwortet, ob die relevanten Geräte- und Laufzeitvarianten geprüft werden. Stabilität zeigt, ob Tests reproduzierbar ohne Ressourcenausfälle laufen. Durchsatz beschreibt, wie viele aussagekräftige Testläufe Ihr Team innerhalb seines Arbeitsablaufs abschließen kann. Eine kleinere Gerätegruppe kann die bessere Wahl sein, wenn sie die kritischen Varianten zuverlässig prüft und sich weitere Geräte in einem separaten Lauf ergänzen lassen.

Lokale und entfernte Umgebung fair bewerten

Ein seriöser Vergleich zwischen lokalem und entferntem Mac setzt echte Messprotokolle voraus. Dafür müssen Sie die tatsächlich verwendete Konfiguration, macOS- und Xcode-Umgebung, Simulatorgeräte, den Projektstand, die Testschritte und die Messmethode dokumentieren. Ohne diese Nachweise lässt sich weder der Arbeitsspeicher noch die Build-Effizienz fair gegenüberstellen. Eine entfernte Umgebung ist nicht allein deshalb schneller, weil sie außerhalb Ihres Arbeitsplatzes läuft.

Prüfen Sie zusätzlich, ob die Art des Zugriffs zu Ihrem Testablauf passt. Bei einer entfernten Sitzung sind Verbindung und Anzeige Teil der täglichen Arbeit; bei lokaler Ausführung können Sie unmittelbar auf vorhandene Peripherie zugreifen. Für ein Team können gemeinsamer Zugriff, Datenschutz und die Verwaltung von Projekt- und Testdaten entscheidend sein. Wenn vertrauliche Projektdaten verarbeitet werden, beziehen Sie die geltenden Datenschutzanforderungen ein und prüfen Sie die Datenschutzhinweise für die jeweilige Nutzung.

Für Ihre Vergleichsläufe genügt ein kurzes Protokoll mit folgenden Angaben:

• Mac und tatsächlich verfügbare Konfiguration, ohne nicht verifizierte Annahmen;
• macOS, Xcode und ausgewählte Simulator-Laufzeiten;
• Projektstand, Scheme und Build-Einstellungen;
• Reihenfolge der Simulatorstarts und Testschritte;
• Speicherzustand vor, während und nach der Last;
• Erst-Build, inkrementeller Build und Testdauer getrennt;
• Hinweise zu Fehlern, Hintergrundlast und Wiederholungen.

Wenn Ihnen für eine Umgebung keine überprüfbaren Daten vorliegen, lassen Sie den direkten Leistungsvergleich offen. Sie können dennoch die lokale Arbeitslast protokollieren und anschließend dieselben Schritte in einer zugänglichen entfernten Umgebung wiederholen. Für einen ersten Überblick über eine mögliche Mietumgebung können Sie die Angaben zu Mac mini mieten heranziehen; bestätigen Sie vor einer Entscheidung die für Ihren Testfall relevanten Details anhand der aktuellen Informationen. Dieser Verweis ersetzt keine Messung und belegt keine bestimmte Leistung.

Häufige Fragen zur Messung und Testauswahl

Kann ich unterschiedliche iOS-Laufzeiten parallel testen?

Ja, sofern die benötigten Simulator-Laufzeiten installiert und in Xcode verfügbar sind. Wählen Sie jedes Ziel bewusst aus und dokumentieren Sie Gerät sowie Laufzeit. Ob die konkrete Kombination in Ihrer Xcode-Umgebung unterstützt wird, prüfen Sie anhand der dort angezeigten Ziele und der offiziellen Apple-Dokumentation. Für eine Aussage über Leistung reicht die Kompatibilität allein nicht aus; messen Sie den Testlauf auf Ihrer tatsächlichen Konfiguration.

Welcher Messwert zeigt, dass meinem Mac Ressourcen fehlen?

Bewerten Sie keinen Einzelwert isoliert. Beobachten Sie Speicherdruck, Swap-Nutzung, Reaktionsfähigkeit und die Dauer von Build und Tests während derselben Arbeitslast. Wiederholen Sie den Lauf mit weniger gleichzeitig geöffneten Simulatoren. Verbessert sich die Stabilität dabei nachvollziehbar, spricht das für eine Ressourcenbegrenzung in der ursprünglichen Testkombination. Halten Sie fest, welche Änderung den Unterschied verursacht hat.

Wie verhindere ich, dass ein schnellerer Build nur auf einem warmen Cache beruht?

Vergleichen Sie Erst-Build und inkrementellen Build als getrennte Messungen und dokumentieren Sie den Ausgangszustand des Projekts. Verwenden Sie dieselben Build-Einstellungen und ändern Sie für inkrementelle Vergleiche denselben definierten Projektbereich. Sichern Sie das Xcode-Protokoll und führen Sie die Messung unter vergleichbaren Bedingungen erneut aus. Ein einzelner Zeitwert ohne Angaben zum Cache-Zustand belegt keinen allgemeinen Leistungsgewinn.

Wann sind mehrere Simulatoren für Regressionstests sinnvoll?

Parallel gestartete Simulatoren sind sinnvoll, wenn unterschiedliche Geräte- oder Laufzeitvarianten gleichzeitig geprüft werden müssen und die Tests unter dieser Last stabil bleiben. Wenn die zusätzliche Parallelität Build oder Bedienung beeinträchtigt, können Sie dieselbe Abdeckung in Gerätegruppen aufteilen. Entscheidend ist, dass jeder relevante Testpfad dokumentiert bleibt und Teammitglieder Fehler anhand von Gerät, Laufzeit und Testprotokoll reproduzieren können.

Wenn Ihre Messungen zeigen, dass lokale Builds und Tests bei der benötigten Geräteabdeckung stabil laufen, ist die lokale Umgebung meist der einfachere Weg: Sie arbeiten direkt mit Ihren vorhandenen Geräten und vermeiden zusätzliche Zugriffsabhängigkeiten. Werden dagegen Simulatoren, Builds und andere Teamaufgaben gleichzeitig zur Belastung, können begrenzte Ressourcen, konkurrierende Prozesse und schwer reproduzierbare Lastspitzen den Ablauf bremsen. Dann kann ein gemieteter Mac von Kvmzen als alternative Testumgebung interessant sein; vergleichen Sie ihn anhand Ihrer eigenen Messwerte, der bestätigten Konfiguration und Ihrer Datenschutzanforderungen. Bei dauerhaft hoher, planbarer Auslastung oder wenn Sie physische Schnittstellen benötigen, prüfen Sie zuerst, ob ein eigener Mac beziehungsweise ein lokaler Testaufbau besser zu Ihrem Betrieb passt.

Häufig gestellte Fragen