Slett Xcode DerivedData og utviklercacher trygt

Hva DerivedData er, og hvorfor mappen blir så stor

DerivedData er der Xcode lagrer alt som avledes av kildekoden din: mellomliggende byggeobjekter, kompilerte produkter, modulcacher, symbolindekser for kodefullføring og «Jump to Definition» samt byggelogger. Mappen ligger som standard i ~/Library/Developer/Xcode/DerivedData, med én undermappe per prosjekt eller arbeidsområde du noen gang har åpnet.

Mappen vokser av en strukturell grunn: Xcode oppretter en DerivedData-mappe for hvert prosjekt du åpner – også engangskloner du bygde én gang og aldri rørte igjen – og fjerner dem ikke av seg selv. Hver mappe har egne byggeprodukter per konfigurasjon og kjøremål (Debug og Release, simulator og fysisk enhet), så mål prosjektundermappene i stedet for å gjette hvor mye plass akkurat din Mac kan få tilbake.

Alt i mappen kan per definisjon lages på nytt – det er nettopp det «derived» (avledet) betyr. Å slette DerivedData rører aldri kildekoden din, prosjektinnstillingene eller noe som ligger under versjonskontroll. Den eneste kostnaden er tid: Neste bygg av hvert prosjekt blir et fullstendig, rent bygg, og indekseringen kjører på nytt i bakgrunnen i noen minutter.

Slett DerivedData

Xcode-kommandoen Clean Build Folder (Product > Clean Build Folder, eller Skift-Kommando-K) fjerner bare byggeproduktene for prosjektet som er åpent – nyttig når et bygg oppfører seg rart, men den gjør knapt noe med diskplassen. Vil du frigjøre plass for alvor, må du slette selve DerivedData-mappene: Vis dem fra Locations-innstillingene i Xcode, gå til mappen i Finder, eller fjern dem fra Terminal. Alle tre veiene fører til samme resultat.

Å 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 på én gang er det raske alternativet, og det går også helt fint – du tar bare kostnaden med full gjenoppbygging for alle prosjektene samtidig.

1. Avslutt Xcode først. Sletter du DerivedData mens Xcode kjører, kan indekseringen komme i ulage, og filer som Xcode har åpne, blir kanskje ikke slettet ordentlig.
2. Finn mappen: Åpne Settings > Locations i Xcode, og klikk på den lille pilen ved siden av DerivedData-stien for å vise mappen i Finder. Eller trykk Skift-Kommando-G i Finder og skriv inn ~/Library/Developer/Xcode/DerivedData direkte.
3. Sorter prosjektundermappene etter størrelse, marker dem du vil bli kvitt (eller trykk Kommando-A for å markere alle), og flytt dem til Papirkurven. Å gå via Papirkurven er den tryggeste vanen – du kan legge mappene tilbake med en gang 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 svært store mapper, men les merknaden nedenfor før du bruker kommandoen.
5. Åpne Xcode igjen og bygg. Regn med at første bygg av hvert prosjekt tar merkbart lengre tid, og at «Indexing» vises i aktivitetsfeltet en stund – begge deler er engangskostnader.

Vær forsiktig med rm -rf: Kommandoen går utenom Papirkurven og sletter permanent, uten mulighet til å angre. Skriv stien nøyaktig, kjør den aldri med sudo for denne oppgaven, og er du ikke vant til Terminal, gjør Finder samme jobben – og der kan du angre.

Rydd bort gamle simulator-runtimes

Simulatorer er ofte en annen stor kategori i utviklerlagringen. Hver iOS-, watchOS- eller tvOS-runtime du har lastet ned, tar sin egen plass, og hver simulert enhet lagrer data under ~/Library/Developer/CoreSimulator/Devices. Har du vært gjennom noen Xcode-oppgraderinger, bør du se etter runtimes for OS-versjoner du ikke lenger tester på.

Den raskeste gevinsten er den innebygde oppryddingskommandoen: Kjør xcrun simctl delete unavailable i Terminal. Den sletter alle simulatorenheter som er merket unavailable – for det meste foreldreløse enheter etter fjernede runtimes og gamle Xcode-versjoner – sammen med appene og dataene i dem. Gå gjennom listen med xcrun simctl list devices først, særlig hvis du har mer enn én Xcode-versjon installert.

For selve runtimene åpner du Settings > Components i Xcode (kalt Platforms i Xcode 14–15). Der ser du hver installerte simulator-runtime med størrelse; marker en gammel og slett den. Behold bare den nyeste runtimen 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 fanen Simulators, høyreklikk på enheter du aldri bruker – for eksempel de seks dupliserte iPhone-modellene med data fra gamle testkjøringer – og velg Delete. Lagrede data og apper på enheten forsvinner sammen med den.

