Den Swift-Package-Manager-Cache sicher leeren

SwiftPM hat mehr als einen Cache

Swift Package Manager speichert neu erzeugbare Daten in mehreren Bereichen. Das .build-Verzeichnis eines Kommandozeilenpakets enthält Checkouts, Repositories, Build-Ausgaben und Workspace-Zustand; daneben gibt es einen gemeinsamen Repository-Cache für mehrere Projekte.

Xcode fügt eine weitere Ebene hinzu. Bei Swift Packages in einer App können Checkouts und kompilierte Ergebnisse zum DerivedData des Projekts gehören. Ein Fehler nur in Xcode braucht daher eine andere Bereinigung als derselbe Code mit swift build.

Beginne mit dem kleinsten Umfang, der das Problem erklärt. Ein fehlgeschlagener Build rechtfertigt nicht, den globalen Cache für alle Repositories zu verwerfen.

Den richtigen SwiftPM-Befehl wählen

swift package clean entfernt Build-Artefakte des aktuellen Pakets. Das ist die erste Wahl bei veralteten Kompilaten, unerklärlichen Linkfehlern oder einer auf ein Repository begrenzten Speicherbereinigung.

swift package reset setzt den vollständigen Cache und das Build-Verzeichnis des aktuellen Pakets zurück. Der Umfang ist größer als bei clean; lokale Abhängigkeiten und Workspace-Zustand müssen vorbereitet werden.

swift package purge-cache leert den globalen SwiftPM-Repository-Cache. Danach können mehrere Projekte Netzwerkzugriff und längere Auflösung benötigen. Nutze ihn nur bei gemessener Übergröße oder Beschädigung.

1. Committe oder stash deine Änderungen und prüfe Package.swift sowie Package.resolved.
2. Führe im Paketstamm swift package clean aus und wiederhole den Build.
3. Bleibt der lokale Zustand inkonsistent, nutze swift package reset und löse neu auf.
4. Nutze swift package purge-cache nur bei bestätigtem Problem des gemeinsamen Caches.
5. Prüfe Abhängigkeitsgraph und Build, bevor du Xcode DerivedData entfernst.

Verfügbare Unterbefehle hängen von deiner Swift-Toolchain ab. Prüfe sie mit swift package --help.

Package.resolved behalten, solange du keine Versionen ändern willst

Package.resolved ist Auflösungszustand, kein Download-Cache. In Apps sorgt die Versionskontrolle dafür, dass Team und CI dieselben Versionen verwenden. Nach dem Löschen kann SwiftPM andere von Package.swift erlaubte Versionen wählen.

Für eine bewusst neue Auflösung kann das sinnvoll sein, aber dann änderst du das Experiment. Bei einer reinen Speicher- oder Build-Bereinigung bleibt die Datei erhalten.

Package.swift, Sources, Tests, Plugins und lokale Pfadabhängigkeiten sind Quellinhalt. .build lässt sich neu erzeugen; geschriebene Dateien nicht.

Swift Packages in Xcode bereinigen

Wenn deine Xcode-Version File > Packages > Reset Package Caches anbietet, beginne dort und stelle den Graphen mit Resolve Package Versions wieder her. Menünamen können sich zwischen Xcode-Versionen ändern.

Betrifft das Problem kompilierte Paketergebnisse, entferne nur das DerivedData des betroffenen Projekts über Xcode Settings > Locations. Aktive andere Projekte behalten ihren warmen Cache.

Bei mehreren Xcode-Installationen startest du vor der Auflösung die vorgesehene Version, damit richtige Toolchain und Plattformunterstützung gelten.

Vor dem Löschen diagnostizieren

Bei Speicherdruck misst du .build-Ordner und gemeinsamen Cache. Artefakte aufgegebener Repositories sind oft besser als ein globaler Cache, der aktive Arbeit beschleunigt.

Bei Buildfehlern sicherst du zuerst die Meldung. Authentifizierung, Git-Ausfall, ungültiges Manifest, inkompatible Toolchain oder Prüfsumme werden durch gelöschte Downloads nicht behoben.

Prüfe danach mit swift package show-dependencies oder dem Xcode-Graphen die Auflösung und führe relevante Tests aus.

Entwickler-Mac und CI unterschiedlich betreiben

Auf dem Entwickler-Mac entfernst du lokale Ergebnisse inaktiver Repositories selektiv und lässt den globalen Cache bestehen, solange er Zeit spart. Persistente CI-Runner brauchen Größenlimit und Cache-Schlüssel mit Toolchain und Auflösungszustand.

Mache purge-cache nicht zum Ritual vor jedem Build. Es vernichtet Wiederverwendung und erhöht das Risiko von Netzwerkausfällen und Limits.

Dokumentiere, ob clean in Repository A oder purge des globalen Caches ausgeführt wurde. Die Auswirkungen sind verschieden.

Den umliegenden Entwicklerspeicher mit AskClean finden

AskClean trennt projektbezogenes DerivedData, Repository-Artefakte, deklarierte Entwickler-Caches, Simulatoren und große unbekannte Ordner und erklärt ihre Wiederherstellungskosten.

Für SwiftPM selbst bleiben die offiziellen Swift-Befehle maßgeblich. AskClean findet den Speicherverursacher, ersetzt aber keinen präzisen Paketmanagerbefehl durch eine pauschale Löschung.

Wirkungsbereich der SwiftPM-Befehle

Wähle nach Umfang und Wiederherstellungskosten, nicht den aggressivsten Befehl.

FAQ