Xcode: Clean Build Folder of DerivedData verwijderen?

Het verschil zit in de reikwijdte, niet in de grondigheid

Product > Clean Build Folder (Shift-Command-K) werkt binnen het project en het scheme dat je op dat moment open hebt. Het gooit de gecompileerde producten en tussenresultaten voor die context weg, zodat de volgende build weer vanaf de broncode begint. Het blijft beperkt tot één project en laat bewust staan wat duur is om opnieuw op te bouwen.

DerivedData is de bovenliggende map die alle projecten met de standaardlocatie delen: ~/Library/Developer/Xcode/DerivedData, met één submap per project of workspace die je ooit hebt geopend. Verwijder je één submap, dan reset je precies dat project. Verwijder je de hele map, dan moet elk project bij de volgende keer openen opnieuw worden gebouwd en geïndexeerd.

Het eerlijke onderscheid is dus niet “lichte schoonmaak” tegenover “grote schoonmaak”. Clean Build Folder is beperkt en goedkoop; DerivedData verwijderen is breed en kost je de index. Welke van de twee de juiste is, hangt er volledig van af of wat er stuk is in de buildproducten zit of daarbuiten.

Gaat een build stuk? Begin klein

Trad de fout op direct nadat je van branch bent gewisseld, een buildconfiguratie hebt gewijzigd of resourcebestanden hebt bewerkt? Stop dan de draaiende app en gebruik eerst Clean Build Folder. Dat is de goedkoopste reset die er is: de index blijft behouden en je kunt na één build weer verder, in plaats van na één build plus enkele minuten indexeren.

Ga pas over op het verwijderen van de DerivedData-map van dat project als de symptomen eigenlijk niet over buildproducten gaan: Xcode toont fouten in code die je al hebt opgelost, Jump to Definition komt op de verkeerde plek uit, of codeaanvulling begrijpt je eigen types niet meer. Dat zijn indexsymptomen, en Clean Build Folder komt niet aan de index.

Eén specifiek geval is goed om te kennen, omdat het meestal verklaart waarom “ik heb opgeschoond en het hielp niet” verandert in “ik heb DerivedData verwijderd en toen werkte het wel”: de voorgecompileerde modulecache (ModuleCache.noindex) staat in de hoofdmap van DerivedData, niet in de submap van een project. Clean Build Folder komt daar nooit bij. Raakt een modulecache verouderd na een wijziging van de SDK of toolchain, dan verdwijnt de fout pas als je die cache verwijdert.

Geen van beide opdrachten lost een echte bug in je broncode of je afhankelijkheden op. Overleeft precies dezelfde fout een schone build, stop dan met opschonen en lees de compilermelding: de oorzaak zit dan in de projectinstellingen, Package.resolved, de gekozen SDK of de code zelf.

Geen van beide is een manier om schijfruimte vrij te maken

Clean Build Folder is een diagnosehulpmiddel dat toevallig wat bytes vrijmaakt. Het kan ruimte opleveren voor het huidige project, maar de buildproducten van alle andere projecten, alle indexen en de modulecache blijven precies waar ze waren. Wie het gebruikt om schijfruimte terug te winnen, meet het verkeerde.

Is ruimte het eigenlijke doel, pak het dan andersom aan: meet eerst de submappen van DerivedData en verwijder daarna de projecten die je al maanden niet hebt geopend. Daar zitten meestal de tientallen gigabytes: eenmalige clones die je één keer hebt gebouwd en waar je daarna nooit meer naar hebt omgekeken.

Begin niet met rm -rf. In de Finder verplaats je de geselecteerde mappen naar de Prullenmand, waar ze terug te halen zijn tot je die leegt. Dat verschil telt zodra je per ongeluk de map verwijdert van een project dat op dat moment juist wordt gebouwd. Terminal is handig voor automatisering, maar pas nadat je het exacte pad hebt gecontroleerd.

Controleer het resultaat in plaats van op een getal te vertrouwen

Noteer de grootte van DerivedData voordat je iets doet, pas precies één van de twee opties toe en meet daarna opnieuw. Bouw na Clean Build Folder het huidige scheme. Open na het verwijderen van een DerivedData-map Xcode en wacht tot de eerste build en het indexeren klaar zijn.

Door het in die volgorde te doen, houd je de ruimte die je terugkrijgt gescheiden van de prijs die je ervoor betaalt. Er is geen universeel getal te verwachten: het resultaat hangt af van hoeveel projecten, configuraties en architecturen er op die specifieke Mac zijn gebouwd.

Welke kies je wanneer?

Deze tabel beschrijft het bereik, geen beloofd aantal gigabytes. Meet je eigen Mac vóór en na.

Veelgestelde vragen