AskClean

Eliminare DerivedData di Xcode e le cache di sviluppo in sicurezza

Team AskClean · Aggiornato 2026-11-02

DerivedData è la cartella di lavoro in cui Xcode conserva prodotti di build e indici, e può arrivare in silenzio a decine di gigabyte. Eliminarla è sicuro: esci da Xcode, rimuovi il contenuto di ~/Library/Developer/Xcode/DerivedData e Xcode ricostruirà tutto alla build successiva. Questa guida spiega come farlo e come gestire simulatori, archivi e cache dei pacchetti.

Eliminare DerivedData di Xcode e le cache di sviluppo in sicurezza
Come eliminare in sicurezza DerivedData di Xcode, rimuovere i vecchi runtime del simulatore e ripulire archivi, DeviceSupport e cache dei pacchetti sul Mac.

Che cos’è DerivedData e perché diventa così grande

DerivedData è la cartella in cui Xcode conserva tutto ciò che ricava dal tuo codice sorgente: oggetti intermedi di build, prodotti compilati, cache dei moduli, indici dei simboli per il completamento del codice e il salto alla definizione, log di build. Per impostazione predefinita si trova in ~/Library/Developer/Xcode/DerivedData, con una sottocartella per ogni progetto o workspace che hai aperto almeno una volta.

Cresce per un motivo strutturale: Xcode crea una cartella DerivedData per ogni progetto che apri, compresi i cloni compilati una volta sola e mai più toccati, e non le rimuove di sua iniziativa. Ogni cartella contiene prodotti di build distinti per configurazione e destinazione (Debug e Release, simulatore e dispositivo): misura quindi le sottocartelle dei progetti invece di dare per scontato quanto spazio recupererai.

Tutto ciò che contiene è rigenerabile per definizione: è proprio questo il senso di “derived” (derivato). Eliminare DerivedData non tocca mai il codice sorgente, le impostazioni del progetto né nulla di ciò che è sotto controllo di versione. L’unico costo è il tempo: la build successiva di ogni progetto riparte da zero e l’indicizzazione torna a girare in background per qualche minuto.

Elimina DerivedData

Il comando Clean Build Folder di Xcode (Product > Clean Build Folder, oppure Maiuscole-Comando-K) cancella solo i prodotti di build del progetto aperto: è utile per sistemare una build che si comporta in modo strano, ma sullo spazio su disco incide pochissimo. Per recuperare spazio davvero, elimina le cartelle DerivedData: puoi mostrarle dalle impostazioni Locations di Xcode, aprire la cartella nel Finder oppure rimuoverle dal Terminale. Tutte e tre le strade portano allo stesso risultato.

Eliminare progetto per progetto è l’opzione chirurgica: conserva DerivedData dei due o tre progetti che compili ogni giorno e rimuovi le cartelle di tutti gli altri. Eliminare tutto è l’opzione rapida, e va bene anche quella: paghi semplicemente il costo di una ricompilazione completa di tutti i progetti in una volta.

  1. Prima di tutto esci da Xcode. Se elimini DerivedData mentre Xcode è aperto, l’indicizzatore può andare in confusione e i file che Xcode tiene aperti potrebbero non venire eliminati del tutto.
  2. Trova la cartella: in Xcode apri Settings > Locations e fai clic sulla piccola freccia accanto al percorso di DerivedData per mostrarla nel Finder. In alternativa, 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 premi Comando-A per selezionarle tutte) e spostale nel Cestino. Passare prima dal Cestino è l’abitudine più prudente: se cambi idea, puoi ripristinarle subito.
  4. In alternativa, dal Terminale: rm -rf ~/Library/Developer/Xcode/DerivedData elimina tutto in un colpo solo. Con cartelle molto grandi è più veloce del Finder, ma prima di usarlo leggi la nota qui sotto.
  5. Riapri Xcode e compila. La prima build di ogni progetto richiederà sensibilmente più tempo e “Indexing” resterà visibile per un po’ nella barra delle attività: sono costi che paghi una volta sola.

Attenzione con rm -rf: salta il Cestino ed elimina in modo definitivo, senza possibilità di annullare. Digita il percorso esattamente, non usare mai sudo per questa operazione e, se non ti senti a tuo agio con il Terminale, passa dal Finder: fa lo stesso lavoro in modo reversibile.

Rimuovi i vecchi runtime del simulatore

I simulatori sono spesso un’altra voce importante dello spazio occupato dagli strumenti di sviluppo. Ogni runtime di iOS, watchOS o tvOS scaricato occupa il proprio spazio e ogni dispositivo simulato conserva i suoi dati in ~/Library/Developer/CoreSimulator/Devices. Se hai già attraversato qualche aggiornamento di Xcode, controlla i runtime delle versioni di sistema che non rientrano più nei tuoi test.

