Xcode Simulator nimmt zu viel Platz auf dem Mac ein? Was du zuerst aufräumen solltest

Wenn Xcode Simulator Platz auf deinem Mac frisst, trenne Simulator-Laufzeiten von Simulator-Gerätedaten, bevor du etwas löschst. Fang damit an zu überprüfen, was nicht verfügbar ist, was inaktiv ist und was du noch zum Testen brauchst — weil Simulator-Cleanup riskant wird, wenn du jeden Apple-seitigen Ordner wie wegwerfbaren Cache behandelst.

Das ist der Fehler, den Entwickler machen, wenn sie eine Cleanup-Regel lernen und sie überall anwenden. DerivedData ist das eine. Simulator-Laufzeiten und Simulator-Gerätzustand sind etwas anderes.

Der Speicher kann zurückgewonnen werden. Die Folgen sind nur weniger einheitlich.

Kurzfassung

Was Xcode-Simulatoren speichern und warum es sich ansammelt

Simulator-Speicher ist nicht eine Sache. Es sind mehrere Schichten, die sich gemeinsam ansammeln.

Auf hoher Ebene umfasst Xcode-Simulator-Speicher normalerweise:

• Laufzeit-Images für verschiedene iOS-Plattformversionen;
• erstellte Simulator-Geräte für verschiedene iPhone- und iPad-Modelle;
• pro-Gerät App-Daten, Einstellungen und Zustand in diesen Simulatoren;
• Apple-seitigen Entwickler-Churn, der wächst, wenn du SDKs, Gerätetypen und Xcode-Versionen wechselst.

Deshalb fühlen sich Entwickler oft von CoreSimulator verwirrt. Es ist einfach, auf die Ordnergröße zu schauen und anzunehmen, das Ganze sei nur Cache. In der Praxis ist manches eher wegwerfbarer Testzustand und manches Laufzeit-Support, von dem du noch abhängst.

Das Wachstumsmuster ist normal:

• du installierst ein neues Xcode oder SDK;
• neue Laufzeiten tauchen auf;
• neue Simulator-Geräte werden erstellt;
• Apps, Testdaten und Einstellungen sammeln sich darin;
• alte Geräte werden nach SDK-Wechseln oder Xcode-Upgrades nicht mehr verfügbar;
• nichts wird monatelang überprüft, weil die Maschine noch genug freien Platz hat.

Dann ist Simulator-Speicher eines Tages die Geschichte, nicht nur ein Detail.

Simulator-Laufzeiten vs. Simulator-Daten: Was ist der Unterschied?

Das ist die wichtigste Unterscheidung.

Apples simctl-Tooling behandelt Laufzeit-Operationen getrennt von Geräte-Operationen. Das allein sagt dir, dass das Cleanup-Modell geschichtet ist: Geräte sind nicht dasselbe wie Laufzeiten, und ein Gerät zurückzusetzen ist nicht dasselbe wie ein Laufzeit-Image zu löschen.

Deshalb sind pauschale Aussagen wie „einfach CoreSimulator leeren” schwacher Rat. Sie kollabieren verschiedene Cleanup-Folgen zu einer emotionalen Aktion.

Wo DerivedData einsortiert ist

DerivedData ist benachbart, aber nicht dasselbe Problem.

DerivedData ist generierte Build-Ausgabe. Simulator-Speicher ist gemischter. Er kann Laufzeiten enthalten, die du noch brauchst, erstellte Geräte, die du nicht mehr brauchst, und Zustand in Geräten, der dir mehr oder weniger egal sein kann.

Wenn der Druck hauptsächlich von generierter Build-Ausgabe kommt, ist die richtige Anleitung Xcode DerivedData nimmt zu viel Platz auf dem Mac ein? Was du zuerst aufräumen solltest. Wenn der Druck hauptsächlich von Laufzeit-Images und Simulator-Zustand kommt, bleib beim Simulator-Workflow.

