Alte Xcode Archives löschen, ohne Crash-Symbole zu verlieren

Warum Archives nicht dasselbe wie DerivedData sind

Mit Product > Archive erzeugt Xcode einen verteilbaren Build als .xcarchive-Paket. Standardmäßig liegen diese Pakete nach Datum sortiert unter ~/Library/Developer/Xcode/Archives und erscheinen im Organizer. Bei einer lange gepflegten App sammeln sich Release Candidates, TestFlight- und Produktions-Builds über viele Versionen an.

DerivedData lässt sich aus dem Quellcode neu erzeugen. Ein Archive kann dagegen genau das Binärprogramm, die Build-Metadaten und das dSYM dieses Releases enthalten. Laut Apple ist ein dSYM über seine UUID an eine bestimmte Binärdatei gebunden. Ein neuer Build desselben Commits ersetzt diese Symbole nicht.

Darum ist der Löschpreis ein anderer. Nach dem Löschen von DerivedData dauern Build und Indizierung einmal länger. Nach dem falschen Löschen eines Archives lassen sich Adressen in einem Crash-Stack möglicherweise nie wieder in Funktionsnamen und Quellzeilen übersetzen.

Vor dem Löschen eine Behalten-Liste erstellen

Beginne in Window > Organizer > Archives und nicht mit Datumsordnern im Finder. Wähle die App und prüfe Version, Buildnummer, Erstellungsdatum und Verteilungsstatus. Dieser Kontext ist zuverlässiger als ein Ordner, der nur alt aussieht.

Behalte jede aktuell im App Store verfügbare Version, aktive TestFlight-Builds, noch installierte Enterprise- oder Ad-Hoc-Builds und Releases innerhalb deines Crash-Analysefensters. Auch ein verifizierter Referenz-Build für erneuten Export, Signaturprüfung oder Incident Response gehört auf die Liste.

Ein erfolgreicher Upload macht das lokale Archive nicht automatisch entbehrlich. Je nach Plattform und Einstellung hat Apple Symbole erhalten; Apples Debugging-Dokumentation empfiehlt trotzdem, das Archiv jedes verteilten Builds aufzubewahren. Es verbindet Binärdatei, dSYM, Version und Buildnummer eindeutig.

1. Öffne Window > Organizer und wähle Archives.
2. Notiere Version und Buildnummer aller noch eingesetzten Produktions-, TestFlight-, Enterprise- und Ad-Hoc-Builds.
3. Prüfe erforderliche Symbol-Uploads und kopiere unersetzliche Archive bei Bedarf in gesicherten Speicher.
4. Markiere nur ersetzte Release Candidates, aufgegebene interne Builds und Releases außerhalb des Analysezeitraums.
5. Lösche einzeln im Organizer und leere den Papierkorb erst nach der Kontrolle.

Das Alter allein ist keine sichere Regel. Ein älterer Produktions-Build kann lange nach einem Update auf Kundengeräten installiert bleiben.

Den Archivordner messen, ohne etwas zu ändern

Öffne mit Command-Shift-G den Pfad ~/Library/Developer/Xcode/Archives im Finder, aktiviere in der Listenansicht „Alle Größen berechnen“ und sortiere nach Größe. Das verändert keine Datei.

Im Terminal zeigt du -sh ~/Library/Developer/Xcode/Archives die Summe; du -sh ~/Library/Developer/Xcode/Archives/* misst die Datumsordner. Beide Befehle sind nur lesend.

Ein .xcarchive ist ein Paket. Du kannst den Paketinhalt einer Kopie untersuchen, solltest aber niemals einzelne Dateien aus dem Original entfernen. Ein unvollständiges Archive kann sichtbar bleiben, aber Export und Symbolikation verlieren.

Der sicherste Löschablauf

Der Organizer ist die erste Wahl, weil App, Version und Buildnummer direkt neben der Aktion stehen. Lösche nur ein Archive, dessen Ausmusterung bestätigt ist.

Nutze den Finder nur, wenn der Organizer ein sehr altes oder beschädigtes Paket nicht lesen kann. Gleiche dessen Info.plist mit deiner Prüfung ab und verschiebe genau dieses .xcarchive in den Papierkorb. Lösche nie einen ganzen Datumsordner nur wegen seines Namens.

Lass den Papierkorb zunächst unangetastet. Öffne den Organizer erneut, prüfe erforderliche Exporte und teste bei kritischen Symbolen einen repräsentativen Crashbericht. Eine permanente Terminal-Löschung macht die Entscheidung nicht richtiger.

Eine Archivaufbewahrung, die nicht endlos wächst

Richte die Regel am Release-Status aus: alle verteilten Builds behalten, ersetzte Produktionsversionen bis zum Ende der Crashannahme, Enterprise-Builds bis zum Ablauf ihrer Installationen und Meilensteine gemäß Rechts-, Audit- oder Incident-Vorgaben.

Dokumentiere Speicherort, dSYM-Upload, Zugriffsberechtigung und Löschzeitpunkt in der Release-Checkliste. Teste bei externem oder Cloud-Speicher die Wiederherstellung und den Export statt nur die Existenz der Kopie.

Eine kurze Prüfung nach großen Releases ist sicherer als eine Panikaktion bei voller Startdisk. Schaffe im Notfall zuerst mit DerivedData und anderen neu erzeugbaren Daten Platz.

Wie AskClean Archives behandelt

AskClean kennzeichnet Xcode Archives nicht als gewöhnlichen, neu erzeugbaren Cache. Es listet einzelne .xcarchive-Pakete auf und zeigt die irreversiblen Kosten, statt den ganzen Ordner als Alles-oder-nichts-Aktion anzubieten.

Die Entscheidung bleibt bei dir. AskClean kann Größe und Pfad zeigen und eine bestätigte Datei in den Papierkorb verschieben, kennt aber weder dein Supportfenster noch kann es ein verlorenes dSYM ersetzen.

Löschgrenze: neu erzeugbar oder unersetzlich

Bewerte zuerst die Wiederherstellungskosten, dann Alter und Größe.

FAQ