Limpe o Xcode sem perder artefatos de release

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 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 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.

Onde um mapa de disco ajuda

Um mapa de disco como a visualização Analisar do Mole 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.