Come disinstallare completamente Xcode su Mac senza perdere progetti o dSYM
Team AskClean · Aggiornato 2026-09-01
Prima di rimuovere completamente Xcode, esegui il backup dei progetti e conserva Archives e dSYM ancora necessari per build distribuite. Poi sposta l’app nel Cestino e controlla separatamente DerivedData, simulatori, DeviceSupport e strumenti da riga di comando.

Proteggi i dati non ricostruibili prima della disinstallazione
Le cartelle dei progetti non sono residui di Xcode. Proteggi repository, file non sottoposti a commit, pacchetti locali e risorse. Conserva Archives/dSYM delle versioni ancora attive su App Store, TestFlight o presso clienti e gli stati Simulator necessari.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
Rimuovi l’app con il metodo usato per installarla
Chiudi Xcode e Simulator e sposta nel Cestino la Xcode.app corretta dal Finder. Non cancellare automaticamente /Library/Developer/CommandLineTools: Git, Homebrew, clang e script di build potrebbero usarli ancora.
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.
Verifica tutto prima di svuotare il Cestino
Ricontrolla Applications, processi e xcode-select -p. Conferma che progetti, Archives/dSYM necessari e dati Simulator siano presenti prima di svuotare il Cestino. System Data può aggiornarsi in ritardo.
Mappa di sicurezza della disinstallazione completa
Rimuovi Xcode distinguendo cache ricostruibili, Archives, DeviceSupport, dati Simulator e Command Line Tools.
| Decisione | Dove controllare o intervenire | Conseguenza e verifica |
|---|---|---|
| Proteggi i dati non ricostruibili prima della disinstallazione | Projects / Xcode Organizer / Archives | Le cartelle dei progetti non sono residui di Xcode. Proteggi repository, file non sottoposti a commit, pacchetti locali e risorse. Conserva Archives/dSYM delle versioni ancora attive su App Store, TestFlight o presso clienti e gli stati Simulator necessari. |
| Rimuovi l’app con il metodo usato per installarla | /Applications/Xcode.app / Finder | Chiudi Xcode e Simulator e sposta nel Cestino la Xcode.app corretta dal Finder. Non cancellare automaticamente /Library/Developer/CommandLineTools: Git, Homebrew, clang e script di build potrebbero usarli ancora. |
| Verifica tutto prima di svuotare il Cestino | xcode-select -p / Activity Monitor | Ricontrolla Applications, processi e xcode-select -p. Conferma che progetti, Archives/dSYM necessari e dati Simulator siano presenti prima di svuotare il Cestino. System Data può aggiornarsi in ritardo. |
FAQ
Posso eliminare tutto ~/Library/Developer?
No. Contiene sia DerivedData ricostruibile sia Archives/dSYM, DeviceSupport, runtime e stati Simulator; valuta ogni categoria separatamente.
È sicuro eliminare DerivedData?
Sì — è una delle eliminazioni pesanti più sicure su un Mac. DerivedData contiene solo file che Xcode genera dal tuo sorgente: prodotti di build, cache dei moduli, indici e log. Il tuo codice, i file di progetto e la cronologia git vivono altrove e non vengono mai toccati. L'unica conseguenza è che la build successiva di ogni progetto è una ricompilazione completa e l'indicizzazione riparte da capo.
Ogni quanto dovrei svuotare DerivedData?
Non c'è una cadenza obbligata: svuotala quando è abbastanza grande da contare, il che per la maggior parte degli sviluppatori attivi significa ogni mese o due. Due momenti la giustificano sempre: quando ti serve spazio su disco in fretta, e quando un progetto mostra errori di build inspiegabili o completamento del codice stantio, casi in cui azzerare DerivedData è la classica prima mossa.
Fonti