Slet Xcode DerivedData & udviklercaches sikkert

Hvad DerivedData er, og hvorfor den bliver enorm

DerivedData er stedet, hvor Xcode opbevarer alt, hvad den afleder af din kildekode: mellemliggende build-objekter, kompilerede produkter, modulcaches, symbolindekser til kodefuldførelse og hop-til-definition samt build-logfiler. Den ligger som standard i ~/Library/Developer/Xcode/DerivedData med én undermappe pr. projekt eller workspace, du nogensinde har åbnet.

Den vokser af en strukturel grund: Xcode opretter en DerivedData-mappe for hvert projekt, du åbner — inklusive engangs-kloner, du byggede én gang og aldrig rørte igen — og den sletter aldrig nogen af dem. Hver mappe rummer separate build-produkter pr. konfiguration og destination (Debug og Release, simulator og enhed), så et enkelt mellemstort projekt kan fylde flere gigabyte, og mappen som helhed når typisk 20-50 GB på en aktiv udviklermaskine.

Alt i den kan pr. definition genskabes — det er det, “derived” betyder. At slette DerivedData rører aldrig din kildekode, dine projektindstillinger eller noget som helst under versionsstyring. Den eneste omkostning er tid: Det næste build af hvert projekt er et fuldt clean build, og indekseringen kører igen i baggrunden i et par minutter.

Slet DerivedData

Der er tre måder at gøre det på, og de ender samme sted. Xcodes kommando Clean Build Folder (Product > Clean Build Folder, eller Kommando-Skift-K) rydder kun build-produkter for det aktuelt åbne projekt — nyttigt til at fikse et mærkeligt build, men det rykker knap nok nålen på diskpladsen. Vil du frigøre reel plads, skal du slette selve DerivedData-mapperne.

At slette pr. projekt er den kirurgiske løsning: Behold DerivedData for de to-tre projekter, du bygger dagligt, og fjern mapperne for alt andet. At slette det hele er den hurtige løsning, og den er også fin — du betaler bare prisen for fuld genopbygning af alle projekter på én gang.

1. Luk Xcode først. Sletter du DerivedData, mens Xcode kører, kan dens indekser blive forvirret, og filer, Xcode har åbne, bliver måske ikke slettet rent.
2. Find mappen: Åbn Settings > Locations i Xcode, og klik på den lille pil ved siden af DerivedData-stien for at vise den i Finder. Eller tryk Skift-Kommando-G i Finder, og indtast ~/Library/Developer/Xcode/DerivedData direkte.
3. Sortér projektundermapperne efter størrelse, markér dem, du vil af med (eller Kommando-A for dem alle), og flyt dem til papirkurven. Papirkurven først er den sikreste vane — du kan gendanne øjeblikkeligt, hvis du ombestemmer dig.
4. Fra Terminal i stedet: rm -rf ~/Library/Developer/Xcode/DerivedData sletter det hele i ét hug. Det er hurtigere end Finder ved meget store mapper, men læs noten herunder, før du bruger det.
5. Genåbn Xcode, og byg. Forvent, at det første build af hvert projekt tager mærkbart længere, og at “Indexing” kører i aktivitetsbjælken et stykke tid — begge dele er engangsomkostninger.

Vær forsigtig med rm -rf: Kommandoen går uden om papirkurven og sletter permanent uden fortrydelsesmulighed. Skriv stien helt præcist, kør den aldrig med sudo til denne opgave, og hvis du ikke er tryg i Terminal, klarer Finder-vejen samme job — reversibelt.

Ryd gamle simulator-runtimes

Simulatorer er som regel den næststørste pladssluger for udviklere efter DerivedData. Hver iOS-, watchOS- eller tvOS-runtime, du nogensinde har hentet, fylder 5-8 GB, og hver simuleret enhed har sin egen datamappe under ~/Library/Developer/CoreSimulator/Devices. Har du været gennem et par Xcode-opgraderinger, har du sandsynligvis runtimes til iOS-versioner, du stoppede med at bygge til for flere år siden.

Den hurtigste gevinst er den indbyggede oprydningskommando: Kør xcrun simctl delete unavailable i Terminal. Den sletter hver simulatorenhed, hvis runtime ikke længere er installeret — de forældreløse rester fra gamle Xcode-versioner — og rører intet, du stadig kan bruge.

For selve runtimes: Åbn Xcodes Settings > Platforms (kaldet Components i ældre Xcode-versioner). Du ser hver installeret simulator-runtime med dens størrelse; vælg en gammel, og slet den. Behold kun den nyeste runtime pr. platform, medmindre du aktivt tester på ældre OS-versioner.

Du kan også luge ud i enkelte simulerede enheder i Window > Devices and Simulators: Skift til fanen Simulators, højreklik på en enhed, du aldrig bruger — de seks ens iPhone-modeller med data fra gamle testkørsler — og vælg Delete. Enhedens gemte data og apps forsvinder med den.

