Radera Xcode DerivedData och utvecklarcacher tryggt

Vad DerivedData är och varför den blir så stor

I DerivedData sparar Xcode allt som härleds ur din källkod: mellanliggande byggobjekt, kompilerade produkter, modulcacher, symbolindex för kodkomplettering och ”Jump to Definition” samt byggloggar. Mappen ligger som standard i ~/Library/Developer/Xcode/DerivedData, med en undermapp för varje projekt eller arbetsyta du någonsin har öppnat.

Den växer av ett strukturellt skäl: Xcode skapar en DerivedData-mapp för varje projekt du öppnar – även engångskloner som du byggde en gång och sedan aldrig rörde – och tar inte bort dem på eget initiativ. Varje mapp innehåller separata byggprodukter per konfiguration och mål (Debug och Release, simulator och enhet), så mät projektundermapparna i stället för att gissa hur mycket utrymme din Mac kan få tillbaka.

Allt i den går per definition att återskapa – det är vad ”derived” (härledd) 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 helt rent bygge, och indexeringen körs igen i bakgrunden i några minuter.

Radera DerivedData

Xcodes kommando Clean Build Folder (Product > Clean Build Folder eller Skift-Kommando-K) rensar bara byggprodukterna för det projekt som är öppet just nu – användbart när ett bygge beter sig konstigt, men det märks knappt på diskutrymmet. För att frigöra verkligt utrymme raderar du själva DerivedData-mapparna: visa dem via Settings > Locations i Xcode, gå till mappen i Finder eller ta bort dem i Terminal. Alla tre vägarna leder till samma resultat.

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 allt är det snabba alternativet, och det går också bra – du betalar bara kostnaden för att bygga om alla projekt på en gång.

1. Avsluta Xcode först. Raderar du DerivedData medan Xcode körs kan indexeraren bli förvirrad, och filer som Xcode har öppna kanske inte raderas ordentligt.
2. Hitta mappen: öppna Settings > Locations i Xcode och klicka på den lilla pilen bredvid DerivedData-sökvägen för att visa den i Finder. Du kan också trycka på Skift-Kommando-G i Finder och skriva ~/Library/Developer/Xcode/DerivedData direkt.
3. Sortera projektundermapparna efter storlek, markera dem du vill bli av med (eller tryck på Kommando-A för att markera alla) och flytta dem till papperskorgen. Att gå via papperskorgen är den säkrare vanan – du kan återställa direkt om du ångrar dig.
4. Via Terminal i stället: rm -rf ~/Library/Developer/Xcode/DerivedData raderar allt på en gång. Det går snabbare än Finder för mycket stora mappar, men läs anmärkningen nedan innan du använder kommandot.
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” visas i aktivitetsfältet en stund – båda är engångskostnader.

Var försiktig med rm -rf: kommandot går förbi papperskorgen och raderar permanent, utan möjlighet att ångra. Skriv sökvägen exakt, kör det aldrig med sudo för den här uppgiften, och känner du dig osäker i Terminal gör Finder samma jobb – på ett sätt som går att ångra.

Rensa simulatorns gamla runtime-versioner

Simulatorer är ofta ännu en stor kategori i utvecklarlagringen. Varje hämtad runtime för iOS, watchOS eller tvOS tar sin egen plats, och varje simulerad enhet sparar data under ~/Library/Developer/CoreSimulator/Devices. Har du gått igenom några Xcode-uppgraderingar bör du granska runtime-versioner för systemversioner som inte längre ingår i dina tester.

Den snabbaste vinsten är det inbyggda rensningskommandot: kör xcrun simctl delete unavailable i Terminal. Det raderar alla simulatorenheter som är märkta unavailable – oftast föräldralösa enheter vars runtime har tagits bort eller som en gammal Xcode-version har lämnat efter sig – tillsammans med apparna och data i dem. Gå först igenom listan med xcrun simctl list devices, särskilt om du har mer än en Xcode-version installerad.

För själva runtime-versionerna öppnar du Settings > Components i Xcode (heter Platforms i Xcode 14–15). Där ser du varje installerad simulator-runtime med storlek; markera en gammal och radera den. Behåll bara den senaste runtime-versionen per plattform om du inte aktivt testar på äldre systemversioner.

