Xcode: Clean Build Folder eller radera DerivedData?
AskClean-teamet · Uppdaterad 2026-11-02
Clean Build Folder rensar byggprodukterna för det scheme du har öppet. Att radera DerivedData återställer mer: byggprodukter plus index, modulcacher och loggar. Börja med Clean Build Folder när ett bygge har gått sönder. Vid ett skadat index raderar du DerivedData-mappen för just det projektet, och behöver du verkligen diskutrymme raderar du DerivedData-mapparna för projekt som du inte längre bygger.
Skillnaden är omfattningen, inte grundligheten
Product > Clean Build Folder (Skift-Kommando-K) arbetar i det projekt och scheme som du har öppet just nu. Kommandot slänger kompilerade produkter och mellanresultat för det sammanhanget, så att nästa bygge utgår från källkoden. Det gäller ett enda projekt och behåller medvetet sådant som är dyrt att bygga om.
DerivedData är den gemensamma toppkatalogen för alla projekt som använder standardplatsen – ~/Library/Developer/Xcode/DerivedData, med en undermapp för varje projekt eller arbetsyta du någonsin har öppnat. Raderar du en undermapp återställs exakt det projektet. Raderar du hela katalogen måste alla dina projekt byggas och indexeras om nästa gång de öppnas.
Därför är det missvisande att beskriva dem som ”lätt rensning” och ”djuprensning”. Clean Build Folder är smalt och billigt; att radera DerivedData är brett och kostar dig indexet. Vilket som är rätt beror helt på om det som är trasigt finns i byggprodukterna eller utanför dem.
När ett bygge går sönder: börja med det minsta ingreppet
Dök felet upp direkt efter att du bytte gren, ändrade en byggkonfiguration eller redigerade resursfiler, avslutar du appen som körs och provar Clean Build Folder först. Det är den billigaste återställningen som finns, indexet bevaras och du kan jobba vidare efter ett bygge i stället för ett bygge plus flera minuters indexering.
Gå vidare till att radera projektets DerivedData-mapp när symtomen egentligen inte handlar om byggprodukter: Xcode visar fel för kod som du redan har rättat, ”Jump to Definition” hamnar på fel ställe eller kodkompletteringen har slutat förstå dina egna typer. Det är indexsymtom, och Clean Build Folder rör inte indexet.
Ett specialfall är värt att känna till, eftersom det är den vanligaste anledningen till att ”jag rensade och det hjälpte inte” blir ”jag raderade DerivedData och då fungerade det”: den förkompilerade modulcachen (ModuleCache.noindex) ligger i roten av DerivedData, inte i något projekts undermapp. Clean Build Folder når den aldrig. När modulcachen blir inaktuell efter ett byte av SDK eller verktygskedja försvinner felet bara om du tar bort den.
Inget av kommandona rättar ett verkligt fel i din källkod eller dina beroenden. Finns exakt samma fel kvar efter ett rent bygge ska du sluta rensa och läsa kompilatorns meddelande – orsaken finns i projektinställningarna, Package.resolved, det valda SDK:t eller i själva koden.
Inget av dem är en strategi för diskrensning
Clean Build Folder är ett felsökningsverktyg som råkar frigöra lite utrymme. Det kan ge tillbaka plats för det aktuella projektet, men alla andra projekts byggprodukter, alla index och modulcachen ligger kvar precis där de var. Att köra det för att frigöra diskutrymme är att mäta fel sak.
Är utrymme det egentliga målet gör du tvärtom: mät först undermapparna i DerivedData och radera sedan projekt som du inte har öppnat på flera månader. Det är där tiotals gigabyte brukar ligga – engångskloner som du byggde en gång och aldrig återvände till.
Börja inte med rm -rf. I Finder kan du flytta de valda mapparna till papperskorgen, där de går att återställa tills du tömmer den, och den skillnaden spelar roll första gången du raderar mappen för ett projekt som visar sig byggas just då. Terminalen är värd att använda för automatisering, men först när du har bekräftat den exakta sökvägen.
Kontrollera resultatet i stället för att lita på en siffra
Anteckna storleken på DerivedData innan du gör något, använd exakt ett av de två alternativen och mät sedan igen. Efter Clean Build Folder bygger du samma scheme igen. Efter att du har raderat en DerivedData-mapp öppnar du Xcode och väntar tills det första bygget och indexeringen är klara.
Gör du i den ordningen kan du skilja utrymmet du fick tillbaka från priset du betalade för det. Det finns ingen universell siffra att räkna med: resultatet beror på hur många projekt, konfigurationer och arkitekturer som har byggts på just den Macen.
Vilket ska du välja?
| Situation | Vad du gör | Kostnad för att återställa |
|---|---|---|
| Bygget misslyckas för aktuellt scheme | Product > Clean Build Folder | Ett nytt bygge av det här projektet. Indexen för alla projekt bevaras. |
| Inaktuella fel, ”Jump to Definition” fungerar inte | ~/Library/Developer/Xcode/DerivedData/<project> | Fullständigt ombygge plus ny indexering, bara för det projektet. |
| Felen finns kvar efter Clean Build Folder och ett SDK-byte | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | Modulerna kompileras om vid nästa bygge. Clean Build Folder når inte hit. |
| Du behöver verkligen diskutrymme | ~/Library/Developer/Xcode/DerivedData | Radera de stora, inaktuella undermapparna; de projekten byggs om nästa gång de öppnas. |
| Simulatorns gamla runtime-versioner | Xcode Settings > Components | En helt separat kategori. Inget av kommandona rör den. |
Tabellen beskriver omfattning, inte ett utlovat antal gigabyte. Mät din egen Mac före och efter.
Vanliga frågor
Raderar Clean Build Folder DerivedData?
Nej. Kommandot rensar byggprodukterna för det projekt och scheme du har öppet. Det motsvarar inte att radera den delade DerivedData-katalogen, som även innehåller index, modulcache och loggar för alla projekt.
Är det säkert att radera ett projekts DerivedData-mapp?
Ja. Allt i den härleds från din källkod och skapas om av Xcode. Din kod och Git-historik påverkas inte. Den enda kostnaden är att nästa bygge blir ett fullständigt bygge, följt av en indexering.
Måste jag avsluta Xcode först?
När du raderar DerivedData för hand, ja – då slipper du att indexeraren håller filer öppna eller skapar dem igen medan du tar bort dem. För det inbyggda kommandot Clean Build Folder behövs det inte; där rensar Xcode efter sig själv.
Varför finns felet kvar efter rensningen?
Troligen var cachen aldrig orsaken. Kontrollera kompilatorns meddelande, scheme-inställningarna, beroendeversionerna, Package.resolved, det valda SDK:t och vad som faktiskt har ändrats i din nuvarande gren.
Clean Build Folder hjälpte inte, men att radera DerivedData gjorde det. Varför?
Oftast på grund av den förkompilerade modulcachen. ModuleCache.noindex ligger i roten av DerivedData och inte i en projektundermapp, så Clean Build Folder når den inte – men det gör en radering av DerivedData.
Källor