iOS 27 Simulator: Speicher knapp – 2026 löschen oder erweitern?

„Speicher knapp“ beschreibt nur das Symptom. Für die richtige Entscheidung müssen Sie fünf Datenklassen auseinanderhalten:

• Simulator Runtime: Das simulierte iOS-Betriebssystem. Mehrere Runtimes werden benötigt, wenn Sie verschiedene Mindestversionen oder Systemstände testen.
• Simulierte Geräte: Konkrete iPhone- oder iPad-Instanzen mit App-Daten, Einstellungen, Logs und Testzuständen.
• DerivedData: Von Xcode erzeugte Indexdaten, Build-Produkte und temporäre Projektartefakte.
• Archives: Exportierbare Build-Stände. Sie können für TestFlight, App-Store-Veröffentlichungen oder spätere Rückverfolgung wichtig sein.
• Abhängigkeiten und Logs: Paketmanager-Downloads, lokale Framework-Artefakte, Crash-Logs und CI-Ausgaben.

Diese Gruppen haben unterschiedliche Risiken. Eine alte Geräteinstanz ist nicht dasselbe wie eine Runtime. DerivedData kann neu entstehen. Ein signiertes Archive oder ein für eine Rückabwicklung benötigter Build sollte dagegen nicht wie ein beliebiger Cache behandelt werden.

Beginnen Sie in macOS mit Systemeinstellungen > Allgemein > Speicher. Nutzen Sie danach Xcode und die Ordneranalyse, statt die gesamte Developer-Struktur pauschal zu löschen. Prüfen Sie insbesondere, ob der Engpass beim Herunterladen der iOS-27-Komponenten, beim Kompilieren, beim Start des Simulators oder erst beim Erstellen eines Archives auftritt.

Für eine grobe Zuordnung können Sie im Terminal die belegten Ordner anzeigen:

du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

Diese Befehle lesen lediglich Größen aus. Sie löschen nichts. Der Platzhalter ~ steht für das Home-Verzeichnis des aktuell angemeldeten Benutzers. Auf einem gemeinsam genutzten Buildhost müssen Sie zusätzlich prüfen, unter welchem Benutzer der Dienst läuft. Eine Ausgabe unter Ihrem Konto zeigt nicht automatisch die Daten anderer Konten.

Wenn Sie eine detailliertere Aufschlüsselung benötigen, verwenden Sie zunächst eine Liste der obersten Verzeichnisebenen:

