Xcode Archives löschen? So entfernst du alte Builds sicher

Warum sich Xcode Archives von DerivedData unterscheiden

Ein Archiv ist das Ergebnis von Product > Archive: ein verteilbarer Build, aufbewahrt als .xcarchive-Paket. Standardmäßig legt Xcode diese Pakete in Datumsordnern unter ~/Library/Developer/Xcode/Archives ab und zeigt sie im Organizer an. Bei einer App, die du lange pflegst, sammeln sich viele Kopien an – Release Candidates, TestFlight-Uploads und Produktionsversionen.

Anders als DerivedData ist ein Archiv nicht bloß ein Cache, der Builds beschleunigt. Es kann genau die App-Binärdatei, die Build-Metadaten und die dSYM-Dateien dieses Builds enthalten. Laut Apple ist ein dSYM über seine UUID an eine bestimmte Binärdatei gebunden. Baust du denselben Quellcode später erneut, entsteht keine austauschbare Symboldatei, weil die neue Binärdatei andere Kennungen erhält.

Das ändert die Regel fürs Aufräumen. DerivedData lässt sich neu erzeugen – der Preis ist ein langsamerer erster Build. Ein gelöschtes Archiv lässt sich womöglich nie wieder exakt rekonstruieren. Kommt für diese Binärdatei ein Absturzbericht herein und du hast die passenden Symbole nicht mehr, bleiben die Stack-Frames womöglich Speicheradressen statt lesbarer Funktionsnamen und Quellcodestellen.

Vor dem Löschen: erst prüfen, was bleiben muss

Beginne in Xcode, nicht im Finder. Öffne Window > Organizer, wähle Archives und die betreffende App und prüfe für jeden Eintrag Version, Build-Nummer, Erstellungsdatum und Verteilungsstatus. Der Organizer gibt einem Archiv Kontext, den ein Ordnername mit Datum nicht liefert.

Erstelle zuerst eine Behalten-Liste, dann eine Löschliste. Behalte die Archive aller aktuell verfügbaren Versionen, aller aktiven TestFlight-Builds, aller noch installierten Enterprise- oder Ad-hoc-Builds und aller Releases, deren Absturzberichte du womöglich noch untersuchst. Behalte außerdem ein bewährtes Release, wenn dein Team auf dessen exportierte Binärdatei, den Notarisierungsverlauf oder die Signaturnachweise angewiesen ist.

Ein erfolgreicher Upload macht dein lokales Archiv nicht automatisch entbehrlich. Je nach Plattform und Upload-Einstellungen erhält Apple womöglich die Symbole; Apples Anleitung zum Debugging empfiehlt trotzdem, das Archiv jedes verteilten Builds aufzubewahren. Dein lokales Archiv ist außerdem der klarste Beleg dafür, welche Binärdatei, welches dSYM, welche Version, Build-Nummer und welcher Export zusammengehören.

1. Öffne Window > Organizer und wähle Archives.
2. Wähle die App und notiere Version und Build-Nummer aller Produktions-, TestFlight-, Enterprise- und Ad-hoc-Builds, die noch im Einsatz sind.
3. Prüfe, ob die benötigten Symbole – wo vorgesehen – hochgeladen wurden, und kopiere unersetzliche Archive in gesicherten Speicher, wenn deine Aufbewahrungsregeln das verlangen.
4. Markiere als Löschkandidaten nur ersetzte Release Candidates, aufgegebene interne Builds und ausgemusterte Versionen außerhalb deines Zeitfensters für Absturzanalysen.
5. Lösche die Kandidaten einzeln im Organizer und prüfe, ob die erwarteten Einträge noch da sind, bevor du den Papierkorb leerst.

Das Datum allein ist keine sichere Aufbewahrungsregel. Ein älterer Produktions-Build kann noch lange nach dem Erscheinen einer neueren Version auf Kundengeräten installiert sein.

Den Archivordner messen, ohne etwas zu ändern

Geht es dir um Speicherplatz, miss zuerst. Drücke im Finder Umschalt-Befehl-G („Gehe zu Ordner“) und öffne ~/Library/Developer/Xcode/Archives. Wechsle in die Listendarstellung, aktiviere in den Darstellungsoptionen „Alle Größen berechnen“ und sortiere nach Größe. Das ändert nichts und macht ungewöhnlich große Archive sichtbar.

