Levo-Anleitungen · Entwickler: Apple

Warum ist Xcode so groß? Was du gefahrlos löschen kannst

Die Xcode-App ist nur ein Teil davon. Das eigentliche Gewicht liegt in ~/Library/Developer: Build-Daten, Simulatoren, geladene Runtimes und Debug-Symbole von jedem Gerät, das du angeschlossen hattest. Fast alles davon kommt wieder, du kannst es also leeren. Die zwei Ausnahmen sind Archive und Daten in Simulatoren, die du noch nutzt.

So machst du es selbst

Miss zuerst die Ordner, damit du deine Zeit auf die großen verwendest:

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

1. Beende Xcode und lösch dann den Inhalt von DerivedData. Siehe DerivedData löschen.
2. Entfern Simulatoren und Runtimes, die du nicht nutzt, mit xcrun simctl oder in Xcode › Settings › Components. Siehe alte Simulatoren löschen.
3. Öffne iOS DeviceSupport und lösch die Ordner für iOS-Versionen, die deine Geräte nicht mehr verwenden. Siehe was DeviceSupport ist.
4. Leere die Paket-Caches mit den Befehlen aus SwiftPM- und CocoaPods-Caches.
5. Öffne Xcode › Window › Organizer › Archives und sieh dir an, was dort liegt. Archive sind die einzige Kopie des genauen Builds, den du an App Store Connect geschickt hast, und die dSYMs darin symbolisieren seine Absturzberichte. Lösch alte nur, wenn du diese Symbole anderswo hast.

Alte Xcode-Versionen in /Applications sind jeweils etwa 12 bis 15 GB groß. Lösch sie im Finder, schieb nicht den Developer-Ordner aus dem Weg.

Was es kostet, jedes davon zurückzuholen

Am billigsten zu verlieren ist DerivedData: ein langsamerer Build pro Projekt. Simulator-Runtimes kosten einen Download von mehreren Gigabyte und ein paar Minuten, behalte also nur die iOS-Versionen, die deine App unterstützt. Device Support kostet eine kurze Wartezeit, wenn du das nächste Mal ein iPhone anschließt.

Archive sind anders. Die dSYM-Dateien darin machen aus einem rohen Absturzbericht einer alten Version lesbare Zeilen. Lädst du dSYMs zum Release-Zeitpunkt in dein Crash-Tool hoch, ist das Archiv nur noch ein großes Zip, das du löschen kannst. Tust du das nicht, behalte das Archiv für jede Version, die noch im Umlauf ist.

Auch Xcodes eigene Updates sind eine stille Ursache. Jede neue Version, die neben der alten installiert wird, bringt 12 bis 15 GB mit, und Xcode-Betas kommen obendrauf. Lösch alte Kopien im Finder, leere den Papierkorb, und der Platz ist sofort wieder da. Ist ein Mac fast voll, tu das vor allem anderen, denn eine volle Festplatte lässt Indizierung und Builds von Xcode auf seltsame Weise scheitern.

So macht es Levo

Levo listet Xcode-Build-Daten, Device-Support-Dateien, Simulatoren und Paket-Caches als eigene Zeilen mit Größen, du siehst also, welches der obigen deine 80 GB sind. Build-Daten und Caches werden zuerst angehakt, wenn das Projekt alt oder verschwunden ist. Alte Xcode-Versionen und Archive werden aufgelistet, aber nie für dich angehakt.

Levo entfernt Simulatoren mit dem eigenen simctl von Xcode und überspringt Build-Daten, solange Xcode, xcodebuild oder ein gestarteter Simulator läuft. Siehe Levo für iOS- und Mac-Entwickler.

FAQ

Warum belegt Xcode 100 GB?

Wegen dem, was es außerhalb der App speichert: Build-Daten pro Projekt, Simulatoren und ihre Runtimes, Debug-Symbole für jedes angeschlossene Gerät und Archive. Die App selbst ist etwa 15 GB groß.

Kann ich den Ordner Library/Developer von Xcode löschen?

Nicht den ganzen Ordner. Leere darin DerivedData, die CoreSimulator-Geräte und DeviceSupport, lass aber Archives und den Ordner UserData in Ruhe, der deine Tastenbelegungen und Themes enthält, außer du willst sie verlieren.

Macht das Löschen von DerivedData meine Projekte kaputt?

Nein. Dein Quellcode und die Projekteinstellungen liegen nicht darin. Der nächste Build ist langsamer, während Xcode neu baut und neu indiziert.

Ist es sicher, Simulator-Runtimes zu löschen?

Ja. Es sind Downloads, Xcode holt sie also erneut, wenn ein Projekt eine braucht. Wer ein Simulatorgerät löscht, löscht die App-Daten darin.