AskCleanAskClean

Xcode DerivedData & ontwikkelaarscaches veilig verwijderen

AskClean Team · Updated 2026-07-18

DerivedData is de kladmap van Xcode voor buildproducten en indexen, en hij kan ongemerkt aangroeien tot tientallen gigabytes. Verwijderen is veilig: stop Xcode, verwijder de inhoud van ~/Library/Developer/Xcode/DerivedData, en Xcode bouwt alles bij de volgende build opnieuw op. Deze gids behandelt dat, plus simulators, archieven en pakketcaches.

Wat DerivedData is en waarom het zo groot wordt

DerivedData is waar Xcode alles bewaart wat het uit je broncode afleidt: tussenliggende buildobjecten, gecompileerde producten, modulecaches, symboolindexen voor codeaanvulling en jump-to-definition, en buildlogs. Het staat standaard op ~/Library/Developer/Xcode/DerivedData, met één submap per project of workspace die je ooit hebt geopend.

Het groeit om een structurele reden: Xcode maakt een DerivedData-map aan voor elk project dat je opent — inclusief eenmalige clones die je één keer hebt gebouwd en nooit meer hebt aangeraakt — en verwijdert er zelf nooit één. Elke map bevat aparte buildproducten per configuratie en bestemming (Debug en Release, simulator en apparaat), dus één middelgroot project kan meerdere gigabytes innemen, en de map als geheel bereikt op een werkende dev-machine gewoonlijk 20-50 GB.

Alles erin is per definitie opnieuw aan te maken — dat betekent "derived" nu eenmaal. DerivedData verwijderen raakt nooit je broncode, je projectinstellingen of iets onder versiebeheer. De enige prijs is tijd: de volgende build van elk project is een volledige schone build, en het indexeren draait daarna een paar minuten op de achtergrond.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Oude simulator-runtimes opruimen

Simulators zijn na DerivedData meestal de op één na grootste ruimtevreter voor ontwikkelaars. Elke iOS-, watchOS- of tvOS-runtime die je ooit hebt gedownload neemt 5-8 GB in, en elk gesimuleerd apparaat houdt zijn eigen gegevensmap bij onder ~/Library/Developer/CoreSimulator/Devices. Heb je een paar Xcode-upgrades achter de rug, dan heb je waarschijnlijk runtimes voor iOS-versies die je jaren geleden al hebt losgelaten.

De snelste winst is het ingebouwde opruimcommando: voer xcrun simctl delete unavailable uit in Terminal. Het verwijdert elk simulatorapparaat waarvan de runtime niet meer is geïnstalleerd — de wezen die oude Xcode-versies achterlieten — en raakt niets aan wat je nog kunt gebruiken.

Voor de runtimes zelf open je Xcode's Settings > Platforms (in oudere Xcode-versies Components genoemd). Je ziet elke geïnstalleerde simulator-runtime met zijn grootte; selecteer een oude en verwijder hem. Houd per platform alleen de nieuwste runtime, tenzij je actief op oudere OS-versies test.

Je kunt ook losse gesimuleerde apparaten snoeien in Window > Devices and Simulators: ga naar het tabblad Simulators, klik met de rechtermuisknop op elk apparaat dat je nooit gebruikt — de zes dubbele iPhone-modellen met data van oude testruns — en kies Delete. De bewaarde gegevens en apps van elk apparaat gaan mee.

Archieven, device-supportbestanden en caches

Archieven stapelen zich op in ~/Library/Developer/Xcode/Archives, elke keer dat je Product > Archive uitvoert om een build te distribueren. Elk archief bevat een volledige app-build plus de dSYM-debugsymbolen, vaak 100 MB tot 1 GB per stuk. Ken vóór het verwijderen de afweging: de dSYM's erin zijn wat je nodig hebt om crashrapporten van precies die build te symboliceren. Bewaar archieven van versies die nog live staan in de App Store of TestFlight (of controleer dat App Store Connect de dSYM's heeft) en verwijder de rest — de veiligste route is Xcode's Organizer (Window > Organizer > Archives), waar je ze met context kunt bekijken en verwijderen.