Wie du überprüfst, wie viel Platz Simulatoren verbrauchen

Der erste Zug ist Inspektion, nicht Löschung.

Nutze Apples eigenes Tooling, um zu sehen, welche Geräte und Laufzeiten tatsächlich existieren:

xcrun simctl list devices
xcrun simctl list runtimes

Wenn du den breiten Apple-seitigen Speicher-Footprint auf der Festplatte inspizieren willst, kannst du die Hauptordner direkt vergleichen:

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

Das ist wichtig, weil der größte Apple-seitige Ordner nicht immer der ist, den du vermutest. Manchmal ist DerivedData das dominante Problem. Manchmal hat CoreSimulator es leise überholt.

Was du zuerst suchen solltest

• Geräte unter Unavailable;
• Laufzeiten für OS-Versionen, die du nicht mehr testest;
• viele erstellte Geräte über mehrere Laufzeit-Generationen hinweg;
• simulator-lastigen Zustand auf einer Maschine, die seit mehreren Xcode-Updates nicht aufgeräumt wurde;
• einen großen CoreSimulator-Ordner, der nicht zu deinen aktuellen Test-Bedürfnissen passt.

Das ist der Punkt, wo Cleanup rational statt reaktiv wird.

Ist es sicher, Simulator-Laufzeiten auf dem Mac zu löschen?

Manchmal, aber das ist nicht der sicherste erste Zug.

Apples simctl runtime-Hilfe macht klar, dass Laufzeit-Images eigene verwaltete Objekte sind. Eine Laufzeit zu löschen ist etwas anderes als den Inhalt eines Simulators zu leeren. Es ist auch etwas anderes als ein nicht verfügbares Gerät zu löschen.

Laufzeit-Löschung ist am besten, wenn:

• du diese iOS-Version nicht mehr zum Testen brauchst;
• du an einer älteren Xcode- oder SDK-Generation vorbeigezogen bist;
• die Laufzeit ungenutzt genug ist, dass der Platz mehr wert ist als die Bequemlichkeit;
• du die Laufzeitliste vorher überprüft hast und genau weißt, was du entfernst.

Es ist eine schlechtere Idee, wenn:

• ein aktives Projekt noch diese Laufzeit-Familie als Target hat;
• SwiftUI-Previews, QA-Reproduktionsschritte oder Regressionstests noch davon abhängen;
• du kurz vor einer Demo stehst oder einen Fehler auf einem älteren Target debuggen willst;
• du nur nach Größe löschst statt nach tatsächlichen Test-Bedürfnissen.

Besserer erster Zug: das offensichtliche Totgewicht entfernen

Das sicherste Simulator-Cleanup beginnt oft mit nicht verfügbaren Geräten.

Apple dokumentiert das direkt in simctl delete: der unavailable-Alias löscht Geräte, die vom aktuellen Xcode SDK nicht unterstützt werden.

xcrun simctl delete unavailable

Das ist keine Universallösung, aber einer der saubersten ersten Durchgänge, weil es Geräte trifft, die bereits als nicht unterstützt durch deinen aktuellen SDK-Kontext markiert sind.

Simulator-Daten aufräumen ohne dein Dev-Environment zu zerstören

Hier nutzen Entwickler oft das falsche Werkzeug.

Wenn dein Problem veraltete App-Daten oder aufgeblähter Gerätzustand in Simulatoren ist, musst du vielleicht gar keine Laufzeiten löschen. Du musst eventuell nur die Simulator-Geräte zurücksetzen.

Apples simctl erase-Hilfe definiert erase als das Löschen der Inhalte und Einstellungen eines Geräts:

xcrun simctl erase <device>

Das ist eine Reset-Operation, keine Laufzeit-Entfernungs-Operation.

Wofür erase gut ist

• App-Zustand in einem Simulator leeren;
• Testumgebungen zurücksetzen;
• aufgeblähte Device-Level-Inhalte entfernen, ohne das Laufzeit-Image selbst zu löschen;
• den Geräte-Workflow behalten, aber den angesammelten Zustand abwerfen.

