Eliminare DerivedData di Xcode e le cache da sviluppatore in sicurezza

Cos'è DerivedData e perché diventa enorme

DerivedData è dove Xcode conserva tutto ciò che deriva dal tuo codice sorgente: oggetti di build intermedi, prodotti compilati, cache dei moduli, indici dei simboli per il completamento del codice e il salto alla definizione, e log di build. Di default vive in ~/Library/Developer/Xcode/DerivedData, con una sottocartella per ogni progetto o workspace che hai mai aperto.

Cresce per una ragione strutturale: Xcode crea una cartella DerivedData per ogni progetto che apri — compresi i cloni una tantum che hai compilato una volta sola e mai più toccato — e non ne elimina mai nessuna. Ogni cartella contiene prodotti di build separati per configurazione e destinazione (Debug e Release, simulatore e dispositivo), quindi un singolo progetto di medie dimensioni può occupare svariati gigabyte, e la cartella nel suo insieme arriva comunemente a 20-50 GB su una macchina da sviluppo in uso.

Tutto ciò che contiene è rigenerabile per definizione: è proprio questo che significa “derived”. Eliminare DerivedData non tocca mai il tuo codice sorgente, le impostazioni del progetto o qualunque cosa sotto controllo di versione. L'unico costo è il tempo: la build successiva di ogni progetto è una build pulita completa, e l'indicizzazione riparte in background per qualche minuto.

Elimina DerivedData

Ci sono tre modi per farlo, e portano tutti allo stesso punto. Il comando Clean Build Folder di Xcode (Product > Clean Build Folder, o Comando-Maiuscole-K) ripulisce solo i prodotti di build del progetto attualmente aperto — utile per sistemare una build che fa le bizze, ma sposta a malapena l'ago dello spazio su disco. Per recuperare spazio vero, elimina direttamente le cartelle di DerivedData.

Eliminare progetto per progetto è l'opzione chirurgica: tieni la DerivedData dei due o tre progetti su cui compili ogni giorno e rimuovi le cartelle di tutto il resto. Eliminare tutto è l'opzione rapida, e va benissimo anche quella: semplicemente paghi il costo della ricompilazione completa su tutti i progetti in una volta.

1. Prima di tutto esci da Xcode. Eliminare DerivedData mentre Xcode è in esecuzione può mandare in confusione il suo indicizzatore, e i file che Xcode tiene aperti potrebbero non eliminarsi in modo pulito.
2. Trova la cartella: in Xcode apri Settings > Locations e fai clic sulla freccina accanto al percorso di DerivedData per mostrarla nel Finder. Oppure nel Finder premi Comando-Maiuscole-G e inserisci direttamente ~/Library/Developer/Xcode/DerivedData.
3. Ordina le sottocartelle dei progetti per dimensione, seleziona quelle da eliminare (o Comando-A per tutte) e spostale nel Cestino. Passare prima dal Cestino è l'abitudine più prudente: puoi ripristinare all'istante se cambi idea.
4. Da Terminale, in alternativa: rm -rf ~/Library/Developer/Xcode/DerivedData elimina tutto in un colpo solo. È più veloce del Finder per cartelle molto grandi, ma leggi la nota qui sotto prima di usarlo.
5. Riapri Xcode e compila. Aspettati che la prima build di ogni progetto duri sensibilmente di più e che “Indexing” resti nella barra di attività per un po': sono entrambi costi una tantum.

Fai attenzione con rm -rf: salta il Cestino ed elimina in modo definitivo, senza possibilità di annullare. Digita il percorso esattamente, non eseguirlo mai con sudo per questo compito, e se non ti senti a tuo agio nel Terminale, la strada del Finder fa lo stesso lavoro in modo reversibile.

Ripulisci i vecchi runtime del simulatore

I simulatori sono di solito il secondo divoratore di spazio da sviluppatore dopo DerivedData. Ogni runtime di iOS, watchOS o tvOS che hai scaricato nel tempo occupa 5-8 GB, e ogni dispositivo simulato tiene la propria cartella dati sotto ~/Library/Developer/CoreSimulator/Devices. Se hai attraversato qualche aggiornamento di Xcode, è probabile che tu abbia runtime per versioni di iOS che hai smesso di supportare anni fa.

La vittoria più rapida è il comando di pulizia integrato: esegui xcrun simctl delete unavailable nel Terminale. Elimina ogni dispositivo simulato il cui runtime non è più installato — gli orfani lasciati indietro dalle vecchie versioni di Xcode — e non tocca nulla che tu possa ancora usare.

Per i runtime veri e propri, apri Settings > Platforms di Xcode (chiamato Components nelle versioni meno recenti di Xcode). Vedrai ogni runtime del simulatore installato con la sua dimensione; seleziona quelli vecchi ed eliminali. Tieni solo il runtime più recente per piattaforma, a meno che tu non faccia test attivi su versioni precedenti del sistema.