Il risultato più rapido arriva dal comando di pulizia integrato: esegui xcrun simctl delete unavailable nel Terminale. Elimina tutti i dispositivi simulati contrassegnati come unavailable (per lo più orfani lasciati da runtime rimossi e da vecchie versioni di Xcode) insieme alle app e ai dati che contengono. Prima controlla l’elenco con xcrun simctl list devices, soprattutto se hai installato più versioni di Xcode.

Per i runtime veri e propri, apri Settings > Components in Xcode (la sezione si chiama Platforms in Xcode 14–15). Vedrai ogni runtime del simulatore installato con la sua dimensione: seleziona quello vecchio ed eliminalo. Conserva solo il runtime più recente per ogni piattaforma, a meno che tu non faccia regolarmente test su versioni di sistema precedenti.

Puoi anche eliminare singoli dispositivi simulati da Window > Devices and Simulators: passa alla scheda Simulators, fai clic con il tasto destro su un dispositivo che non usi mai (magari uno dei sei modelli di iPhone duplicati, pieni di dati di vecchi test) e scegli Delete. Insieme al dispositivo spariscono anche i dati salvati e le app.

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 e i relativi simboli di debug dSYM, spesso tra 100 MB e 1 GB ciascuno. Prima di eliminarli, valuta il compromesso: i dSYM che contengono servono a simbolicare i report dei crash di quella build esatta. Conserva gli archivi delle versioni ancora disponibili su App Store o TestFlight (oppure 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 tutto il 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 collegato: una cartella per versione di iOS, in genere da 2 a 5 GB ciascuna. Le cartelle delle versioni di iOS che nessuno dei tuoi dispositivi usa più sono solo peso morto: eliminale. Se un giorno ricolleghi un dispositivo con quella versione, Xcode copierà di nuovo i simboli (vedrai una volta il messaggio “Preparing debugger support”). Esistono cartelle analoghe anche per i dispositivi watchOS e tvOS.

Xcode conserva anche le proprie cache in ~/Library/Caches/com.apple.dt.Xcode, mentre i simulatori tengono le loro in ~/Library/Developer/CoreSimulator/Caches. Entrambe vengono ricostruite quando servono, ma svuotale solo dopo aver chiuso Xcode e l’app Simulator e lascia stare i file di cache di CoreSimulator che non riconosci.

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

I package manager conservano le dipendenze scaricate per velocizzare le installazioni successive. È utile, ma su un Mac che ha visto anni di progetti può diventare una voce importante dello spazio occupato. Queste cache di download si possono ricostruire, ma alla prossima installazione i pacchetti andranno scaricati di nuovo.

Swift Package Manager tiene in cache i pacchetti scaricati in ~/Library/Caches/org.swift.swiftpm, e i checkout risolti di ogni progetto si trovano anche nella sua cartella DerivedData: svuotando DerivedData li elimini già. La cache condivisa puoi eliminarla dal Finder oppure con rm -rf su quel percorso.

CocoaPods conserva i pod scaricati in ~/Library/Caches/CocoaPods. Il modo corretto per svuotarla è il comando integrato pod cache clean --all. Le cartelle Pods dei tuoi progetti restano intatte: viene eliminata solo la cache dei download.

La cache di npm si trova in ~/.npm e, su un Mac usato molto per JavaScript, può arrivare a parecchi gigabyte. Esegui npm cache clean --force per svuotarla (npm richiede l’opzione perché la cache si autoripara e di norma non ha bisogno di essere pulita; eliminarla è comunque sicuro: i pacchetti vengono semplicemente scaricati di nuovo alla prossima installazione). Con pnpm puoi usare invece pnpm store prune.

Homebrew accumula vecchi download e versioni superate dei pacchetti. brew cleanup rimuove le versioni obsolete e i download datati e, se lo esegui su tutto senza indicare pacchetti, disinstalla anche le dipendenze che non servono più a nulla (a meno che non sia impostata HOMEBREW_NO_AUTOREMOVE); brew cleanup --prune=all svuota anche l’intera cache dei download. Esegui prima brew cleanup -n se vuoi l’elenco di ciò che verrebbe rimosso, senza eliminare nulla.

Automatizza la pulizia

Tutto ciò che hai letto finora funziona, ma con i file di sviluppo è un lavoro che non finisce mai: DerivedData si riforma dopo una settimana di lavoro normale, le cache si riempiono di nuovo e ogni aggiornamento di Xcode lascia indietro un altro runtime. Se non vuoi ripetere sei procedure manuali ogni mese, questa è la parte che vale la pena automatizzare, con uno strumento che spiega il proprio ragionamento invece di eliminare in blocco senza dire nulla.

AskClean tratta i file di sviluppo come categorie a sé: una sola scansione elenca DerivedData di Xcode progetto per progetto, i vecchi runtime del simulatore (letti tramite simctl, conservando il più recente per ogni piattaforma), i file di supporto dei dispositivi e le cache dei package manager di npm, SwiftPM, cargo, uv e altri. Individua anche i nuovi divoratori di spazio, i modelli di IA locali: elenca uno per uno i modelli di Hugging Face e mostra la libreria dei modelli Ollama come un unico elemento, tutti deselezionati per impostazione predefinita.

Ogni elemento è accompagnato da una spiegazione (che cos’è, se si può ricostruire, quanto costa eliminarlo) e non succede nulla finché non confermi. Gli elementi confermati vengono eliminati definitivamente, non spostati nel Cestino: controlla quindi ogni selezione prima di confermare. Il codice sorgente e la libreria di Foto non vengono mai toccati. È la stessa checklist di questa guida, senza l’ora di lavoro nel Terminale.

Cosa si può ricostruire e cosa no

Questa tabella indica i confini di ciò che puoi eliminare, non promette un risparmio valido per tutti. Misura il tuo Mac prima e dopo ogni intervento: lo script di controllo in sola lettura della guida sullo spazio dei simulatori Xcode mostra queste cartelle senza modificare nulla.

CategoriaPosizione predefinitaConseguenza dell’eliminazione
DerivedData~/Library/Developer/Xcode/DerivedDataViene ricompilato e reindicizzato; codice sorgente e cronologia Git restano intatti.
Dispositivi simulati~/Library/Developer/CoreSimulator/DevicesSi perdono app e dati di test dei dispositivi virtuali selezionati; eliminali con simctl o da Xcode.
Archivi~/Library/Developer/Xcode/ArchivesPossono sparire i dSYM necessari per simbolicare i crash; controlla prima nell’Organizer.
DeviceSupport~/Library/Developer/Xcode/iOS DeviceSupportI simboli di debug vengono copiati di nuovo quando ricolleghi un dispositivo con quella versione di sistema.

FAQ

È sicuro eliminare DerivedData?

Sì, è una delle eliminazioni di grandi dimensioni più sicure su un Mac. DerivedData contiene solo file che Xcode genera dal tuo codice: prodotti di build, cache dei moduli, indici e log. Il codice, i file di progetto e la cronologia Git si trovano altrove e non vengono mai toccati. L’unica conseguenza è che la build successiva di ogni progetto sarà una ricompilazione completa e l’indicizzazione ripartirà da capo.

Ogni quanto conviene svuotare DerivedData?

Non c’è una cadenza obbligatoria: svuotala quando è abbastanza grande da fare la differenza, il che per la maggior parte degli sviluppatori attivi significa ogni mese o due. Due situazioni la giustificano sempre: quando ti serve spazio su disco in fretta e quando un progetto mostra errori di build inspiegabili o un completamento del codice non aggiornato. In quei casi azzerare DerivedData è il classico primo rimedio.

Xcode sarà più lento dopo che avrò eliminato DerivedData?

Temporaneamente sì. La prima build di ogni progetto riparte da zero e può durare parecchie volte più di una build incrementale, e l’indicizzazione in background richiede qualche minuto prima che completamento del codice e ricerca tornino a funzionare a pieno regime. Dopo questo primo ciclo le prestazioni sono esattamente quelle di prima: DerivedData contiene cache, non ottimizzazioni che perdi per sempre.

E ~/Library/Developer/CoreSimulator? Posso eliminarla?

Non alla cieca: contiene i simulatori installati e i loro dati, ed eliminarla in blocco li rende inutilizzabili finché non reinstalli i runtime. Sfoltiscila invece nel modo corretto: esegui xcrun simctl delete unavailable per i dispositivi orfani (con loro spariscono anche app e dati), rimuovi i vecchi runtime in Settings > Components di Xcode, elimina i dispositivi inutilizzati in Devices and Simulators e svuota a mano solo la sottocartella Caches, dopo aver chiuso Xcode e Simulator.

Clean Build Folder fa la stessa cosa?

No. Product > Clean Build Folder (Maiuscole-Comando-K) cancella solo i prodotti di build del progetto corrente e lascia al loro posto indici, cache dei moduli e le cartelle di tutti gli altri progetti. È uno strumento per risolvere problemi di build, non per liberare spazio: per recuperare spazio davvero devi eliminare le cartelle DerivedData.

Fonti

Lo spazio per lo sviluppo, passo dopo passo