Slett Xcode DerivedData og utviklercacher trygt

Hva DerivedData er, og hvorfor den blir enorm

DerivedData er der Xcode oppbevarer alt den avleder fra kildekoden din: mellomliggende byggeobjekter, kompilerte produkter, modulcacher, symbolindekser for kodefullføring og hopp-til-definisjon, samt bygglogger. Den ligger som standard i ~/Library/Developer/Xcode/DerivedData, med én undermappe per prosjekt eller arbeidsområde du noen gang har åpnet.

Den vokser av en strukturell grunn: Xcode oppretter en DerivedData-mappe for hvert prosjekt du åpner — inkludert engangskloner du bygget én gang og aldri rørte igjen — og den sletter aldri noen av dem. Hver mappe holder separate byggeprodukter per konfigurasjon og destinasjon (Debug og Release, simulator og enhet), så ett enkelt mellomstort prosjekt kan oppta flere gigabyte, og mappen som helhet når gjerne 20–50 GB på en utviklermaskin i daglig bruk.

Alt i den kan per definisjon gjenskapes — det er det «derived» betyr. Å slette DerivedData rører aldri kildekoden din, prosjektinnstillingene dine eller noe som ligger under versjonskontroll. Den eneste kostnaden er tid: neste bygg av hvert prosjekt er et fullt rent bygg, og indekseringen kjører på nytt i bakgrunnen i noen minutter.

Slett DerivedData

Det finnes tre måter å gjøre det på, og de ender på samme sted. Xcodes Clean Build Folder-kommando (Product > Clean Build Folder, eller Kommando-Skift-K) tømmer bare byggeprodukter for prosjektet som er åpent akkurat nå — nyttig for å fikse et rart bygg, men den flytter knapt på diskplass-nålen. For å frigjøre reell plass må du slette selve DerivedData-mappene.

Å slette per prosjekt er det kirurgiske alternativet: behold DerivedData for de to–tre prosjektene du bygger daglig, og fjern mappene for alt annet. Å slette alt sammen er det raske alternativet, og det er også helt greit — du betaler bare full gjenoppbyggingskostnad på alle prosjektene samtidig.

1. Avslutt Xcode først. Sletter du DerivedData mens Xcode kjører, kan indeksereren bli forvirret, og filer Xcode har åpne, slettes kanskje ikke rent.
2. Finn mappen: i Xcode åpner du Settings > Locations og klikker på den lille pilen ved siden av DerivedData-stien for å vise den i Finder. Eller trykk Kommando-Skift-G i Finder og skriv inn ~/Library/Developer/Xcode/DerivedData direkte.
3. Sorter prosjektundermappene etter størrelse, marker dem du vil bli kvitt (eller Kommando-A for alle sammen), og flytt dem til Papirkurven. Papirkurven først er den tryggeste vanen — du kan gjenopprette umiddelbart hvis du ombestemmer deg.
4. Fra Terminal i stedet: rm -rf ~/Library/Developer/Xcode/DerivedData sletter alt i ett jafs. Det går raskere enn Finder for veldig store mapper, men les merknaden nedenfor før du bruker det.
5. Åpne Xcode igjen og bygg. Regn med at første bygg av hvert prosjekt tar merkbart lengre tid, og at «Indexing» kjører i aktivitetslinjen en stund — begge deler er engangskostnader.

Vær forsiktig med rm -rf: den går utenom Papirkurven og sletter permanent, uten angremulighet. Skriv stien nøyaktig, kjør den aldri med sudo for denne oppgaven, og hvis du ikke er komfortabel i Terminal, gjør Finder-ruten samme jobb — reversibelt.

Rydd ut gamle simulator-runtimes

Simulatorer er vanligvis den nest største plasstyven for utviklere etter DerivedData. Hver iOS-, watchOS- eller tvOS-runtime du noen gang har lastet ned, opptar 5–8 GB, og hver simulert enhet holder sin egen datamappe under ~/Library/Developer/CoreSimulator/Devices. Har du vært gjennom noen Xcode-oppgraderinger, har du sannsynligvis runtimes for iOS-versjoner du sluttet å bygge for for flere år siden.

Den raskeste gevinsten er den innebygde oppryddingskommandoen: kjør xcrun simctl delete unavailable i Terminal. Den sletter hver simulatorenhet hvis runtime ikke lenger er installert — de foreldreløse etterlatt av gamle Xcode-versjoner — og rører ingenting du fortsatt kan bruke.

For selve runtimene åpner du Xcodes Settings > Platforms (kalt Components i eldre Xcode-versjoner). Der ser du hver installerte simulator-runtime med størrelse; marker en gammel og slett den. Behold bare nyeste runtime per plattform, med mindre du aktivt tester på eldre OS-versjoner.

Du kan også luke ut enkelte simulerte enheter i Window > Devices and Simulators: bytt til Simulators-fanen, høyreklikk på enhver enhet du aldri bruker — de seks dupliserte iPhone-modellene med data fra gamle testkjøringer — og velg Delete. Enhetens lagrede data og apper forsvinner med den.