Puoi anche sfoltire i singoli dispositivi simulati in Window > Devices and Simulators: passa alla scheda Simulators, fai clic con il tasto destro su qualunque dispositivo che non usi mai — i sei modelli di iPhone duplicati con dati di vecchie sessioni di test — e scegli Delete. I dati salvati e le app di ciascun dispositivo spariscono con lui.

Archivi, file di supporto dei dispositivi e cache

Gli archivi si accumulano in ~/Library/Developer/Xcode/Archives ogni volta che esegui Product > Archive per distribuire una build. Ogni archivio contiene una build completa dell'app più i suoi simboli di debug dSYM, spesso da 100 MB a 1 GB l'uno. Prima di eliminare, conosci il compromesso: i dSYM al suo interno sono ciò che ti permette di simbolicare i report dei crash di quella build esatta. Conserva gli archivi delle versioni ancora attive sull'App Store o su TestFlight (o verifica che App Store Connect abbia i dSYM) ed elimina il resto — la strada più sicura è l'Organizer di Xcode (Window > Organizer > Archives), dove puoi esaminarli ed eliminarli con il giusto contesto.

iOS DeviceSupport, in ~/Library/Developer/Xcode/iOS DeviceSupport, contiene i simboli di debug che Xcode copia da ogni iPhone o iPad fisico che hai mai collegato — una cartella per versione di iOS, tipicamente 2-5 GB ciascuna. Le cartelle di versioni di iOS che nessuno dei tuoi dispositivi usa più sono puro peso morto: eliminale, e se un giorno ricolleghi un dispositivo con quella versione, Xcode ricopia semplicemente i simboli (vedrai “Preparing debugger support” una volta). Esistono cartelle gemelle anche per i dispositivi watchOS e tvOS.

Xcode tiene anche le proprie cache sotto ~/Library/Caches/com.apple.dt.Xcode, e i simulatori tengono le loro in ~/Library/Developer/CoreSimulator/Caches — entrambe sicure da svuotare quando Xcode e l'app Simulator non sono in esecuzione, ed entrambe ricostruite al bisogno.

Cache dei package manager (SwiftPM, CocoaPods, npm, Homebrew)

I package manager conservano ogni dipendenza che hanno mai scaricato, così le installazioni future sono veloci. È buona ingegneria e pessima igiene del disco: le cache non fanno che crescere, e su una macchina che ha visto qualche anno di progetti arrivano in silenzio a 10-20 GB. Sono tutte sicure da svuotare — nel peggiore dei casi la tua prossima installazione riscarica i pacchetti.

Swift Package Manager mette in cache i pacchetti scaricati in ~/Library/Caches/org.swift.swiftpm, e i checkout risolti di ogni progetto vivono anche dentro la sua cartella DerivedData — quindi svuotare DerivedData li ripulisce già. La cache condivisa puoi eliminarla dal Finder, o con rm -rf su quel percorso.

CocoaPods tiene i pod scaricati in ~/Library/Caches/CocoaPods. Il modo pulito per svuotarla è il comando integrato: pod cache clean --all. Le cartelle Pods dei tuoi progetti restano intatte; se ne va solo la cache dei download.

La cache di npm vive in ~/.npm e su una macchina piena di JavaScript può raggiungere parecchi gigabyte. Esegui npm cache clean --force per svuotarla (npm pretende il flag perché la cache si autoripara e normalmente non ha mai bisogno di pulizia — eliminarla resta comunque perfettamente sicuro). Chi usa pnpm può eseguire invece pnpm store prune.

Homebrew accumula vecchi download e versioni superate dei pacchetti. brew cleanup rimuove le versioni obsolete e i download stantii; brew cleanup --prune=all svuota anche l'intera cache dei download. Esegui prima brew cleanup -n se vuoi una lista di prova di ciò che verrebbe eliminato.

Automatizzalo

Tutto quanto sopra funziona, ma la zavorra da sviluppatore è un tapis roulant: DerivedData torna entro una settimana di lavoro normale, le cache si riempiono di nuovo e ogni aggiornamento di Xcode abbandona un altro runtime. Se preferisci non ripetere sei procedure manuali ogni mese, questa è la parte che vale la pena automatizzare — con uno strumento che mostra il proprio ragionamento invece di eliminare in blocco in silenzio.

AskClean tratta i file da sviluppatore come categorie di prima classe: una sola scansione dettaglia la DerivedData di Xcode progetto per progetto, i vecchi runtime del simulatore (letti tramite simctl, conservando il più recente per piattaforma), i file di supporto dei dispositivi e le cache dei package manager per npm, SwiftPM, cargo, uv e altri. Intercetta anche i nuovi divoratori di spazio — le cache dei modelli di Hugging Face e Ollama — che elenca modello per modello e lascia deselezionate di default.

Ogni elemento arriva con una spiegazione — cos'è, se può essere ricostruito, cosa costa eliminarlo — e niente parte finché non lo confermi tu. Le eliminazioni vanno nel Cestino, così un clic sbagliato si annulla con un trascinamento, e codice sorgente, documenti e foto non vengono mai toccati. È la stessa checklist di questa guida, senza l'ora di lavoro nel Terminale.

FAQ