iOS DeviceSupport, in ~/Library/Developer/Xcode/iOS DeviceSupport, bevat debugsymbolen die Xcode kopieert van elke fysieke iPhone of iPad die je ooit hebt aangesloten — één map per iOS-versie, doorgaans 2-5 GB per stuk. Mappen voor iOS-versies waar geen van je apparaten nog op draait zijn puur dood gewicht: verwijder ze, en sluit je ooit weer een apparaat met die versie aan, dan kopieert Xcode de symbolen gewoon opnieuw (je ziet één keer "Preparing debugger support"). Vergelijkbare mappen bestaan ook voor watchOS- en tvOS-apparaten.

Xcode houdt daarnaast zijn eigen caches bij onder ~/Library/Caches/com.apple.dt.Xcode, en simulators bewaren de hunne in ~/Library/Developer/CoreSimulator/Caches — beide veilig te legen zolang Xcode en de Simulator-app niet draaien, en beide worden op verzoek opnieuw opgebouwd.

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.

CocoaPods bewaart gedownloade pods in ~/Library/Caches/CocoaPods. De nette manier om die te legen is het ingebouwde commando: pod cache clean --all. De Pods-mappen van je projecten blijven staan; alleen de downloadcache verdwijnt.

De cache van npm staat in ~/.npm en kan op een JavaScript-zware machine vele gigabytes bereiken. Voer npm cache clean --force uit om hem te legen (npm staat op die vlag omdat de cache zichzelf herstelt en normaal nooit schoongemaakt hoeft te worden — hem verwijderen is toch volkomen veilig). pnpm-gebruikers voeren in plaats daarvan pnpm store prune uit.

Homebrew hamstert oude downloads en verouderde pakketversies. brew cleanup verwijdert verouderde versies en oude downloads; brew cleanup --prune=all leegt ook de hele downloadcache. Voer eerst brew cleanup -n uit als je een proefdraai-lijst wilt van wat er zou verdwijnen.

Automatiseer het

Alles hierboven werkt, maar ontwikkelaarsrommel is een tredmolen: DerivedData is binnen een week normaal werk terug, caches vullen zich opnieuw, en elke Xcode-update laat weer een runtime achter. Wil je niet elke maand zes handmatige procedures herhalen, dan is dit het deel dat automatiseren waard is — met een tool die zijn redenering laat zien in plaats van stilletjes in bulk te verwijderen.

AskClean behandelt ontwikkelaarsbestanden als volwaardige categorieën: één scan splitst Xcode DerivedData uit per project, plus oude simulator-runtimes (uitgelezen via simctl, met per platform de nieuwste behouden), device-supportbestanden en caches van pakketbeheerders voor npm, SwiftPM, cargo, uv en meer. Het vangt ook de nieuwere ruimtevreters — modelcaches van Hugging Face en Ollama — die het per model toont en standaard niet aanvinkt.

Elk item komt met een uitleg — wat het is, of het opnieuw kan worden aangemaakt, wat verwijderen kost — en er gebeurt niets tot jij het bevestigt. Verwijderen gaat via de Prullenmand, dus een verkeerde klik is met slepen weer ongedaan gemaakt, en je broncode, documenten en foto's blijven onaangeroerd. Het is dezelfde checklist als deze gids, minus het uur Terminal-werk.

FAQ

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.

Wordt Xcode trager nadat ik DerivedData heb verwijderd?

Tijdelijk wel. De eerste build van elk project is een schone build, die meerdere keren langer kan duren dan een incrementele, en het indexeren op de achtergrond heeft een paar minuten nodig voordat codeaanvulling en zoeken weer volledig werken. Na die eerste cyclus is de prestatie precies wat hij was — DerivedData bevat caches, geen optimalisaties die je blijvend kwijtraakt.

En ~/Library/Developer/CoreSimulator — mag die weg?

Niet blindelings — die map bevat je huidige simulators en hun gegevens, en hem in zijn geheel verwijderen breekt ze totdat je de runtimes opnieuw installeert. Snoei hem in plaats daarvan netjes: voer xcrun simctl delete unavailable uit voor verweesde apparaten, verwijder oude runtimes in Xcode's Settings > Platforms, gooi ongebruikte apparaten weg in Devices and Simulators, en leeg alleen de submap Caches handmatig.

Doet Clean Build Folder hetzelfde?

Nee. Product > Clean Build Folder (Command-Shift-K) wist alleen de buildproducten van het huidige project en laat indexen, modulecaches en de mappen van alle andere projecten staan. Het is een tool voor build-problemen, niet voor schijfruimte — echt ruimte terugwinnen betekent de DerivedData-mappen zelf verwijderen.

Sources