Im Terminal zeigt du -sh ~/Library/Developer/Xcode/Archives die Gesamtgröße. Für die einzelnen Datumsordner führst du du -sh ~/Library/Developer/Xcode/Archives/* aus und sortierst die Ausgabe selbst. Beide Befehle messen nur und löschen nichts.

Ein Archiv ist ein Paket, das der Finder normalerweise als ein einzelnes Objekt zeigt. Um seine Größe zu untersuchen, kannst du bei einer Kopie per Rechtsklick „Paketinhalt zeigen“ wählen – bearbeite aber keine Dateien im Original. Entfernst du einzelne Dateien daraus, bleibt womöglich ein Archiv zurück, das zwar noch da ist, sich aber nicht mehr korrekt exportieren oder symbolisieren lässt.

Der sicherste Löschablauf

Der Organizer ist der bevorzugte Weg, weil App, Version und Build-Nummer direkt neben der Aktion stehen. Wähle ein Archiv, dessen Ausmusterung feststeht, und nutze „Delete“. Xcode entfernt das Archivpaket; je nach macOS- und Xcode-Version musst du den Vorgang noch bestätigen.

Der Finder hilft, wenn der Organizer ein altes oder beschädigtes Paket nicht öffnen kann. Wechsle in den Ordner Archives, bestimme das exakte .xcarchive, indem du die Metadaten in seiner Info.plist mit deiner Prüfliste abgleichst, und lege genau dieses eine Paket in den Papierkorb. Lösche keinen ganzen Datumsordner, nur weil sein Name alt ist.

Leere den Papierkorb erst, wenn du den Organizer erneut geöffnet, jeden noch benötigten Build exportiert und – falls Symbole geschäftskritisch sind – einen repräsentativen Absturzbericht symbolisiert hast. Der Papierkorb verschafft dir ein kurzes Zeitfenster für die Wiederherstellung. Endgültiges Löschen im Terminal nimmt dir diesen Puffer, ohne das Aufräumen richtiger zu machen.

Archive aufbewahren, ohne dass der Ordner endlos wächst

Eine praktikable Regel richtet sich nach dem Release-Status, nicht nach einem willkürlichen Dateialter: Behalte alle aktuell verteilten Builds, ersetzte Produktions-Builds für den Zeitraum, in dem du noch Absturzberichte annimmst, Enterprise-Builds, bis ihre Installationen ablaufen, und Meilenstein-Releases, die Rechts-, Support- oder Incident-Response-Vorgaben verlangen.

Im Team gehört die Aufbewahrung ausdrücklich in die Release-Checkliste: wo Archive liegen, ob dSYMs hochgeladen wurden, wer sie abrufen kann und ab wann ein Build gelöscht werden darf. Ziehen Archive auf externen oder Cloud-Speicher um, teste die Wiederherstellung, statt anzunehmen, dass ein kopiertes Paket nutzbar ist.

Sieh dir den Ordner nach großen Release-Zyklen wieder an. Zehn Minuten Prüfung pro Quartal sind sicherer als eine Panik-Löschaktion, wenn das Startvolume voll ist. Für schnellen, risikoarmen Platz leerst du zuerst DerivedData und veraltete Simulatordaten; Archive prüfst du erst, wenn der Mac genug Luft hat, um in Ruhe vorzugehen.

Wie AskClean Archives behandelt

AskClean stuft Xcode Archives bewusst nicht als gewöhnlichen, neu erzeugbaren Cache ein. Es durchsucht den Archives-Ordner, listet einzelne .xcarchive-Pakete auf und versieht sie mit einem Hinweis auf nicht umkehrbare Kosten. So prüfst du alte Builds einzeln, statt nur die Wahl zu haben, den ganzen Ordner zu löschen oder gar nichts.

Die Entscheidung bleibt bei dir. Die App zeigt, welches Archiv wie viel Platz belegt, und löscht einen Eintrag, den du freigibst, endgültig – dein Support-Zeitfenster für Produktions-Builds kennt sie aber nicht, und ein fehlendes dSYM kann sie nicht ersetzen. Diese Grenze ist gewollt: Speicherautomatisierung soll Release-Artefakte sichtbar machen, nicht stillschweigend entscheiden, dass sie keine Rolle mehr spielen.

Löschgrenze: neu erzeugbar oder unersetzlich

Stufe ein Artefakt zuerst nach seinen Wiederherstellungskosten ein, erst dann nach Alter oder Größe.

FAQ