Xcode: Clean Build Folder o eliminare DerivedData?
Team AskClean · Aggiornato 2026-11-02
Clean Build Folder cancella i prodotti di build dello schema che hai aperto. Eliminare DerivedData azzera un insieme più ampio: i prodotti di build più indici, cache dei moduli e log. Se una build si rompe, parti da Clean Build Folder; se l’indice è danneggiato, elimina la cartella DerivedData di quel solo progetto; per liberare davvero spazio su disco, elimina le cartelle DerivedData dei progetti che non compili più.
La differenza sta nella portata, non nella profondità
Product > Clean Build Folder (Maiuscole-Comando-K) agisce all’interno del progetto e dello schema che hai aperto. Scarta i prodotti compilati e i file intermedi di quel contesto, così la build successiva riparte dal codice sorgente. Riguarda un solo progetto e conserva di proposito ciò che è costoso da ricostruire.
DerivedData è la cartella principale condivisa da tutti i progetti che usano la posizione predefinita: ~/Library/Developer/Xcode/DerivedData, con una sottocartella per ogni progetto o workspace che hai aperto almeno una volta. Eliminare una sottocartella azzera esattamente quel progetto. Eliminare l’intera cartella costringe tutti i tuoi progetti a essere ricompilati e reindicizzati alla prossima apertura.
A dirla tutta, quindi, non si tratta di “pulizia leggera” contro “pulizia profonda”. Clean Build Folder è mirato ed economico; eliminare DerivedData è ampio e ti costa l’indice. Quale scegliere dipende solo da dove si trova ciò che si è rotto: dentro i prodotti di build o fuori.
Quando una build si rompe, parti dall’intervento più mirato
Se l’errore è comparso subito dopo aver cambiato branch, modificato una configurazione di build o i file di risorse, chiudi l’app in esecuzione e usa prima Clean Build Folder. È il reset più economico che hai a disposizione, conserva l’indice e ti rimette al lavoro con una sola build, invece di una build più diversi minuti di indicizzazione.
Passa a eliminare la cartella DerivedData di quel progetto quando i sintomi non riguardano davvero i prodotti di build: Xcode segnala errori in codice che hai già corretto, Jump to Definition ti porta nel punto sbagliato, il completamento del codice non riconosce più i tuoi tipi. Sono sintomi dell’indice, e Clean Build Folder l’indice non lo tocca.
C’è un caso specifico che vale la pena conoscere, perché è il motivo tipico per cui “ho fatto il clean e non è servito” diventa “ho eliminato DerivedData e ha funzionato”: la cache dei moduli precompilati (ModuleCache.noindex) si trova nella radice di DerivedData, non nella sottocartella di un progetto. Clean Build Folder non la raggiunge mai. Quando una cache dei moduli diventa obsoleta dopo un cambio di SDK o di toolchain, l’errore sparisce solo rimuovendola.
Nessuno dei due comandi corregge un vero bug nel codice o nelle dipendenze. Se lo stesso identico errore sopravvive a una build pulita, smetti di pulire e leggi il messaggio del compilatore: la causa sta nelle impostazioni del progetto, in Package.resolved, nell’SDK selezionato o nel codice stesso.
Nessuno dei due è una strategia per liberare spazio
Clean Build Folder è uno strumento diagnostico che, per inciso, libera qualche byte. Può restituire spazio per il progetto corrente, ma i prodotti di build di tutti gli altri progetti, ogni indice e la cache dei moduli restano esattamente dove sono. Usarlo per recuperare spazio su disco significa misurare la cosa sbagliata.
Se il vero obiettivo è lo spazio, procedi al contrario: misura prima le sottocartelle di DerivedData, poi elimina quelle dei progetti che non apri da mesi. Di solito le decine di gigabyte sono lì: cloni compilati una volta e mai più riaperti.
Non partire da rm -rf. Il Finder ti permette di spostare le cartelle selezionate nel Cestino, da cui puoi recuperarle finché non lo svuoti, e questa differenza conta la prima volta che elimini la cartella di un progetto che, si scopre, è in compilazione proprio in quel momento. Il Terminale ha senso per automatizzare, ma solo dopo aver verificato il percorso esatto.
Verifica il risultato invece di fidarti di un numero
Annota le dimensioni di DerivedData prima di fare qualsiasi cosa, applica una sola delle due opzioni, poi misura di nuovo. Dopo Clean Build Folder, compila lo schema corrente. Dopo aver eliminato una cartella DerivedData, apri Xcode e attendi che la prima build e l’indicizzazione siano terminate.
Procedendo in quest’ordine distingui lo spazio recuperato dal prezzo pagato per recuperarlo. Non c’è una cifra universale da aspettarsi: il risultato dipende da quanti progetti, configurazioni e architetture sono stati compilati su quel Mac.
Quale strada scegliere
| Situazione | Cosa fare | Costo del ripristino |
|---|---|---|
| La build dello schema corrente non riesce | Product > Clean Build Folder | Una ricompilazione di questo progetto. Gli indici di tutti i progetti restano intatti. |
| Errori già corretti ancora segnalati, Jump to Definition che sbaglia | ~/Library/Developer/Xcode/DerivedData/<project> | Ricompilazione completa più reindicizzazione, solo per quel progetto. |
| Gli errori restano dopo Clean Build Folder e un cambio di SDK | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | I moduli vengono ricompilati alla build successiva. Clean Build Folder non arriva fin qui. |
| Ti serve davvero spazio su disco | ~/Library/Developer/Xcode/DerivedData | Elimina le sottocartelle grandi e inutilizzate; quei progetti verranno ricompilati alla prossima apertura. |
| Vecchi runtime del simulatore | Xcode Settings > Components | È una categoria del tutto separata: nessuno dei due comandi la tocca. |
La tabella descrive la portata di ciascuna azione, non promette un numero di gigabyte. Misura il tuo Mac prima e dopo.
FAQ
Clean Build Folder elimina DerivedData?
No. Cancella i prodotti di build del progetto e dello schema che hai aperto. Non equivale a eliminare la cartella condivisa DerivedData, che contiene anche indici, cache dei moduli e log di tutti i progetti.
È sicuro eliminare la cartella DerivedData di un progetto?
Sì. Tutto ciò che contiene deriva dal tuo codice sorgente e Xcode lo rigenera. Il codice e la cronologia Git restano intatti. L’unico costo è che la prima build successiva sarà completa e verrà seguita da una nuova indicizzazione.
Devo chiudere prima Xcode?
Se elimini DerivedData a mano, sì: eviti che l’indicizzatore tenga aperti o ricrei i file mentre li rimuovi. Per il comando integrato Clean Build Folder no: è Xcode stesso a eseguirlo.
Perché l’errore c’è ancora dopo la pulizia?
Molto probabilmente la causa non è mai stata la cache. Controlla il messaggio del compilatore, le impostazioni dello schema, le versioni delle dipendenze, Package.resolved, l’SDK selezionato e che cosa è cambiato davvero nel branch su cui lavori.
Clean Build Folder non è servito, eliminare DerivedData sì. Perché?
Di solito per colpa della cache dei moduli precompilati. ModuleCache.noindex si trova nella radice di DerivedData e non nella sottocartella di un progetto: Clean Build Folder non può raggiungerla, eliminando DerivedData invece la rimuovi.
Fonti