Wofür erase nicht gedacht ist

• kein Laufzeit-Cleanup-Befehl;
• kein DerivedData-Cleanup-Befehl;
• kein guter Ersatz für die Überprüfung, welche Geräte und Laufzeiten du tatsächlich noch brauchst.

Diese Unterscheidung ist die ganze Simulator-Cleanup-Geschichte: ein Gerät zurücksetzen, ein Gerät löschen und eine Laufzeit löschen sind drei verschiedene Entscheidungen.

Wie du Simulator-Speicher zukünftig verwaltest

Das praktische Ziel ist nicht „Simulatoren niemals wachsen lassen”. Das Ziel ist „Simulator-Speicher aufhören zu lassen, unsichtbar zu werden”.

Nutze einen Review-Rhythmus wie diesen:

1. Liste Geräte und Laufzeiten nach größeren Xcode- oder SDK-Wechseln auf.
2. Lösche nicht verfügbare Geräte, wenn sie auftauchen.
3. Setze veraltete Simulator-Geräte zurück, wenn das Problem Gerätzustand ist, nicht Laufzeit-Bestand.
4. Überprüfe die Laufzeitnutzung, bevor du eine OS-Version komplett entfernst.
5. Vergleiche CoreSimulator, DerivedData und Archives zusammen, wenn Apple-seitiger Speicher zu steigen beginnt.

Das hält die Cleanup-Entscheidung an der Schicht ausgerichtet, die tatsächlich teuer ist.

Ein besseres mentales Modell für Apple-seitigen Speicher

• DerivedData ist hauptsächlich generierte Build-Ausgabe.
• Archives bewahren Lieferartefakte und Build-Historie.
• CoreSimulator mischt Laufzeit-Support mit Simulator-Gerätzustand.
• das sicherste Cleanup hängt davon ab, welche Schicht groß ist, nicht nur welcher Ordner sichtbar.

Sobald du in Schichten denkst, wird Simulator-Cleanup viel weniger chaotisch.

Warum Dev Cleanup besser funktioniert, wenn er ökosystembewusst bleibt

Wenn du nur den Finder nutzt, sieht ein 20-GB- oder 30-GB-Apple-seitiger Ordner wie ein offensichtliches Cleanup-Ziel aus. Ist er nicht.

Ein Dateibrowser kann dir zeigen, dass CoreSimulator groß ist. Er kann dir nicht sagen, ob der echte zurückgewinnbare Platz aus:

• nicht unterstützten Geräten besteht;
• zurücksetzbaren Simulator-Inhalten;
• Laufzeiten, die du nicht mehr brauchst;
• oder einem benachbarten Xcode-Profil, das nur zufällig in der Nähe liegt.

Deshalb gehört Simulator-Cleanup in Dev Cleanup, nicht in generisches Datei-Cleanup.

Wenn dein echtes Problem „Simulatoren plus DerivedData plus anderer Apple-Dev-Speicher” ist, ist dieser breitere profilbewusste Workflow viel nützlicher, als einen Ordnerpfad nach dem anderen zu jagen.

Fazit

Wenn Xcode Simulator Platz auf deinem Mac einnimmt, behandle CoreSimulator nicht wie einen wegwerfbaren Cache-Bucket.

Überprüfe zuerst Geräte und Laufzeiten. Lösche nicht verfügbare Geräte als sauberen ersten Durchgang, nutze erase nur, wenn du Simulator-Inhalte und Einstellungen zurücksetzen willst, und entferne Laufzeiten nur, wenn du diese OS-Version wirklich nicht mehr brauchst.

Das ist der sicherere Cleanup-Pfad: trenne Laufzeit-Images von Gerätzustand, trenne Simulator-Speicher von DerivedData und halte Apple-seitiges Cleanup an tatsächlichen Test-Bedürfnissen ausgerichtet statt blindes Ordner-Löschen.