Zurück zum Blog

Ist es sicher, Xcode-Archive auf dem Mac zu löschen?

Was in ~/Library/Developer/Xcode/Archives liegt, warum die dSYMs darin für Crash-Reports zählen, welche Archive du löschen kannst und wie du sie in Xcode entfernst.

Veröffentlicht 25. Oktober 2026 Autor Vladimir Chemeris Lesezeit 5 Min. Lesezeit
XcodeArchivesDeveloper Cleanup

Die meisten Xcode-Archive kannst du gefahrlos löschen, und einige sind mehr wert, als ihre Größe vermuten lässt. Jedes Archiv ist ein Build, den du exportiert oder hochgeladen hast, und seine dSYMs enthalten die Symbole für genau diese Binärdatei. Lösche die Archive von Builds, die niemand ausführt. Behalte die Archive hinter jeder Version, die noch irgendwo installiert ist, es sei denn, dein Crash-Reporter oder App Store Connect hat ihre Symbole bereits.

Hauptregel: Behalte das Archiv jedes Builds, den noch jemand nutzt, und lösche den Rest im Organizer von Xcode statt im Terminal.

Kurzfassung

  1. Miss den Ordner mit du -sh ~/Library/Developer/Xcode/Archives/* | sort -h | tail.
  2. Öffne Xcode, dann Window, Organizer, Archives.
  3. Behalte den zuletzt veröffentlichten Build jeder App und jeden älteren Build, den deine Nutzer noch verwenden.
  4. Prüfe, ob dein Crash-Reporter oder App Store Connect die Symbole der Builds hat, die du löschen willst.
  5. Lösche Test-Exporte, ersetzte Uploads und abgelaufene TestFlight-Builds.
  6. Verschiebe Archive, bei denen du unsicher bist, auf ein externes Laufwerk, statt sie zu löschen.

Was in einem Xcode-Archiv steckt

Xcode schreibt jedes Mal ein Archiv, wenn du Product, Archive oder xcodebuild archive ausführst. Es legt die Archive in ~/Library/Developer/Xcode/Archives ab, einen Ordner pro Tag, und benennt jedes Bundle nach Scheme und Uhrzeit, zum Beispiel MyApp 21.09.2026, 14.13.xcarchive.

Element im .xcarchiveWas es enthält
dSYMsDebug-Symbole für die App und ihre eingebetteten Frameworks
Productsdie gebaute App
Info.plistVersion, Build-Nummer und Erstellungsdatum
SignaturesSignatur-Metadaten

Ich habe den Ordner auf meinem Mac am 25. Oktober 2026 gemessen, mit macOS 27.0.1 und Xcode 27.1. Er enthielt 3,9 GB: 35 Archive von 11 Apps, alle zwischen dem 16. August und dem 24. Oktober entstanden. Ein typisches Archiv belegte etwa 165 MB, das größte 407 MB. In einem StorageRadar-Archiv belegte der Ordner dSYMs 84 MB und die App selbst 39 MB, die Symbole wogen also schwerer als das Produkt.

Warum die dSYMs zählen

Ein Crash-Report aus einem Release-Build listet Speicheradressen statt Funktionsnamen. Xcode und Crash-Reporting-Dienste übersetzen diese Adressen mit dem dSYM, dessen UUID zur abgestürzten Binärdatei passt. Zu welchem Build ein dSYM gehört, prüfst du so:

dwarfdump --uuid ~/Library/Developer/Xcode/Archives/2026-09-21/*.xcarchive/dSYMs/*.dSYM

Archivierst du denselben Commit erneut, bekommst du eine neue Binärdatei und in den meisten Setups eine neue UUID. Deshalb lässt sich ein gelöschtes Archiv für das Crash-Reporting nicht wiederherstellen: Die Reports des alten Builds brauchen das alte dSYM.

Zwei Stellen können eine zweite Kopie halten:

  • App Store Connect. Wenn du mit der Option verteilst, die Symbole deiner App hochzuladen, symbolisiert Apple die Crash-Reports, die du im Organizer von Xcode siehst.
  • Dein Crash-Reporter. Dienste wie Sentry und Firebase Crashlytics laden dSYMs während des Builds hoch, wenn das Projekt dafür eingerichtet ist, und bewahren sie auf ihrer Seite auf.

Trifft keins von beidem auf einen Build zu, ist sein Archiv die einzige Kopie seiner Symbole.

Welche Archive du löschen kannst

Ohne langes Nachdenken löschen:

  • Archive lokaler oder Ad-hoc-Exporte, die du gemacht hast, um etwas zu testen;
  • Builds, die du hochgeladen und dann durch einen neueren Build derselben Version ersetzt hast;
  • TestFlight-Builds, die älter als 90 Tage sind, denn TestFlight lässt Builds nach dieser Zeit ablaufen.

Behalten:

  • das Archiv des Builds, der im App Store live ist, und des vorherigen oder der zwei vorherigen, wenn deine Nutzer langsam aktualisieren;
  • Archive von Builds, die du außerhalb des App Store verteilst, weil du genau diesen Build eventuell erneut exportieren oder notarisieren musst;
  • alles ohne zweite Kopie seiner Symbole, solange dafür noch Crash-Reports eintreffen.

Wie du Archive löschst

In Xcode. Öffne Window, Organizer und wähle Archives. Wähle links eine App, markiere ein oder mehrere Archive und lösche sie über das Kontextmenü. Der Organizer liest den Archives-Ordner, damit verschwinden die Bundles also auch von der Platte.

Im Finder. Führe open ~/Library/Developer/Xcode/Archives aus und verschiebe ganze Datumsordner in den Papierkorb. Der Organizer listet dann nicht mehr auf, was du verschoben hast.

Auf ein externes Laufwerk. Kopiere alte Datumsordner auf eine externe Platte und lösche sie dann vom Mac. Xcode braucht die Archive nicht auf der internen Platte, um weiter zu funktionieren, und du kannst eins zurückkopieren, falls je ein Crash-Report für einen alten Build auftaucht.

Unter Xcode Settings, Locations kannst du Xcode auch einen anderen Ordner für Archive zuweisen.

Archives und DerivedData im Vergleich

Diese beiden Ordner liegen nebeneinander in ~/Library/Developer/Xcode und verhalten sich gegensätzlich. DerivedData ist Build-Ausgabe, die Xcode beim nächsten Build neu erzeugt, Löschen kostet dich also einen langsameren Build. Archives sind Aufzeichnungen von Builds, die du ausgeliefert hast, und nichts erzeugt sie neu. Räume DerivedData ohne Bedenken auf und prüfe Archives einzeln.

Fazit

Xcode-Archive zu löschen ist sicher für Builds, die niemand ausführt, und teuer für Builds, die noch jemand nutzt. Miss den Ordner, öffne den Organizer, behalte das Archiv hinter jeder Live-Version und prüfe, wo die Symbole älterer Builds liegen, bevor du sie löschst. Im Zweifel kostet ein externes Laufwerk weniger als ein Crash-Report, den du nicht lesen kannst.

Über den Autor

Vladimir Chemeris

Gründer, StorageRadar

Vladimir Chemeris entwickelt StorageRadar, eine datenschutzfreundliche macOS-App für Speicheranalyse mit Fokus auf Review-First-Cleanup, Entwickler-Speicher und Vorher-Nachher-Vergleiche.

Häufig gestellte Fragen

Ist es sicher, Xcode-Archive zu löschen?

Ja, bei Archiven von Builds, die niemand mehr ausführt: Test-Exporte, ersetzte Uploads, abgelaufene TestFlight-Builds. Behalte das Archiv jedes Builds, der noch irgendwo installiert ist, denn seine dSYMs machen aus den Crash-Reports dieses Builds lesbare Stack Traces.

Entfernt das Löschen eines Xcode-Archivs meine App aus dem App Store?

Nein. App Store Connect behält den Build, den du hochgeladen hast. Das Archiv ist deine lokale Kopie dieses Builds und seiner Debug-Symbole.

Kann ich ein gelöschtes Archiv neu erzeugen?

Du kannst denselben Commit erneut archivieren, aber in den meisten Setups bekommt die neue Binärdatei eine neue UUID. Die alten Crash-Reports brauchen das dSYM mit der alten UUID und bleiben deshalb unsymbolisiert, sofern dieses dSYM nicht anderswo liegt, etwa in App Store Connect oder bei deinem Crash-Reporter.

Wo speichert Xcode Archive auf dem Mac?

In ~/Library/Developer/Xcode/Archives, in einem Ordner pro Tag mit Namen wie 2026-10-24. Den Pfad zeigt Xcode unter Settings, Locations. Jedes Archiv ist ein .xcarchive-Bundle mit der App, ihren dSYMs und einer Info.plist.

Wie viel Platz belegen Xcode-Archive?

Das hängt von der App ab. Auf meinem Mac belegte ein typisches Archiv etwa 165 MB, das größte 407 MB. Fünfunddreißig davon summierten sich in zehn Wochen auf 3,9 GB, weil jeder Upload eines zurücklässt.

Quellen & Referenzen

Sieh Archives neben jedem anderen Entwickler-Ordner.

Dev Cleanup in StorageRadar misst Archives, DerivedData, CoreSimulator und Paket-Caches nebeneinander, kennzeichnet jeden Ordner nach Risiko und führt einen Dry Run aus, bevor etwas entfernt wird.