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 ist CoreSimulator auf dem Mac?

CoreSimulator ist der von Apple verwaltete Ordner, in dem Xcode die Simulator-Laufzeiten und die Simulator-Geräte ablegt, mit denen du iOS-, iPadOS-, watchOS- und tvOS-Apps baust und testest. Auf den meisten Macs liegt er unter ~/Library/Developer/CoreSimulator und wächst, sobald du Laufzeiten hinzufügst, Geräte anlegst und App-Daten darin ansammelst.

Es ist kein gewöhnlicher Cache. Der Ordner mischt zwei Dinge: Laufzeit-Images, auf die du noch angewiesen sein kannst, und Gerätezustand, den du in vielen Fällen zurücksetzen oder entfernen kannst. Deshalb hat “CoreSimulator auf dem Mac ist riesig” mehr als eine Antwort.

Kann ich den CoreSimulator-Ordner löschen?

Nicht blind als einen Ordner. Den größten Teil des Platzes bekommst du zurück, indem du die richtige Ebene leerst statt den ganzen Pfad zu entfernen.

Wenn du ~/Library/Developer/CoreSimulator von Hand komplett löschst, muss Xcode den Simulator-Zustand neu aufbauen, und Laufzeiten, die du noch brauchst, sind weg. Der sichere Weg führt über Apples eigenes simctl:

• Geräte, die das aktuelle SDK nicht mehr unterstützt, mit xcrun simctl delete unavailable entfernen;
• Inhalte und Einstellungen eines Geräts mit xcrun simctl erase <device> zurücksetzen, wenn aufgeblähter App-Zustand das Problem ist;
• eine Laufzeit mit xcrun simctl runtime delete nur dann löschen, wenn du diese OS-Version nicht mehr testest.

Du gewinnst CoreSimulator-Platz Ebene für Ebene zurück, nicht durch das Löschen des Ordners in der Hoffnung, dass Xcode sich erholt.

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.

Simulatoren in Xcode löschen: Schritt für Schritt

Wenn du Simulatoren in Xcode löschen statt nur ansehen willst, hast du zwei sichere Wege: die Xcode-Oberfläche und die Kommandozeile mit simctl. Beide entfernen alte Simulatoren, ohne Laufzeiten anzutasten, die du noch brauchst.

In der Xcode-App:

1. Öffne Xcode und gehe zu Window → Devices and Simulators.
2. Wähle den Tab Simulators.
3. Klicke mit der rechten Maustaste auf einen Simulator, den du nicht mehr brauchst, und wähle Delete, oder nutze Delete Unavailable Simulators für Geräte, die das aktuelle SDK nicht mehr unterstützt.

Auf der Kommandozeile:

# zuerst alles auflisten
xcrun simctl list devices

# alle Geräte löschen, die das aktuelle SDK als unavailable markiert
xcrun simctl delete unavailable

# ein bestimmtes Gerät über seine UDID löschen
xcrun simctl delete <device-UDID>

Nicht verfügbare Simulatoren zu löschen ist der sauberste erste Durchgang, weil dabei nur Geräte verschwinden, die Apple bereits als nicht unterstützt markiert. Löschst du ein einzelnes Gerät, verschwindet diese Simulator-Instanz, das Laufzeit-Image bleibt liegen, und du kannst das Gerät später neu anlegen.

Wenn du alte Simulatoren aufräumst, um Platz zu gewinnen, fang hier an, bevor du Laufzeiten anfasst: ein gelöschtes Gerät ist schnell wiederhergestellt, eine gelöschte Laufzeit ist die schwerere Entscheidung.

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.

Wo CoreSimulator auf der Festplatte liegt

Beim Prüfen des Simulator-Speichers zählen zwei Pfade.

~/Library/Developer/CoreSimulator/Devices enthält die Simulator-Geräte, die du angelegt hast. Jedes Gerät ist ein Ordner mit seiner UDID als Namen, und data/ darin trägt installierte Apps, App-Daten und Einstellungen. Genau diesen Teil setzt simctl erase zurück und entfernt simctl delete.

Der Ordner /Library/Developer/CoreSimulator auf Systemebene trägt die Laufzeit-Seite. Je nach Xcode-Version liegen die Laufzeit-Images als .simruntime-Bundles unter Profiles/Runtimes, oder Xcode verwaltet sie als ladbare Laufzeiten, die xcrun simctl runtime list ausgibt. Was du dort entfernst, betrifft jedes Benutzerkonto auf dem Mac, also behandle es als die schwerere Entscheidung.

du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh /Library/Developer/CoreSimulator
xcrun simctl runtime list

Dominiert Devices, liegt dein Problem beim angesammelten Gerätezustand und bei Geräten, die das aktuelle SDK nicht mehr unterstützt. Dominiert der Ordner auf Systemebene, liegt es an den Laufzeit-Images.

Kann man CoreSimulator auf eine externe Festplatte verschieben?

Diese Frage kommt auf, wenn die interne Platte klein ist und der Simulator-Ordner die 40 GB überschreitet. Apple liefert keine unterstützte Einstellung dafür, deshalb greifen Entwickler zum Symlink: ~/Library/Developer/CoreSimulator auf das externe Volume kopieren, die Kopie prüfen, das Original entfernen und den alten Pfad auf den neuen verlinken.

Worauf du dich einlässt:

• Xcode kann keine Simulatoren starten, wenn das Laufwerk nicht eingehängt ist, weil der Pfad fehlt;
• auf einer bus-versorgten USB-Platte starten Simulatoren langsamer als auf der internen SSD;
• ein Xcode- oder SDK-Update kann Teile der Ordnerstruktur am ursprünglichen Pfad neu anlegen;
• Backup und Rechte verhalten sich auf externen Volumes anders.

Prüfe den zurückgewinnbaren Platz, bevor du den ganzen Ordner verschiebst. Nicht verfügbare Geräte und Laufzeiten, die du nicht mehr testest, geben oft mehr frei als der Umzug bringt, und das Setup bleibt so, wie Apple es unterstützt.

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.