Radera Xcode DerivedData och utvecklarcacher tryggt

Vad DerivedData är och varför den blir enorm

DerivedData är där Xcode förvarar allt det härleder ur din källkod: mellanliggande byggobjekt, kompilerade produkter, modulcacher, symbolindex för kodkomplettering och hoppa-till-definition, samt byggloggar. Den ligger som standard i ~/Library/Developer/Xcode/DerivedData, med en undermapp per projekt eller arbetsyta du någonsin öppnat.

Den växer av ett strukturellt skäl: Xcode skapar en DerivedData-mapp för varje projekt du öppnar — inklusive engångskloner du byggde en gång och aldrig rörde igen — och den raderar aldrig någon av dem. Varje mapp rymmer separata byggprodukter per konfiguration och mål (Debug och Release, simulator och enhet), så ett enda medelstort projekt kan uppta flera gigabyte, och mappen som helhet når vanligtvis 20–50 GB på en aktiv utvecklarmaskin.

Allt i den går per definition att återskapa — det är vad ”derived” betyder. Att radera DerivedData rör aldrig din källkod, dina projektinställningar eller något under versionshantering. Den enda kostnaden är tid: nästa bygge av varje projekt blir ett fullständigt rent bygge, och indexeringen körs igen i bakgrunden i några minuter.

Radera DerivedData

Det finns tre sätt att göra det, och de slutar på samma ställe. Xcodes kommando Clean Build Folder (Product > Clean Build Folder, eller Kommando-Skift-K) rensar bara byggprodukter för det projekt som är öppet just nu — användbart för att fixa ett konstigt bygge, men det flyttar knappt nålen för diskutrymmet. För att frigöra riktigt utrymme raderar du själva DerivedData-mapparna.

Att radera per projekt är det kirurgiska alternativet: behåll DerivedData för de två eller tre projekt du bygger dagligen och ta bort mapparna för allt annat. Att radera alltihop är det snabba alternativet, och det funkar det också — du betalar bara ombyggnadskostnaden för alla projekt på en gång.

1. Avsluta Xcode först. Att radera DerivedData medan Xcode körs kan lämna dess indexerare förvirrad, och filer Xcode har öppna raderas kanske inte rent.
2. Hitta mappen: i Xcode öppnar du Settings > Locations och klickar på den lilla pilen bredvid DerivedData-sökvägen för att visa den i Finder. Eller tryck Kommando-Skift-G i Finder och skriv in ~/Library/Developer/Xcode/DerivedData direkt.
3. Sortera projektundermapparna efter storlek, markera dem du vill bli av med (eller Kommando-A för allihop) och flytta dem till papperskorgen. Papperskorgen först är den tryggare vanan — du kan återställa direkt om du ångrar dig.
4. Från Terminal i stället: rm -rf ~/Library/Developer/Xcode/DerivedData raderar allt i ett svep. Det går snabbare än Finder för väldigt stora mappar, men läs noteringen nedan innan du använder det.
5. Öppna Xcode igen och bygg. Räkna med att det första bygget av varje projekt tar märkbart längre tid, och att ”Indexing” syns i aktivitetsfältet ett tag — båda är engångskostnader.

Var försiktig med rm -rf: det går förbi papperskorgen och raderar permanent, utan ångra. Skriv sökvägen exakt, kör det aldrig med sudo för den här uppgiften, och känner du dig inte hemma i Terminal gör Finder-vägen samma jobb — fast reversibelt.

Rensa gamla simulatorversioner

Simulatorer är oftast den näst största utrymmestjuven bland utvecklarfiler efter DerivedData. Varje iOS-, watchOS- eller tvOS-version du någonsin laddat ner upptar 5–8 GB, och varje simulerad enhet har sin egen datamapp under ~/Library/Developer/CoreSimulator/Devices. Har du varit med om några Xcode-uppgraderingar har du troligen körmiljöer för iOS-versioner du slutade bygga för för flera år sedan.

Den snabbaste vinsten är det inbyggda rensningskommandot: kör xcrun simctl delete unavailable i Terminal. Det raderar varje simulatorenhet vars körmiljö inte längre är installerad — de föräldralösa som gamla Xcode-versioner lämnat efter sig — och rör inget du fortfarande kan använda.

För själva körmiljöerna öppnar du Xcodes Settings > Platforms (kallas Components i äldre Xcode-versioner). Du ser varje installerad simulatorversion med dess storlek; markera en gammal och radera den. Behåll bara den senaste versionen per plattform om du inte aktivt testar på äldre OS-versioner.

Du kan också gallra enskilda simulerade enheter i Window > Devices and Simulators: byt till fliken Simulators, högerklicka på en enhet du aldrig använder — de sex identiska iPhone-modellerna med data från gamla testkörningar — och välj Delete. Varje enhets sparade data och appar följer med.