Arkiver, enhetsstøttefiler og cacher

Arkiver hoper seg opp i ~/Library/Developer/Xcode/Archives hver gang du kjører Product > Archive for å distribuere et bygg. Hvert arkiv inneholder et fullt appbygg pluss dSYM-feilsøkingssymbolene, ofte 100 MB til 1 GB per stykk. Før du sletter, må du kjenne avveiningen: dSYM-ene inni er det som lar deg symbolisere krasjrapporter for akkurat det bygget. Behold arkiver for versjoner som fortsatt er live på App Store eller TestFlight (eller bekreft at App Store Connect har dSYM-ene), og slett resten — den tryggeste ruten er Xcodes Organizer (Window > Organizer > Archives), der du kan gå gjennom og slette dem med kontekst.

iOS DeviceSupport, i ~/Library/Developer/Xcode/iOS DeviceSupport, holder feilsøkingssymboler som Xcode kopierer fra hver fysiske iPhone eller iPad du noen gang har koblet til — én mappe per iOS-versjon, typisk 2–5 GB hver. Mapper for iOS-versjoner ingen av enhetene dine kjører lenger, er ren dødvekt: slett dem, og hvis du noen gang kobler til en enhet på den versjonen igjen, kopierer Xcode ganske enkelt symbolene på nytt (du ser «Preparing debugger support» én gang). Søskenmapper finnes for watchOS- og tvOS-enheter også.

Xcode holder dessuten sine egne cacher under ~/Library/Caches/com.apple.dt.Xcode, og simulatorene holder sine i ~/Library/Developer/CoreSimulator/Caches — begge er trygge å tømme når Xcode og Simulator-appen ikke kjører, og begge bygges opp igjen ved behov.

Pakkehåndterer-cacher (SwiftPM, CocoaPods, npm, Homebrew)

Pakkehåndterere beholder hver eneste avhengighet de noen gang har lastet ned, slik at fremtidige installasjoner går raskt. Det er god ingeniørkunst og dårlig diskhygiene: cachene bare vokser, og på en maskin som har vært gjennom noen år med prosjekter, summerer de seg i stillhet til 10–20 GB. Alle er trygge å tømme — verste fall er at neste installasjon laster ned pakkene på nytt.

Swift Package Manager cacher nedlastede pakker i ~/Library/Caches/org.swift.swiftpm, og hvert prosjekts oppløste utsjekkinger ligger dessuten inne i prosjektets DerivedData-mappe — så tømmer du DerivedData, er de allerede borte. Den delte cachen kan du slette fra Finder, eller med rm -rf på den stien.

CocoaPods oppbevarer nedlastede pods i ~/Library/Caches/CocoaPods. Den rene måten å tømme den på er den innebygde kommandoen: pod cache clean --all. Prosjektenes Pods-mapper røres ikke; bare nedlastingscachen forsvinner.

npm sin cache ligger i ~/.npm og kan nå mange gigabyte på en JavaScript-tung maskin. Kjør npm cache clean --force for å tømme den (npm insisterer på flagget fordi cachen er selvreparerende og normalt aldri trenger rydding — å slette den er likevel helt trygt). pnpm-brukere kan kjøre pnpm store prune i stedet.

Homebrew hamstrer gamle nedlastinger og utdaterte pakkeversjoner. brew cleanup fjerner utdaterte versjoner og gamle nedlastinger; brew cleanup --prune=all tømmer i tillegg hele nedlastingscachen. Kjør brew cleanup -n først hvis du vil ha en prøvekjøringsliste over hva som ville forsvinne.

Automatiser det

Alt ovenfor fungerer, men utviklerrot er en tredemølle: DerivedData er tilbake innen en uke med normalt arbeid, cachene fylles på nytt, og hver Xcode-oppdatering strander enda en runtime. Hvis du helst slipper å kjøre seks manuelle prosedyrer på nytt hver måned, er dette delen det er verdt å automatisere — med et verktøy som viser resonnementet sitt i stedet for å masseslette i stillhet.

AskClean behandler utviklerfiler som førsteklasses kategorier: én skanning spesifiserer Xcode DerivedData per prosjekt, gamle simulator-runtimes (lest via simctl, med nyeste beholdt per plattform), enhetsstøttefiler og pakkehåndterer-cacher for npm, SwiftPM, cargo, uv og flere. Den fanger også de nyere plasstyvene — Hugging Face- og Ollama-modellcacher — som den lister opp per modell og lar stå uavhuket som standard.

Hvert element kommer med en forklaring — hva det er, om det kan gjenskapes, hva slettingen koster — og ingenting kjøres før du bekrefter. Slettinger går til Papirkurven, så et feilklikk er ett drag-og-slipp unna å være angret, og kildekoden, dokumentene og bildene dine røres aldri. Det er samme sjekkliste som denne guiden, minus timen med Terminal-arbeid.

FAQ