Arkiver, DeviceSupport-filer 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 komplett appbygg pluss dSYM-filene med feilsøkingssymboler, ofte 100 MB til 1 GB per stykk. Kjenn avveiningen før du sletter: Det er dSYM-filene i arkivet som lar deg symbolisere krasjrapporter for akkurat det bygget. Behold arkiver for versjoner som fortsatt er ute i App Store eller TestFlight (eller bekreft at App Store Connect har dSYM-filene), og slett resten – tryggest i Organizer i Xcode (Window > Organizer > Archives), der du ser versjon og byggnummer mens du går gjennom og sletter.

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

Xcode har dessuten egne cacher under ~/Library/Caches/com.apple.dt.Xcode, og simulatorene har sine i ~/Library/Developer/CoreSimulator/Caches. Begge bygges opp igjen ved behov, men tøm dem bare når Xcode og Simulator-appen er avsluttet, og la CoreSimulator-cachefiler du ikke kjenner igjen, være i fred.

Cacher fra pakkebehandlere (SwiftPM, CocoaPods, npm, Homebrew)

Pakkebehandlere tar vare på nedlastede avhengigheter, slik at senere installasjoner går raskt. Det er nyttig, men kan likevel bli en stor post på en maskin som har vært gjennom mange år med prosjekter. Disse nedlastingscachene kan bygges opp igjen, men neste installasjon må da hente pakkene på nytt.

Swift Package Manager lagrer nedlastede pakker i ~/Library/Caches/org.swift.swiftpm, og hvert prosjekts utsjekkede avhengigheter ligger dessuten i prosjektets DerivedData-mappe – så tømmer du DerivedData, forsvinner også de. Den delte cachen kan du slette i Finder, eller med rm -rf på den stien.

CocoaPods lagrer nedlastede pods i ~/Library/Caches/CocoaPods. Den ryddige måten å tømme den på er den innebygde kommandoen: pod cache clean --all. Pods-mappene i prosjektene dine røres ikke; bare nedlastingscachen forsvinner.

npm-cachen ligger i ~/.npm og kan bli mange gigabyte stor på en maskin med mye JavaScript-arbeid. Kjør npm cache clean --force for å tømme den (npm krever flagget fordi cachen reparerer seg selv og normalt aldri trenger å tømmes; det er likevel trygt å slette den – pakkene lastes bare ned på nytt ved neste installasjon). Bruker du pnpm, kan du kjøre pnpm store prune i stedet.

Homebrew samler på gamle nedlastinger og utdaterte pakkeversjoner. brew cleanup fjerner utdaterte versjoner og gamle nedlastinger, og kjører du kommandoen for alle pakker, avinstallerer den også avhengigheter som ingenting trenger lenger (med mindre HOMEBREW_NO_AUTOREMOVE er satt); brew cleanup --prune=all tømmer i tillegg hele nedlastingscachen. Kjør brew cleanup -n først hvis du vil se en prøvekjøring av hva som ville blitt fjernet.

Automatiser oppryddingen

Alt ovenfor fungerer, men utviklerrot er en tredemølle: DerivedData er tilbake etter en uke med vanlig arbeid, cachene fylles igjen, og hver Xcode-oppdatering etterlater enda en runtime. Vil du slippe å gjenta seks manuelle prosedyrer hver måned, er det denne delen som er verdt å automatisere – med et verktøy som viser begrunnelsen sin i stedet for å masseslette i det stille.

AskClean behandler utviklerfiler som egne kategorier: Én skanning viser Xcode DerivedData per prosjekt, gamle simulator-runtimes (lest via simctl, der den nyeste per plattform beholdes), DeviceSupport-filer og cacher fra pakkebehandlere som npm, SwiftPM, cargo og uv. Den fanger også opp de nyere plasstyvene – lokale AI-modeller – og viser Hugging Face-modeller én for én og Ollama-modellbiblioteket som ett samlet element, uten at noen av dem er valgt som standard.

Hvert element har en forklaring – hva det er, om det kan bygges opp igjen, og hva slettingen koster – og ingenting skjer før du bekrefter. Bekreftede elementer slettes permanent i stedet for å flyttes til Papirkurven, så se over hvert valg før du bekrefter. Kildekoden og bildebiblioteket ditt røres aldri. Det er samme sjekkliste som i denne guiden, bare uten timen med Terminal-arbeid.

Hva som kan bygges opp igjen – og hva som ikke kan

Tabellen viser hvor grensene for sletting går; den lover ingen bestemt besparelse. Mål Macen før og etter hver handling – kontrollskriptet i guiden om lagring i Xcode Simulator viser disse mappene uten å endre noe.

Vanlige spørsmål