Du kan också rensa enskilda simulerade enheter i Window > Devices and Simulators: välj fliken Simulators, högerklicka på en enhet du aldrig använder – till exempel sex likadana iPhone-modeller med data från gamla testkörningar – och välj Delete. Enhetens sparade data och appar försvinner tillsammans med den.

Arkiv, DeviceSupport-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. Känn till avvägningen innan du raderar: dSYM-filerna i arkivet är det som gör att du kan symbolicera kraschrapporter för exakt det bygget. Behåll arkiv för versioner som fortfarande finns i App Store eller TestFlight (eller kontrollera att App Store Connect har dSYM-filerna) och radera resten – säkrast i Xcodes Organizer (Window > Organizer > Archives), där du kan granska och radera dem med sammanhanget framför dig.

iOS DeviceSupport, i ~/Library/Developer/Xcode/iOS DeviceSupport, innehåller felsökningssymboler som Xcode kopierar från varje fysisk iPhone eller iPad du någonsin har 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 ansluter du någon gång en enhet med den versionen igen kopierar Xcode helt enkelt symbolerna på nytt (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 byggs upp igen vid behov, men rensa dem bara när Xcode och appen Simulator är avslutade, och låt CoreSimulator-cachefiler som du inte känner igen vara kvar.

Pakethanterarnas cacher (SwiftPM, CocoaPods, npm, Homebrew)

Pakethanterare sparar hämtade beroenden så att framtida installationer går snabbt. Det är praktiskt, men på en dator som har sett flera års projekt kan cacherna ändå ta mycket plats. Nedladdningscacherna går att återskapa, men nästa installation måste hämta paketen igen.

Swift Package Manager cachar hämtade paket i ~/Library/Caches/org.swift.swiftpm, och varje projekts upplösta checkouts ligger dessutom i projektets DerivedData-mapp – så när du rensar DerivedData försvinner de redan. Den delade cachen kan du radera i Finder eller med rm -rf på den sökvägen.

CocoaPods sparar sina hämtade 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 ligger i ~/.npm och kan bli många gigabyte på en dator med mycket JavaScript. 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 säkert – paketen hämtas helt enkelt igen vid nästa installation). Med pnpm kan du köra pnpm store prune i stället.

Homebrew samlar på sig gamla hämtningar och inaktuella paketversioner. brew cleanup tar bort inaktuella versioner och gamla hämtningar, och en global körning avinstallerar dessutom beroenden som inget längre behöver (om inte HOMEBREW_NO_AUTOREMOVE är satt); brew cleanup --prune=all tömmer även hela nedladdningscachen. Kör brew cleanup -n först om du vill se en torrkörningslista över vad som skulle försvinna.

Automatisera det

Allt ovan fungerar, men utvecklarskräp är ett ekorrhjul: DerivedData är tillbaka efter en veckas normalt arbete, cacherna fylls på igen och varje Xcode-uppdatering lämnar ännu en runtime efter sig. Vill du slippa upprepa sex manuella procedurer varje månad är det här delen som är värd att automatisera – med ett verktyg som visar sitt resonemang i stället för att tyst massradera.

AskClean behandlar utvecklarfiler som egna kategorier: en skanning listar Xcode DerivedData per projekt, simulatorns gamla runtime-versioner (lästa via simctl, där den senaste per plattform behålls), DeviceSupport-filer och pakethanterarcacher för npm, SwiftPM, cargo, uv med flera. Den hittar också de nyare utrymmestjuvarna – lokala AI-modeller – och listar Hugging Face-modeller en och en och Ollamas modellbibliotek som ett enda objekt, alla omarkerade som standard.

Varje objekt har en förklaring – vad det är, om det kan byggas om och vad raderingen kostar – och inget körs förrän du bekräftar. Bekräftade objekt raderas permanent i stället för att flyttas till papperskorgen, så granska varje val innan du bekräftar; din källkod och ditt bildbibliotek rörs aldrig. Det är samma checklista som i den här guiden, minus timmen i Terminal.

Vad som kan byggas om – och vad som inte kan det

Tabellen visar var raderingsgränserna går, inte hur mycket du sparar. Mät din Mac före och efter varje åtgärd – granskningsskriptet i guiden om lagringen för Xcode Simulator redovisar de här mapparna utan att ändra något.

Vanliga frågor