Arkiver, device support-filer og caches

Arkiver hober sig op i ~/Library/Developer/Xcode/Archives, hver gang du kører Product > Archive for at distribuere et build. Hvert arkiv indeholder et komplet app-build plus dets dSYM-fejlfindingssymboler, ofte 100 MB til 1 GB stykket. Kend afvejningen, før du sletter: dSYM-filerne indeni er det, der lader dig symbolikere nedbrudsrapporter for netop det build. Behold arkiver for versioner, der stadig er live på App Store eller TestFlight (eller bekræft, at App Store Connect har dSYM-filerne), og slet resten — den sikreste vej er Xcodes Organizer (Window > Organizer > Archives), hvor du kan gennemgå og slette dem med kontekst.

iOS DeviceSupport, i ~/Library/Developer/Xcode/iOS DeviceSupport, rummer fejlfindingssymboler, som Xcode kopierer fra hver fysisk iPhone eller iPad, du nogensinde har tilsluttet — én mappe pr. iOS-version, typisk 2-5 GB stykket. Mapper for iOS-versioner, som ingen af dine enheder længere kører, er ren dødvægt: Slet dem, og skulle du igen tilslutte en enhed på den version, kopierer Xcode simpelthen symbolerne på ny (du ser “Preparing debugger support” én gang). Tilsvarende mapper findes også for watchOS- og tvOS-enheder.

Xcode har desuden sine egne caches under ~/Library/Caches/com.apple.dt.Xcode, og simulatorerne har deres i ~/Library/Developer/CoreSimulator/Caches — begge sikre at rydde, når Xcode og Simulator-appen ikke kører, og begge genopbygges efter behov.

Caches fra pakkehåndteringer (SwiftPM, CocoaPods, npm, Homebrew)

Pakkehåndteringer gemmer hver eneste afhængighed, de nogensinde har hentet, så fremtidige installationer går hurtigt. Det er god ingeniørkunst og dårlig diskhygiejne: Cacherne vokser kun, og på en maskine med et par års projekter bag sig lægger de stille og roligt 10-20 GB til. Alle er sikre at rydde — i værste fald henter din næste installation pakkerne igen.

Swift Package Manager cacher hentede pakker i ~/Library/Caches/org.swift.swiftpm, og hvert projekts opløste checkouts ligger desuden inde i dets DerivedData-mappe — så rydning af DerivedData rydder allerede dem. Den delte cache kan du slette fra Finder eller med rm -rf på den sti.

CocoaPods opbevarer sine hentede pods i ~/Library/Caches/CocoaPods. Den rene måde at tømme den på er den indbyggede kommando: pod cache clean --all. Dine projekters Pods-mapper røres ikke; kun downloadcachen ryger.

npm's cache ligger i ~/.npm og kan nå mange gigabyte på en JavaScript-tung maskine. Kør npm cache clean --force for at tømme den (npm insisterer på flaget, fordi cachen er selvhelende og normalt aldrig behøver rydning — det er stadig helt sikkert at slette den). pnpm-brugere kan i stedet køre pnpm store prune.

Homebrew hamstrer gamle downloads og forældede pakkeversioner. brew cleanup fjerner forældede versioner og gamle downloads; brew cleanup --prune=all tømmer desuden hele downloadcachen. Kør brew cleanup -n først, hvis du vil have en prøvekørselsliste over, hvad der ville ryge.

Automatisér det

Alt det ovenstående virker, men udviklerskrammel er et løbebånd: DerivedData er tilbage inden for en uges normalt arbejde, cacherne fyldes op igen, og hver Xcode-opdatering efterlader endnu en strandet runtime. Hvis du helst ikke vil gentage seks manuelle procedurer hver måned, er det her den del, der er værd at automatisere — med et værktøj, der viser sit ræsonnement i stedet for lydløst at massesletter.

AskClean behandler udviklerfiler som førsteklasses kategorier: Én scanning specificerer Xcode DerivedData pr. projekt, gamle simulator-runtimes (læst via simctl, med den nyeste beholdt pr. platform), device support-filer og caches fra pakkehåndteringer som npm, SwiftPM, cargo, uv med flere. Den fanger også de nyere pladsslugere — modelcaches fra Hugging Face og Ollama — som den lister pr. model og lader være fravalgt som standard.

Hvert element kommer med en forklaring — hvad det er, om det kan genopbygges, hvad det koster at slette — og intet kører, før du bekræfter det. Sletninger ryger i papirkurven, så et fejlklik kan fortrydes med et enkelt træk, og din kildekode, dine dokumenter og fotos røres aldrig. Det er samme tjekliste som denne guide — minus timen med Terminal-arbejde.

FAQ