Slet Xcode DerivedData og udviklercaches sikkert

Hvad DerivedData er, og hvorfor mappen bliver så stor

I DerivedData gemmer Xcode alt, hvad programmet afleder af din kildekode: mellemliggende build-objekter, kompilerede produkter, modulcaches, symbolindekser til kodefuldførelse og ”Jump to Definition” samt build-logfiler. Mappen ligger som standard i ~/Library/Developer/Xcode/DerivedData med én undermappe for hvert projekt eller workspace, du nogensinde har åbnet.

Den vokser af en strukturel grund: Xcode opretter en DerivedData-mappe for hvert projekt, du åbner — også engangskloner, du byggede én gang og aldrig rørte igen — og fjerner dem ikke af sig selv. Hver mappe rummer separate build-produkter pr. konfiguration og destination (Debug og Release, simulator og enhed), så mål projektundermapperne i stedet for at gætte på, hvor meget plads din Mac får tilbage.

Alt i den kan pr. definition genskabes — det er det, ”derived” (afledt) betyder. Når du sletter DerivedData, rører du aldrig din kildekode, dine projektindstillinger eller noget under versionsstyring. Den eneste omkostning er tid: Næste build af hvert projekt bliver et fuldt clean build, og indekseringen kører igen i baggrunden i nogle minutter.

Slet DerivedData

Xcodes kommando Clean Build Folder (Product > Clean Build Folder eller Skift-Kommando-K) rydder kun build-produkterne for det projekt, der er åbent — nyttigt, når et build opfører sig mærkeligt, men det batter næsten ingenting på diskpladsen. Vil du frigøre reel plads, skal du slette selve DerivedData-mapperne: Vis dem via Locations i Xcodes indstillinger, gå til mappen i Finder, eller fjern dem fra Terminal. Alle tre veje fører samme sted hen.

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 det er også helt i orden — du betaler bare prisen for at genopbygge alle projekter på én gang.

1. Luk Xcode først. Sletter du DerivedData, mens Xcode kører, kan indekseringen komme i uorden, og filer, som Xcode har åbne, bliver måske ikke slettet ordentligt.
2. Find mappen: Åbn Settings > Locations i Xcode, og klik på den lille pil ud for DerivedData-stien for at vise mappen i Finder. Du kan også trykke på Skift-Kommando-G i Finder og skrive ~/Library/Developer/Xcode/DerivedData direkte.
3. Sorter projektundermapperne efter størrelse, marker dem, du vil af med (eller tryk på Kommando-A for at vælge dem alle), og flyt dem til papirkurven. Det er den sikreste vane at gå via papirkurven — du kan lægge mapperne tilbage med det samme, hvis du fortryder.
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 bemærkningen herunder, før du bruger kommandoen.
5. Åbn Xcode igen, og byg. Regn med, at det første build af hvert projekt tager mærkbart længere tid, og at ”Indexing” står i aktivitetsfeltet et stykke tid — begge dele er engangsomkostninger.

Vær forsigtig med rm -rf: Kommandoen går uden om papirkurven og sletter permanent uden mulighed for at fortryde. Skriv stien helt præcist, kør den aldrig med sudo til denne opgave, og er du ikke tryg ved Terminal, klarer Finder samme opgave — på en måde, der kan fortrydes.

Ryd gamle simulator-runtimes

Simulatorer er ofte endnu en stor kategori på en udvikler-Mac. Hver hentet runtime til iOS, watchOS eller tvOS fylder sit, og hver simuleret enhed gemmer data under ~/Library/Developer/CoreSimulator/Devices. Har du været igennem et par Xcode-opgraderinger, så gennemgå de runtimes, der hører til systemversioner, du ikke længere tester på.

Den hurtigste gevinst er den indbyggede oprydningskommando: Kør xcrun simctl delete unavailable i Terminal. Den sletter alle simulatorenheder, der er markeret som unavailable — for det meste forældreløse enheder efter fjernede runtimes og gamle Xcode-versioner — sammen med de apps og data, de indeholder. Gennemgå listen med xcrun simctl list devices først, især hvis du har mere end én Xcode installeret.

Selve runtimes fjerner du i Xcode under Settings > Components (hed Platforms i Xcode 14–15). Her ser du 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 systemversioner.

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

