Xcode DerivedData en ontwikkelaarscaches veilig verwijderen

Wat DerivedData is en waarom het zo groot wordt

In DerivedData bewaart Xcode alles wat het uit je broncode afleidt: tussenliggende buildobjecten, gecompileerde producten, modulecaches, symboolindexen voor codeaanvulling en Jump to Definition, en buildlogs. Standaard staat de map in ~/Library/Developer/Xcode/DerivedData, met één submap per project of workspace die je ooit hebt geopend.

De groei heeft een structurele oorzaak: Xcode maakt een DerivedData-map aan voor elk project dat je opent — ook voor eenmalige clones die je één keer hebt gebouwd en daarna nooit meer hebt aangeraakt — en ruimt die niet uit zichzelf op. Elke map bevat aparte buildproducten per configuratie en bestemming (Debug en Release, simulator en apparaat). Meet daarom de projectsubmappen in plaats van te gokken hoeveel ruimte je Mac terugkrijgt.

Alles erin is per definitie opnieuw aan te maken; dat betekent “derived” (afgeleid) 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 daarna draait het indexeren een paar minuten op de achtergrond.

DerivedData verwijderen

Het commando Clean Build Folder van Xcode (Product > Clean Build Folder, of Shift-Command-K) wist alleen de buildproducten van het geopende project. Handig om een vreemde buildfout te verhelpen, maar voor je schijfruimte zet het nauwelijks zoden aan de dijk. Wil je echt ruimte terugwinnen, verwijder dan de DerivedData-mappen zelf: toon ze via Settings > Locations in Xcode, ga in de Finder naar de map, of verwijder ze vanuit Terminal. Alle drie de manieren komen op hetzelfde neer.

Per project verwijderen is de chirurgische optie: houd DerivedData voor de twee of drie projecten die je dagelijks bouwt en verwijder de mappen van al het andere. Alles in één keer verwijderen is de snelle optie, en ook prima; je betaalt dan wel voor alle projecten tegelijk de prijs van een volledig nieuwe build.

1. Sluit eerst Xcode af. Verwijder je DerivedData terwijl Xcode draait, dan kan de indexer in de war raken, 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 de map 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: bedenk je je, dan zet je ze direct terug.
4. Liever via Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData verwijdert alles in één keer. Bij heel grote mappen is dat sneller dan de Finder, maar lees eerst de opmerking hieronder.
5. Open Xcode weer en bouw. Reken erop dat de eerste build van elk project merkbaar langer duurt en dat er een tijdje “Indexing” 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, maar omkeerbaar.

Oude simulator-runtimes opruimen

Simulators zijn vaak een tweede grote categorie ontwikkelaarsopslag. Elke gedownloade iOS-, watchOS- of tvOS-runtime neemt zelf ruimte in, en elk gesimuleerd apparaat bewaart gegevens onder ~/Library/Developer/CoreSimulator/Devices. Heb je een paar Xcode-upgrades achter de rug, kijk dan welke runtimes horen bij systeemversies waarop je niet meer test.

De snelste winst is het ingebouwde opruimcommando: voer in Terminal xcrun simctl delete unavailable uit. Het verwijdert elk simulatorapparaat dat als niet beschikbaar (unavailable) is gemarkeerd — meestal verweesde apparaten van verwijderde runtimes en oude Xcode-versies — samen met de apps en gegevens erin. Bekijk de lijst eerst met xcrun simctl list devices, vooral als je meer dan één Xcode-versie hebt geïnstalleerd, en exporteer wat je wilt bewaren.

Voor de runtimes zelf open je in Xcode Settings > Components (in Xcode 14–15: Platforms). Daar zie je elke geïnstalleerde simulator-runtime met zijn grootte; selecteer een oude en verwijder die. Houd per platform alleen de nieuwste runtime, tenzij je actief op oudere systeemversies test.

Je kunt ook losse gesimuleerde apparaten verwijderen via Window > Devices and Simulators: open het tabblad Simulators, klik met de rechtermuisknop op een apparaat dat je nooit gebruikt — zoals die zes dubbele iPhone-modellen met gegevens van oude testruns — en kies Delete. De bewaarde gegevens en apps van dat apparaat gaan mee.

