# Limpe o Xcode sem perder artefatos de release

> Separe DerivedData, dispositivos do simulador, runtimes, DeviceSupport e archives de release antes de remover o armazenamento do Xcode.

Published: 2026-07-12 | Updated: 2026-10-18

O Xcode espalha armazenamento por saída de build, índices, archives, suporte a dispositivos, dispositivos do simulador e runtimes de plataforma que se baixam. Parte disso é reproduzível; parte é a única cópia de um archive de release ou dos dSYMs dele. O caminho seguro é medir cada categoria, remover pelo Xcode quando for possível e preservar artefatos ligados a builds que já foram enviados.

Um primeiro corte útil é separar o que o Xcode consegue reconstruir do que só você consegue repor. DerivedData e índices em geral são reconstruíveis se o código-fonte, as dependências e a toolchain ainda estiverem disponíveis. Dispositivos do simulador podem conter dados de teste únicos. Archives e os dSYMs deles também precisam ser preservados quando correspondem a software que já está nas mãos dos usuários.

## Para onde vão os gigabytes do Xcode

Comece pelas duas raízes principais no nível do usuário:

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

Os pesos habituais são:

- **DerivedData**: produtos de build, índices e caches de módulos, em geral uma pasta por projeto. É reconstruível, mas uma limpeza total torna a indexação e os builds seguintes caros. Mire primeiro no projeto parado.
- **DeviceSupport**: símbolos e artefatos de suporte capturados para dispositivos físicos e builds do sistema. Entradas antigas ainda podem servir para simbolicar crashes.
- **Archives**: builds salvos de cada vez que você exportou ou publicou um app. A Apple diz para guardar o archive de cada build que você distribui, porque os binários e os arquivos dSYM correspondentes podem ser necessários para diagnosticar relatórios de crash posteriores. Archives de builds que nunca saíram do seu Mac são os candidatos mais seguros à limpeza.
- **Dispositivos do simulador e runtimes de plataforma**: os dispositivos ficam em CoreSimulator, enquanto os runtimes baixáveis são gerenciados como componentes do Xcode. Não são um único cache.

## Limpar cada um com segurança

**DerivedData** é melhor tratado por projeto. Encerre o Xcode, use **Xcode › Settings > Locations** para revelar Derived Data, identifique a pasta do projeto parado e mova essa pasta para o Lixo. Limpe tudo só quando um problema global de índice ou de build justificar o custo da reconstrução.

**Dispositivos de simulador indisponíveis** têm um comando dedicado. Ele remove os dados desses dispositivos, não só uma entrada de lista, então preserve qualquer dado de teste que você ainda precise antes de executar:

```
xcrun simctl delete unavailable
```

Isso remove registros de dispositivos cujos runtimes estão indisponíveis; não desinstala as imagens de runtime em si. Use **Xcode › Settings › Components** para inspecionar plataformas instaladas e runtimes de simulador com os tamanhos recuperáveis, e depois remova runtimes que você consegue baixar de novo. O [guia de componentes do Xcode](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components) da Apple documenta o mesmo caminho de remoção gerenciada. Use **Window › Devices and Simulators** para os registros de dispositivos.

Revise os Archives em **Window › Organizer**. Preserve o archive e o dSYM de cada build distribuído, inclusive versões antigas de produção que ainda estão em uso. O [guia de informações de depuração](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information) da Apple observa que binários e dSYMs só funcionam juntos quando os UUIDs de build coincidem. DeviceSupport também merece revisão seletiva, não uma limpeza geral.

Encerre o Xcode antes de mover DerivedData para que índices e bancos de build não estejam no meio de uma escrita. Espere que a próxima abertura e o próximo build reindexem, resolvam dependências e recriem a saída; a duração depende do projeto e do que continua disponível.

## Por dentro: por que DerivedData é seguro e DeviceSupport não é a mesma coisa

DerivedData é saída reproduzível de build e de índice. Para cada projeto o Xcode cria uma pasta nomeada com um hash do caminho do projeto e a preenche com objetos compilados, caches de módulos, índices e produtos de build derivados do código-fonte, dos ajustes, das toolchains e das dependências. Apague e o Xcode reconstrói o que ainda está disponível, o que pode levar tempo e acesso à rede. DeviceSupport é diferente em natureza: quando você depura um dispositivo físico, o Xcode captura dados de suporte e de símbolos daquele build do sistema. Dispositivos do simulador e imagens de runtime também são objetos gerenciados distintos, não pastas de cache comuns. Archives são o conjunto que vale guardar de forma seletiva, porque contêm os dSYMs de que você precisa para simbolicar relatórios de crash de builds da App Store. Saber o que é cache reconstruível e o que é artefato capturado é a linha inteira entre o que é seguro limpar e o que se guarda.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/xcode-storage-map.webp" width="1360" height="454" loading="lazy" alt="A pasta de desenvolvedor do Xcode dividida em caches reconstruíveis, DerivedData e cache de módulos, e artefatos capturados, DeviceSupport, Archives e simuladores.">
  <figcaption>A pegada do Xcode se divide em saída reproduzível e artefatos capturados. Archives e dSYMs podem continuar importantes na prática muito depois que um build é publicado.</figcaption>
</figure>

## Onde um mapa de disco ajuda

Um mapa de disco como a visualização Analisar do [Mole](https://mole.fit/) pode mostrar se DerivedData, CoreSimulator ou Archives é a fonte real da pressão. As visualizações Components, Devices e Organizer do Xcode devem fazer a remoção, porque entendem runtimes, dispositivos e artefatos de release.

## Uma ordem segura de operações

Encerre builds ativos, meça Xcode e CoreSimulator separadamente, remova DerivedData parado por projeto, apague dispositivos de simulador indisponíveis e desinstale runtimes sem uso em Components. Revise os Archives contra as versões publicadas e a necessidade de simbolicação antes de remover. Reabra um projeto importante e rode um build antes de esvaziar o Lixo.

---

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