Archives, DeviceSupport-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: Det er dSYM-filerne i arkivet, der gør det muligt at symbolikere crashrapporter for netop det build. Behold arkiver for versioner, der stadig er ude i App Store eller TestFlight (eller bekræft, at App Store Connect har dSYM-filerne), og slet resten — sikrest i Xcodes Organizer (Window > Organizer > Archives), hvor du kan gennemgå og slette dem med alle oplysninger for øje.

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 til iOS-versioner, som ingen af dine enheder kører længere, er ren dødvægt: Slet dem, og tilslutter du senere en enhed med den version igen, kopierer Xcode blot symbolerne på ny (du ser ”Preparing debugger support” én gang). Tilsvarende mapper findes til watchOS- og tvOS-enheder.

Xcode har desuden sine egne caches i ~/Library/Caches/com.apple.dt.Xcode, og simulatorerne har deres i ~/Library/Developer/CoreSimulator/Caches. Begge genopbygges efter behov, men ryd dem kun, mens Xcode og appen Simulator er lukket, og lad CoreSimulator-cachefiler, du ikke kender, være i fred.

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

Pakkehåndteringer gemmer hentede afhængigheder, så fremtidige installationer går hurtigt. Det er nyttigt, men kan alligevel blive en stor post på en maskine med mange års projekter bag sig. Downloadcaches kan genskabes, men næste installation skal så hente pakkerne igen.

Swift Package Manager gemmer hentede pakker i ~/Library/Caches/org.swift.swiftpm, og de checkouts, hvert projekt har hentet, ligger desuden i projektets DerivedData-mappe — så når du rydder DerivedData, ryger de også. Den delte cache kan du slette i Finder eller med rm -rf på den sti.

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

npm's cache ligger i ~/.npm og kan nå op på mange gigabyte på en maskine, hvor der arbejdes meget med JavaScript. Kør npm cache clean --force for at tømme den (npm kræver flaget, fordi cachen reparerer sig selv og normalt aldrig behøver at blive ryddet; det er sikkert at slette den — pakkerne hentes bare igen ved næste installation). Bruger du pnpm, kan du i stedet køre pnpm store prune.

Homebrew hamstrer gamle downloads og forældede pakkeversioner. brew cleanup fjerner forældede versioner og gamle downloads, og en global kørsel afinstallerer desuden afhængigheder, som intet længere bruger (medmindre HOMEBREW_NO_AUTOREMOVE er sat); brew cleanup --prune=all tømmer derudover hele downloadcachen. Kør brew cleanup -n først, hvis du vil se en liste over, hvad der ville blive fjernet, uden at ændre noget.

Automatiser oprydningen

Alt det ovenstående virker, men udviklerskrammel er et hamsterhjul: DerivedData er tilbage efter en uges normalt arbejde, caches fyldes op igen, og hver Xcode-opdatering efterlader endnu en overflødig runtime. Hvis du helst ikke vil gentage seks manuelle procedurer hver måned, er det denne del, der er værd at automatisere — med et værktøj, der viser sit ræsonnement i stedet for at masseslette i det stille.

AskClean behandler udviklerfiler som selvstændige kategorier: Én scanning viser Xcode DerivedData pr. projekt, gamle simulator-runtimes (aflæst via simctl, så den nyeste pr. platform beholdes), DeviceSupport-filer og caches fra pakkehåndteringer som npm, SwiftPM, cargo, uv og flere. Den finder også de nyere pladsslugere — lokale AI-modeller — og viser Hugging Face-modeller enkeltvis og Ollamas modelbibliotek som ét samlet element, alle fravalgt som standard.

Hvert element har en forklaring — hvad det er, om det kan genopbygges, og hvad det koster at slette det — og intet sker, før du bekræfter. Bekræftede elementer slettes permanent i stedet for at blive flyttet til papirkurven, så gennemgå hvert valg, før du bekræfter; din kildekode og dit fotobibliotek røres aldrig. Det er samme tjekliste som i denne guide — bare uden timen i Terminal.

Hvad der kan genopbygges — og hvad der ikke kan

Tabellen viser, hvor grænserne for sletning går; den lover ingen bestemt besparelse. Mål din Mac før og efter hver handling — scriptet i guiden om lagerplads i Xcode Simulator viser disse mapper uden at ændre noget.

FAQ