du -sh ~/Library/Developer/* 2>/dev/null

Das kann je nach Dateimenge dauern. Es ist eine Diagnose, keine Bereinigung. Löschen Sie keine geschützten Systemverzeichnisse und deaktivieren Sie nicht den System Integrity Protection, um Speicherplatz zu gewinnen. Das wäre kein normaler Wartungsschritt für Xcode.

Die folgende Tabelle trennt die häufigsten Fälle. Sie ist kein Ersatz für die Speicherprüfung, verhindert aber, dass Sie eine Testumgebung für eine kurzfristige Entlastung beschädigen.

Die entscheidende Frage lautet nicht „Was kann ich löschen?“, sondern „Welche Daten muss mein nächster realer Build noch vorfinden?“ Wenn die Antwort mehrere Runtimes, Archives und Abhängigkeiten umfasst, verschiebt sich die Entscheidung von Bereinigung zu Kapazitätsplanung.

Wenn Sie eine einzelne App betreuen und vorwiegend gegen den aktuellen Entwicklungsstand testen, beginnen Sie mit dem kleinsten reproduzierbaren Setup. Öffnen Sie Xcode und kontrollieren Sie die installierten Komponenten über die dafür vorgesehene Verwaltung. Apple beschreibt dort, wie zusätzliche Komponenten installiert und nicht benötigte Komponenten entfernt werden können: offizielle Anleitung zur Xcode-Komponentenverwaltung.

Entfernen Sie eine nicht mehr benötigte Runtime bevorzugt über diesen Weg. So bleibt nachvollziehbar, welche Komponente fehlt und später erneut installiert werden muss. Eine manuelle Löschung tief in der CoreSimulator-Struktur erschwert dagegen die Diagnose und kann bei Beta-Versionen zu unklaren Zuständen führen.

Arbeiten Sie anschließend mit dieser Checkliste:

• [ ] Ist die Runtime für den nächsten lokalen Build oder Test wirklich überflüssig?
• [ ] Gibt es ein aktives Projekt, das genau diese iOS-Version in den Scheme-Einstellungen verwendet?
• [ ] Läuft ein CI- oder Signaturjob mit dieser Runtime?
• [ ] Sind die zu löschenden simulierten Geräte nur Testdaten und keine benötigten Reproduktionsstände?
• [ ] Sind wichtige Archives außerhalb des lokalen Cache-Bereichs gesichert?
• [ ] Können Paketabhängigkeiten nach einer Bereinigung reproduzierbar wiederhergestellt werden?

DerivedData können Sie selektiv über Xcode bereinigen. Alternativ können Sie den zum Projekt gehörenden Ordner unter ~/Library/Developer/Xcode/DerivedData identifizieren und entfernen. Der Effekt ist konkret: Der nächste Build muss Indexdaten und erzeugte Artefakte erneut anlegen. Ihr Quellcode, das Git-Arbeitsverzeichnis und Apple-Entwicklerzertifikate liegen nicht automatisch dort.

Behandeln Sie Signaturmaterial trotzdem separat. Zertifikate, Provisioning Profiles und Schlüssel sind keine Build-Caches. Eine Bereinigung darf nicht daraus bestehen, den gesamten Benutzerordner „Developer“ zu löschen.

Für eine App mit breiter Nutzerbasis sollten Sie vor dem Löschen eine Testmatrix festlegen. Schreiben Sie mindestens diese drei Ebenen auf:

1. die niedrigste unterstützte iOS-Version,
2. die wichtigste Version aus Ihrer tatsächlichen Nutzerverteilung,
3. iOS 27 für die laufende Anpassung und Regression.

Die drei Ebenen sind eine Arbeitsstruktur, keine Aussage über Marktanteile oder eine allgemeine Kompatibilitätsregel. Ihre Projektanforderungen entscheiden, ob zusätzliche Versionen erforderlich sind.

Eine simulierte Geräteinstanz können Sie entfernen, wenn nur deren App-Daten, Einstellungen oder ein fehlerhafter Testzustand stören. Die zugehörige Runtime bleibt dabei verfügbar. Das ist sinnvoll, wenn Sie schnell eine saubere Geräteinstanz benötigen, aber dieselbe iOS-Version im nächsten Regressionstest wieder verwenden.

Das Entfernen einer Runtime ist weitreichender. Alle simulierten Geräte, die darauf basieren, verlieren ihre Ausführungsumgebung. Die Geräteinstanz und das Betriebssystem sind daher getrennt zu bewerten. Apple dokumentiert die Installation zusätzlicher Simulatoren und die Geräteverwaltung in der Dokumentation zu weiteren Simulatoren.

Planen Sie vor der Bereinigung einen Wiederherstellungstest. Notieren Sie, welche Runtime benötigt wird, wie sie in Xcode angezeigt wird und welcher Scheme sie zugeordnet ist. Bei einer Beta-Toolchain können sich Menübezeichnungen, Systemanforderungen und Komponentenstatus ändern. Für Xcode 27 sollten Sie deshalb den aktuellen Stand der offiziellen Xcode-27-Release-Notes prüfen, bevor Sie eine Anleitung aus einer älteren Beta übernehmen.

Zwei Xcode-Installationen sind nicht automatisch zwei voneinander vollständig isolierte Welten. Beide können auf gemeinsame Simulator-Daten, Benutzerverzeichnisse oder ähnliche Build-Strukturen zugreifen. Vor dem Löschen müssen Sie daher den aktiven Developer-Pfad kontrollieren:

xcode-select -p

Der Befehl zeigt, welche Developer-Umgebung die Command-Line-Tools verwenden. Er verändert nichts. Zum Umschalten zwischen Installationen gibt es xcode-select; verwenden Sie die Änderung erst, nachdem Sie laufende Builds beendet und den gewünschten Pfad eindeutig identifiziert haben. Die offizielle Beschreibung der Einstellung finden Sie in Apples Dokumentation zu xcode-select und Command-Line-Tools.

Verwechseln Sie drei Vorgänge nicht:

• Xcode wechseln: Auswahl der aktiven Toolchain.
• Xcode-App entfernen: Löschen einer vollständigen Entwicklungsumgebung.
• Simulator-Daten bereinigen: Entfernen von Runtimes oder Geräteinstanzen.

Für Veröffentlichungen sollte die stabile Umgebung zurückfallfähig bleiben. Die Beta-Umgebung darf nach dem Prinzip „erneut installierbar“ schlanker gehalten werden, sofern kein laufender Test davon abhängt. Prüfen Sie vor jedem Löschlauf außerdem, ob Ihr CI-Skript explizit eine Xcode-Version, einen Simulatornamen oder ein Runtime-Identifikationsmerkmal erwartet.

Bei einem unbeaufsichtigten Buildhost entsteht das Problem nicht durch einen einzelnen großen Ordner, sondern durch kontinuierliches Wachstum. Archives, DerivedData, Logs und Abhängigkeiten können nach jedem Build erneut anwachsen. Eine Bereinigung, die nur einmal freien Speicher schafft, löst die Betriebsfrage nicht.

Legen Sie deshalb Regeln mit klarer Zuständigkeit fest:

• Archives werden nach Release- und Rückfallbedarf aufbewahrt, nicht unbegrenzt.
• Logs werden nach einer nachvollziehbaren Aufbewahrungsregel rotiert.
• DerivedData wird entfernt, wenn es veraltet oder beschädigt ist, nicht während eines laufenden Builds.
• Paketabhängigkeiten werden nur gelöscht, wenn der Wiederaufbau ohne manuelle Schritte funktioniert.
• Simulator-Geräte werden nach Testzweck gruppiert und nicht nach ihrem Namen blind entfernt.

Für Archive und Distribution gelten zusätzliche Bedingungen. Apple beschreibt typische Archivierungsprobleme in der Technote zu Archive-Fehlern und erläutert den Ablauf für Beta-Verteilung und Releases. Daraus folgt für die Wartung: Ein erfolgreicher lokaler Build ist nicht automatisch ein wiederherstellbares Release-Archive.

Auf einem Remote Mac prüfen Sie vor jeder automatischen Bereinigung:

• Bleiben Daten nach einem Neustart erhalten?
• Haben Sie die nötigen Rechte für Xcode, CoreSimulator und den Buildbenutzer?
• Können Runtimes nach einer Beschädigung erneut installiert werden?
• Wird ein unterbrochener Build sauber beendet oder startet er doppelt?
• Ist genügend Speicher vorhanden, um Abhängigkeiten und Buildprodukte während des Wiederaufbaus gleichzeitig zu halten?
• Können Sie den Zustand über SSH, VNC oder die Webkonsole kontrollieren?

Wenn die Umgebung regelmäßig unter den für einen vollständigen Build benötigten freien Speicher fällt, sollten Sie nicht nur den Löschzeitpunkt optimieren. Trennen Sie gegebenenfalls den Buildhost vom Simulator-Testhost oder wählen Sie einen Remote Mac mit einer geeigneteren Speicherausstattung. Für die Auswahl eines temporären Arbeitsumfelds können Sie die CALMVPS-Preisübersicht heranziehen; entscheidend bleiben dabei Ihre Runtime-Anzahl, Archive-Aufbewahrung und Buildfrequenz.

1. Fehlerphase festhalten

Notieren Sie, ob der Speicher beim Runtime-Download, beim Build, beim Simulatorstart oder beim Archive knapp wird. Diese Phase bestimmt, welche Datenklasse Sie untersuchen.

2. Speicherverbrauch zuordnen

Prüfen Sie macOS-Speicherinformationen, Xcode-Komponenten und die relevanten Verzeichnisse. Vergleichen Sie Runtime, CoreSimulator, DerivedData, Archives und Abhängigkeiten getrennt.

3. Testmatrix einfrieren

Halten Sie Mindestversion, Haupttestversion und iOS 27 fest. Markieren Sie jede Runtime, die ein lokaler oder automatisierter Test wirklich benötigt.

4. Reversible Inhalte zuerst entfernen

Beginnen Sie mit nicht benötigten simulierten Geräten und selektiver DerivedData. Entfernen Sie Runtimes erst über Xcode Components, wenn sie nicht mehr zur Matrix gehören. Erstellen Sie vor dem Löschvorgang ein Backup der wichtigen Archives.

5. Mit einem echten Projekt abnehmen

Führen Sie danach den realen Dependency-Installationsschritt, den Build, den Simulatorstart und ein Archive aus. Prüfen Sie außerdem Signierung, Upload-Vorbereitung und verbleibenden Speicher. Ein größerer freier Balken im Finder allein ist kein erfolgreicher Wartungstest.

Wählen Sie Bereinigung, wenn einmalig gewachsene Caches oder nicht mehr benötigte Geräte den Engpass verursachen und alle notwendigen Runtimes anschließend erhalten bleiben.

Wählen Sie Erweiterung, wenn Ihre Testmatrix sinnvoll ist, aber mehrere Runtimes, Archives und laufende Builds dauerhaft nicht gemeinsam in den verfügbaren Speicher passen. Das gilt besonders für einen Remote Mac, der ohne manuellen Eingriff arbeiten soll.

Wählen Sie Migration, wenn Jobs regelmäßig abbrechen, Daten nach Neustarts verschwinden, Berechtigungen nicht zuverlässig reproduzierbar sind oder die Toolchain nicht vollständig erhalten werden kann. Ein anderer Host ist dann nicht bloß komfortabler, sondern reduziert die Zahl der manuellen Wiederherstellungen.

Wenn Sie auf einen Remote Mac wechseln, sollten Sie zunächst mit einem echten Projekt und einer kurzen Laufzeit testen. Vergleichen Sie nicht nur den freien Speicher, sondern auch Runtime-Wiederherstellung, Archive-Aufbewahrung, Neustartverhalten, SSH-Zugriff und die Zeit bis zu einem reproduzierbaren Build. Bei CALMVPS können Sie dafür die verfügbaren Mac-Mietoptionen prüfen, ohne Ihre lokale Entwicklungsumgebung sofort aufzugeben.

Kann die iOS-27-Simulator-Runtime gelöscht werden?

Ja, wenn sie außerhalb Ihrer Testmatrix liegt. Verwenden Sie Xcode Components und prüfen Sie vorher Projekte, CI-Aufgaben und Regressionstests. Die Runtime gehört zur Entwicklungsumgebung, nicht zum Quellcode. Nach dem Entfernen müssen Sie sie für spätere iOS-27-Tests erneut installieren. Bei einer Beta-Version sollten Sie zusätzlich die aktuellen Release-Notes kontrollieren.

Was unterscheidet ein simuliertes Gerät von einer Runtime?

Ein simuliertes Gerät ist eine konkrete Instanz mit Daten und Einstellungen. Die Runtime ist das simulierte Betriebssystem. Löschen Sie ein Gerät, bleibt die iOS-Version normalerweise verfügbar. Entfernen Sie die Runtime, verlieren alle darauf basierenden Geräte ihre Ausführungsumgebung. Für einen sauberen Test reicht daher oft das Löschen der Geräteinstanz.

Beeinträchtigt das Löschen von DerivedData Ihr Projekt?

DerivedData enthält erzeugte Build- und Indexdaten. Ihr Quellcode und Ihre Signaturmaterialien liegen nicht automatisch dort. Nach dem Löschen muss Xcode mehr neu erzeugen, weshalb der nächste Build länger dauern kann. Löschen Sie gezielt den Projektordner und führen Sie anschließend einen echten Build aus. Entfernen Sie nicht pauschal alle Developer-Verzeichnisse.

Was tun bei regelmäßig vollem Speicher auf einem Remote Mac?

Messen Sie zuerst das Wachstum von Runtime, Geräten, DerivedData, Archives, Logs und Abhängigkeiten. Danach legen Sie Aufbewahrungs- und Rotationsregeln fest. Wenn die benötigte Testmatrix trotzdem regelmäßig den Speicher ausreizt, ist eine Erweiterung stabiler als wiederholtes Löschen. Prüfen Sie zusätzlich Persistenz, Berechtigungen und die Wiederherstellung nach einem Neustart.

Für unabhängige Entwickler ist der häufigste Fehler nicht eine zu große einzelne Datei, sondern eine unklare Grenze zwischen notwendiger Testumgebung und regenerierbarem Cache. Bereinigen Sie deshalb nur nach einer bekannten Testmatrix. Wenn iOS-27-Runtime, Archives und Abhängigkeiten auf dem bestehenden Host nicht dauerhaft zusammenpassen, ist ein größerer oder ausgelagerter Remote Mac die verlässlichere Lösung als wiederkehrende Notfalllöschungen.