# Pulire Xcode senza perdere gli artefatti di release

> Separa DerivedData, dispositivi del simulatore, runtime, DeviceSupport e archivi di release prima di liberare spazio di Xcode.

Published: 2026-07-12 | Updated: 2026-08-08

Xcode distribuisce lo spazio su disco tra output di build, indici, archive, supporto dispositivi, simulatori e runtime di piattaforma scaricabili. Parte di questi dati è riproducibile; parte è l'unica copia di un'archive di release o dei suoi dSYM. L'approccio sicuro è misurare ogni categoria, rimuoverla tramite Xcode quando possibile e conservare gli artefatti legati alle build distribuite.

## Dove finiscono i gigabyte di Xcode

Parti dalle due radici principali a livello utente:

```
du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h
```

I soliti grandi consumatori di spazio sono:

- **DerivedData**: prodotti di build, indici e cache dei moduli, di solito una cartella per progetto. È ricostruibile, ma una pulizia completa rende costosi i successivi indici e le build. Parti prima dal progetto obsoleto.
- **DeviceSupport**: simboli e artefatti di supporto acquisiti per dispositivi fisici e versioni di OS. Le voci più vecchie possono ancora servire per la simbolizzazione dei crash.
- **Archives**: build salvate ogni volta che hai esportato o distribuito un'app. Apple consiglia di conservare l'archive per ogni build distribuita, perché i binari e i file dSYM corrispondenti possono essere necessari per diagnosticare crash successivi. Le archive di build che non hanno mai lasciato il Mac sono le candidate più sicure alla pulizia.
- **Simulator devices e platform runtimes**: i dispositivi vivono sotto CoreSimulator, mentre i runtime scaricabili sono gestiti come componenti di Xcode. Non sono un'unica cache.

## Come svuotare ogni area in sicurezza

**DerivedData** si gestisce al meglio per progetto. Chiudi Xcode, usa **Xcode > Settings > Locations** per rivelare Derived Data, individua la cartella del progetto obsoleto e spostala nel Cestino. Svuota tutto solo quando un problema globale di indici o di build giustifica il costo della ricostruzione.

**I simulatori non disponibili** hanno un comando dedicato:

```
xcrun simctl delete unavailable
```

Questo rimuove i record di dispositivi i cui runtime non sono disponibili; non disinstalla le immagini dei runtime. Usa **Xcode > Settings > Components** per ispezionare le piattaforme e i runtime del simulatore installati, con le dimensioni recuperabili, poi rimuovi i runtime che puoi scaricare di nuovo. La [guida ai componenti di Xcode](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components) di Apple documenta lo stesso percorso di rimozione gestita. Usa **Window > Devices and Simulators** per i record dei dispositivi.

Rivedi le Archives in **Window > Organizer**. Conserva archive e dSYM per ogni build distribuita, comprese le versioni di produzione più vecchie ancora in uso. La [guida alle informazioni di debug](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information) di Apple osserva che binari e dSYM funzionano insieme solo quando i loro UUID di build coincidono. Anche DeviceSupport merita una revisione selettiva, non una cancellazione indiscriminata.

Chiudi Xcode prima di spostare DerivedData, così indici e database di build non vengono interrotti a metà scrittura. Al prossimo avvio e alla prossima build attenditi re-indicizzazione, risoluzione delle dipendenze e ricreazione dell'output; la durata dipende dal progetto e da ciò che resta disponibile.

## Dietro le quinte: perché DerivedData è sicuro e DeviceSupport non è la stessa cosa

DerivedData è output riproducibile di build e indici. Per ogni progetto Xcode crea una cartella con un hash del percorso del progetto e la riempie di oggetti compilati, cache dei moduli, indici e prodotti di build derivati da sorgenti, impostazioni, toolchain e dipendenze. Eliminala e Xcode ricostruisce ciò che resta disponibile, il che può richiedere tempo e accesso di rete. DeviceSupport è diverso per natura: quando esegui il debug su un dispositivo fisico, Xcode acquisisce dati di supporto e simboli per quella build di OS. Anche i dispositivi del simulatore e le immagini dei runtime sono oggetti gestiti distinti, non semplici cartelle di cache. Le Archives sono l'insieme da conservare selettivamente, perché contengono i dSYM necessari per simbolizzare i report di crash delle build App Store. Sapere cosa è cache ricostruibile e cosa è un artefatto acquisito è l'intera linea tra ciò che è sicuro da cancellare e ciò che va tenuto.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/xcode-storage-map.webp" width="1360" height="454" loading="lazy" alt="La cartella developer di Xcode divisa in cache ricostruibili, DerivedData e module cache, e artefatti catturati, DeviceSupport, Archives e simulatori">
  <figcaption>L'impronta di Xcode si divide in output riproducibile e artefatti acquisiti. Archives e dSYM possono restare operativamente importanti a lungo dopo la distribuzione di una build.</figcaption>
</figure>

## Dove una mappa del disco aiuta

Una mappa del disco come la vista Analyze di [Mole](https://mole.fit/) può mostrare se la pressione reale viene da DerivedData, CoreSimulator o Archives. Le viste Components, Devices e Organizer di Xcode dovrebbero eseguire la rimozione, perché conoscono runtime, dispositivi e artefatti di release.

## Un ordine di operazioni sicuro

Chiudi le build attive, misura Xcode e CoreSimulator separatamente, rimuovi la DerivedData obsoleta per progetto, elimina i simulatori non disponibili e disinstalla i runtime inutilizzati da Components. Rivedi le Archives rispetto alle versioni distribuite e alle esigenze di simbolizzazione prima di rimuoverle. Riapri un progetto importante ed esegui una build prima di svuotare il Cestino.

---

Canonical HTML page: https://mole.fit/it/blog/how-to-clean-up-xcode-mac
Blog index for agents: https://mole.fit/it/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
