Xcode volledig verwijderen van een Mac zonder projecten of dSYMs te verliezen
AskClean-team · Bijgewerkt 2026-09-01
Maak vóór een volledige Xcode-verwijdering een back-up van bronprojecten en bewaar Archives en dSYMs die nog nodig zijn voor uitgebrachte builds. Verplaats daarna de app naar de Prullenmand en controleer DerivedData, simulators, DeviceSupport en commandoregeltools afzonderlijk.

Bescherm niet-reproduceerbare gegevens vóór het verwijderen
Projectmappen zijn geen Xcode-restanten. Bescherm repositories, niet-gecommitte bestanden, lokale pakketten en assets. Bewaar Archives/dSYMs voor versies die nog in App Store, TestFlight of bij klanten draaien en nuttige Simulator-status.
- Stop eerst Xcode. DerivedData verwijderen terwijl Xcode draait kan de indexer in de war brengen, en bestanden die Xcode open heeft, worden mogelijk niet netjes verwijderd.
- Zoek de map op: open in Xcode Settings > Locations en klik op het pijltje naast het DerivedData-pad om hem in de Finder te tonen. Of druk in de Finder op Command-Shift-G en voer rechtstreeks ~/Library/Developer/Xcode/DerivedData in.
- Sorteer de projectsubmappen op grootte, selecteer de mappen die weg mogen (of Command-A voor allemaal) en verplaats ze naar de Prullenmand. Eerst naar de Prullenmand is de veiligere gewoonte — je herstelt direct als je je bedenkt.
- Liever via Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData verwijdert alles in één klap. Het is sneller dan de Finder bij hele grote mappen, maar lees eerst de opmerking hieronder.
- Open Xcode weer en bouw. Verwacht dat de eerste build van elk project merkbaar langer duurt en dat "Indexing" een tijdje in de activiteitenbalk staat — beide zijn eenmalige kosten.
Wees voorzichtig met rm -rf: het slaat de Prullenmand over en verwijdert definitief, zonder ongedaan maken. Typ het pad exact, gebruik hiervoor nooit sudo, en voel je je niet thuis in Terminal, dan doet de Finder-route hetzelfde werk omkeerbaar.
DerivedData verwijderen
Er zijn drie manieren, en ze komen op hetzelfde neer. Xcode's Clean Build Folder-commando (Product > Clean Build Folder, of Command-Shift-K) wist alleen de buildproducten van het geopende project — handig om een rare build te fixen, maar het zet nauwelijks zoden aan de dijk voor je schijfruimte. Wil je echt ruimte terugwinnen, verwijder dan de DerivedData-mappen zelf.
Per project verwijderen is de chirurgische optie: houd DerivedData voor de twee of drie projecten waar je dagelijks aan bouwt, en gooi de mappen van al het andere weg. Alles in één keer verwijderen is de snelle optie, en ook prima — je betaalt de prijs van een volledige rebuild dan alleen voor elk project tegelijk.
Verwijder de app via de oorspronkelijke installatiemethode
Sluit Xcode en Simulator en verplaats de juiste Xcode.app via Finder naar de Prullenmand. Verwijder /Library/Developer/CommandLineTools niet automatisch: Git, Homebrew, clang en buildscripts kunnen die nog gebruiken.
Caches van pakketbeheerders (SwiftPM, CocoaPods, npm, Homebrew)
Pakketbeheerders bewaren elke dependency die ze ooit hebben gedownload, zodat toekomstige installaties snel zijn. Dat is goede engineering en slechte schijfhygiëne: de caches groeien alleen maar, en op een machine met een paar jaar aan projecten lopen ze ongemerkt op tot 10-20 GB. Ze zijn allemaal veilig te legen — in het slechtste geval downloadt je volgende installatie de pakketten opnieuw.
Swift Package Manager cachet gedownloade pakketten in ~/Library/Caches/org.swift.swiftpm, en de opgeloste checkouts van elk project staan ook in de DerivedData-map van dat project — DerivedData legen ruimt die dus al op. De gedeelde cache kun je via de Finder verwijderen, of met rm -rf op dat pad.
Controleer alles voordat je de Prullenmand leegt
Controleer Applications, actieve processen en xcode-select -p opnieuw. Bevestig dat projecten, vereiste Archives/dSYMs en Simulator-gegevens aanwezig zijn voordat je de Prullenmand leegt. De weergave van System Data kan met vertraging worden bijgewerkt.
Veiligheidsoverzicht voor volledige verwijdering
Verwijder Xcode veilig en beoordeel herstelbare caches, Archives, DeviceSupport, Simulator-gegevens en Command Line Tools apart.
| Beslissing | Hier controleren of handelen | Gevolg en controle |
|---|---|---|
| Bescherm niet-reproduceerbare gegevens vóór het verwijderen | Projects / Xcode Organizer / Archives | Projectmappen zijn geen Xcode-restanten. Bescherm repositories, niet-gecommitte bestanden, lokale pakketten en assets. Bewaar Archives/dSYMs voor versies die nog in App Store, TestFlight of bij klanten draaien en nuttige Simulator-status. |
| Verwijder de app via de oorspronkelijke installatiemethode | /Applications/Xcode.app / Finder | Sluit Xcode en Simulator en verplaats de juiste Xcode.app via Finder naar de Prullenmand. Verwijder /Library/Developer/CommandLineTools niet automatisch: Git, Homebrew, clang en buildscripts kunnen die nog gebruiken. |
| Controleer alles voordat je de Prullenmand leegt | xcode-select -p / Activity Monitor | Controleer Applications, actieve processen en xcode-select -p opnieuw. Bevestig dat projecten, vereiste Archives/dSYMs en Simulator-gegevens aanwezig zijn voordat je de Prullenmand leegt. De weergave van System Data kan met vertraging worden bijgewerkt. |
FAQ
Kan ik heel ~/Library/Developer verwijderen?
Nee. Daar staan herstelbare DerivedData én Archives/dSYMs, DeviceSupport, runtimes en Simulator-status; beoordeel elke categorie apart.
Is het veilig om DerivedData te verwijderen?
Ja — het is een van de veiligste grote verwijderingen op een Mac. DerivedData bevat alleen bestanden die Xcode uit je broncode genereert: buildproducten, modulecaches, indexen en logs. Je code, projectbestanden en git-geschiedenis staan ergens anders en worden nooit geraakt. Het enige gevolg is dat de volgende build van elk project een volledige rebuild is en het indexeren opnieuw draait.
Hoe vaak moet ik DerivedData legen?
Er is geen verplicht schema — leeg het wanneer het groot genoeg is om ertoe te doen, wat voor de meeste actieve ontwikkelaars elke maand of twee betekent. Twee momenten rechtvaardigen het altijd: wanneer je snel schijfruimte nodig hebt, en wanneer een project onverklaarbare buildfouten of verouderde codeaanvulling laat zien — een DerivedData-wipe is dan de standaard eerste fix.
Bronnen