Arkiv, device support-filer och cacher

Arkiv samlas i ~/Library/Developer/Xcode/Archives varje gång du kör Product > Archive för att distribuera ett bygge. Varje arkiv innehåller ett komplett appbygge plus dess dSYM-felsökningssymboler, ofta 100 MB till 1 GB styck. Innan du raderar, känn till avvägningen: dSYM-filerna där inne är det som låter dig symbolicera kraschrapporter för exakt det bygget. Behåll arkiv för versioner som fortfarande är live på App Store eller TestFlight (eller bekräfta att App Store Connect har dSYM-filerna) och radera resten — tryggast är Xcodes Organizer (Window > Organizer > Archives), där du kan granska och radera dem med sammanhang.

iOS DeviceSupport, i ~/Library/Developer/Xcode/iOS DeviceSupport, rymmer felsökningssymboler som Xcode kopierar från varje fysisk iPhone eller iPad du någonsin anslutit — en mapp per iOS-version, vanligtvis 2–5 GB styck. Mappar för iOS-versioner som ingen av dina enheter längre kör är ren dödvikt: radera dem, och skulle du någon gång ansluta en enhet med den versionen igen kopierar Xcode helt enkelt om symbolerna (du ser ”Preparing debugger support” en gång). Motsvarande mappar finns även för watchOS- och tvOS-enheter.

Xcode har dessutom egna cacher under ~/Library/Caches/com.apple.dt.Xcode, och simulatorerna har sina i ~/Library/Developer/CoreSimulator/Caches — båda säkra att rensa när Xcode och Simulator-appen inte körs, och båda byggs om vid behov.

Pakethanterarcacher (SwiftPM, CocoaPods, npm, Homebrew)

Pakethanterare sparar varje beroende de någonsin laddat ner så att framtida installationer går snabbt. Det är god ingenjörskonst och dålig diskhygien: cacherna bara växer, och på en maskin som sett några års projekt summerar de tyst till 10–20 GB. Alla är säkra att rensa — värsta fallet är att din nästa installation laddar ner paketen igen.

Swift Package Manager cachar nedladdade paket i ~/Library/Caches/org.swift.swiftpm, och varje projekts upplösta utcheckningar ligger dessutom inuti dess DerivedData-mapp — så att rensa DerivedData rensar redan dem. Den delade cachen kan du radera från Finder, eller med rm -rf på den sökvägen.

CocoaPods förvarar sina nedladdade pods i ~/Library/Caches/CocoaPods. Det rena sättet att tömma den är det inbyggda kommandot: pod cache clean --all. Dina projekts Pods-mappar rörs inte; bara nedladdningscachen försvinner.

npm:s cache bor i ~/.npm och kan nå många gigabyte på en JavaScript-tung maskin. Kör npm cache clean --force för att tömma den (npm kräver flaggan eftersom cachen är självläkande och normalt aldrig behöver rensas — att radera den är ändå helt säkert). pnpm-användare kan köra pnpm store prune i stället.

Homebrew hamstrar gamla nedladdningar och inaktuella paketversioner. brew cleanup tar bort inaktuella versioner och gamla nedladdningar; brew cleanup --prune=all tömmer dessutom hela nedladdningscachen. Kör brew cleanup -n först om du vill ha en testkörningslista över vad som skulle försvinna.

Automatisera det

Allt ovan fungerar, men utvecklarskräp är ett löpband: DerivedData är tillbaka inom en vecka av normalt arbete, cacherna fylls på igen och varje Xcode-uppdatering strandar ännu en körmiljö. Om du hellre slipper köra sex manuella procedurer varje månad är det här delen värd att automatisera — med ett verktyg som visar sitt resonemang i stället för att tyst massradera.

AskClean behandlar utvecklarfiler som förstklassiga kategorier: en skanning specificerar Xcode DerivedData per projekt, gamla simulatorversioner (lästa via simctl, med den senaste per plattform bevarad), device support-filer och pakethanterarcacher för npm, SwiftPM, cargo, uv med flera. Den fångar också de nyare utrymmestjuvarna — Hugging Face- och Ollama-modellcacher — som den listar per modell och lämnar oförbockade som standard.

Varje objekt kommer med en förklaring — vad det är, om det går att bygga om, vad raderingen kostar — och inget körs förrän du bekräftar det. Raderingar hamnar i papperskorgen så att ett felklick är ett drag-och-släpp från ogjort, och din källkod, dina dokument och dina bilder rörs aldrig. Det är samma checklista som den här guiden, minus timmen av Terminal-arbete.

FAQ