Archives, DeviceSupport-bestanden en caches

Archives stapelen zich op in ~/Library/Developer/Xcode/Archives, elke keer dat je Product > Archive uitvoert om een build te distribueren. Elk archive bevat een volledige app-build plus de dSYM-debugsymbolen, vaak 100 MB tot 1 GB per stuk. Ken vóór het verwijderen de afweging: met de dSYMs erin kun je crashrapporten van precies die build symboliseren. Bewaar archives van versies die nog in de App Store of TestFlight staan (of controleer of App Store Connect de dSYMs heeft) en verwijder de rest. De veiligste route is de Organizer van Xcode (Window > Organizer > Archives), waar je ze met context bekijkt en verwijdert.

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 waarop geen van je apparaten nog draait, zijn pure ballast. Verwijder ze; sluit je ooit weer een apparaat met die versie aan, dan kopieert Xcode de symbolen gewoon opnieuw (je ziet dan één keer “Preparing debugger support”). Vergelijkbare mappen bestaan ook voor watchOS- en tvOS-apparaten.

Xcode bewaart daarnaast eigen caches in ~/Library/Caches/com.apple.dt.Xcode, en simulators bewaren de hunne in ~/Library/Developer/CoreSimulator/Caches. Beide worden zo nodig opnieuw opgebouwd, maar leeg ze alleen als Xcode en de Simulator-app zijn gestopt, en laat cachebestanden in CoreSimulator die je niet herkent met rust.

Caches van pakketbeheerders (SwiftPM, CocoaPods, npm, Homebrew)

Pakketbeheerders bewaren gedownloade afhankelijkheden, zodat volgende installaties snel gaan. Dat is nuttig, maar op een machine met jaren aan projecten kan het toch een grote opslagcategorie worden. Deze downloadcaches zijn opnieuw op te bouwen, maar bij de volgende installatie moeten de pakketten dan opnieuw worden opgehaald.

Swift Package Manager bewaart 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 machine met veel JavaScript-werk vele gigabytes groot worden. Voer npm cache clean --force uit om hem te legen. npm vraagt om die vlag omdat de cache zichzelf herstelt en normaal nooit hoeft te worden opgeschoond; verwijderen is veilig, want pakketten worden bij de volgende installatie gewoon opnieuw gedownload. Gebruik je pnpm, voer dan pnpm store prune uit.

Homebrew hamstert oude downloads en verouderde pakketversies. brew cleanup verwijdert verouderde versies en oude downloads, en een globale run de-installeert ook afhankelijkheden die niets meer nodig heeft (tenzij HOMEBREW_NO_AUTOREMOVE is ingesteld); brew cleanup --prune=all leegt ook de hele downloadcache. Voer eerst brew cleanup -n uit als je vooraf wilt zien wat er zou verdwijnen.

Automatiseer het

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

AskClean behandelt ontwikkelaarsbestanden als volwaardige categorieën: één scan toont Xcode DerivedData per project, oude simulator-runtimes (uitgelezen via simctl, met per platform de nieuwste behouden), DeviceSupport-bestanden en caches van pakketbeheerders voor npm, SwiftPM, cargo, uv en meer. Ook de nieuwere ruimtevreters komen in beeld: Hugging Face-modellen, per model, en de standaardbibliotheek van Ollama als één geheel, allebei standaard niet aangevinkt.

Bij elk onderdeel staat een uitleg: wat het is, of het opnieuw kan worden aangemaakt en wat verwijderen kost. Er gebeurt niets tot jij bevestigt. Bevestigde onderdelen worden definitief verwijderd, niet naar de Prullenmand verplaatst; controleer dus elke selectie voordat je bevestigt. Je broncode en je fotobibliotheek blijven onaangeroerd. Het is dezelfde checklist als in deze gids, zonder een uur werk in Terminal.

Wat opnieuw op te bouwen is — en wat niet

Deze tabel laat zien waar de grens voor verwijderen ligt; het is geen belofte van een vaste besparing. Meet je Mac vóór en na elke actie, bijvoorbeeld met het controlescript uit de gids over simulatoropslag, dat alleen leest.

Veelgestelde vragen