Apagar runtimes antigos do simulador iOS no Mac

O armazenamento do Xcode não é um único cache. Runtimes de plataforma, dispositivos de simulador, DerivedData, DeviceSupport e Arquivos podem ficar perto uns dos outros no disco, mas têm donos diferentes e custos de recuperação muito diferentes.

Um runtime baixado pode ocupar vários gigabytes. Um dispositivo de simulador pode então acumular apps, bancos de dados, itens do Acesso às Chaves e fixtures de teste em cima desse runtime. Apagar a camada errada pode transformar uma limpeza rápida num download longo, numa reindexação completa ou na perda do estado exato necessário para reproduzir um bug.

A regra mais segura é simples: meça a categoria grande, identifique o dono e remova pelo Xcode ou pelo simctl. Não trate a pasta Developer inteira como descartável.

Comece com um inventário de armazenamento

Antes de apagar qualquer coisa, encerre builds ativos e anote o que você ainda precisa suportar. Registre as versões do Xcode, as versões de plataforma, as versões de sistema dos dispositivos físicos e os arquivos de distribuição que continuam relevantes para o trabalho atual.

Use Xcode › Ajustes › Componentes para ver os componentes de plataforma instalados. A Apple documenta isso como o lugar suportado para baixar e remover runtimes de simulador: Downloading and installing additional Xcode components.

Para um inventário só de leitura na linha de comando, rode:

xcrun simctl list runtimes
xcrun simctl list devices

Depois use um analisador de disco para comparar as categorias amplas em ~/Library/Developer e no CoreSimulator. O tamanho diz onde investigar; não diz o que é seguro apagar.

Imagens de runtime e dispositivos de simulador são coisas diferentes

Um runtime é a imagem de sistema baixável de iOS, watchOS, tvOS ou visionOS. Um dispositivo de simulador é um iPhone, iPad, Apple Watch, Apple TV ou Vision Pro virtual que roda numa dessas imagens. Vários dispositivos podem compartilhar um runtime.

Essa distinção explica duas surpresas comuns:

• Apagar um dispositivo não recupera necessariamente os vários gigabytes do runtime.
• Remover um runtime pode tornar indisponível todo dispositivo que depende dele.

A Apple também distingue o runtime da configuração de hardware simulado na documentação de desenvolvedor do Safari: Adding additional simulators.

Remova runtimes antigos pelo Xcode

Abra Xcode › Ajustes › Componentes, revise cada versão de plataforma instalada e remova só as versões de que nenhum projeto ativo, matriz de testes ou obrigação de suporte ainda precisa.

Mantenha um runtime quando qualquer um destes for verdade:

• É a versão instalada mais nova de uma plataforma para a qual você desenvolve.
• Um bug só se reproduz nessa versão do sistema.
• A CI ou um plano de testes local nomeia esse runtime de forma explícita.
• Baixá-lo de novo interromperia um trabalho próximo numa conexão lenta ou medida.

Remover o runtime pelo Xcode deixa o CoreSimulator atualizar os próprios registros. Evite apagar pastas à mão em /Library/Developer/CoreSimulator ou /System/Library/AssetsV2; esses diretórios podem conter recursos e registros gerenciados que uma exclusão no Finder não reconcilia.

A revisão Limpar do Mole pode listar runtimes baixados e substituídos que a Apple informa como apagáveis. Quando você confirma um, o Mole pede ao caminho simctl runtime delete da Apple para removê-lo. Ele confere o runtime de novo na hora da exclusão, preserva o runtime mais novo de cada plataforma e não oferece limpeza enquanto o Xcode ou as ferramentas do Simulator estão ativos.

Remova dispositivos indisponíveis separadamente

Quando um runtime some, os registros de dispositivos que dependiam dele podem permanecer como entradas indisponíveis. Revise a lista primeiro e remova só esses registros indisponíveis:

xcrun simctl delete unavailable

Esse comando remove registros de dispositivos. Ele não desinstala imagens de runtime e não apaga dispositivos disponíveis que ainda têm um runtime funcional.

Para um dispositivo nomeado, use Janela › Dispositivos e Simuladores no Xcode. Isso é mais fácil de auditar do que apagar um diretório com forma de UUID, porque a interface mostra juntos o nome do dispositivo, a plataforma e a disponibilidade.

Apague um dispositivo quando o problema é o estado de teste

Se um simulador específico tem dados de app velhos, uma migração de banco quebrada ou um estado de autenticação que você quer zerar, abra esse dispositivo no Simulator e escolha Dispositivo › Apagar Todo o Conteúdo e Ajustes.

Trate isso como apagar um telefone de teste. O runtime compartilhado continua instalado, mas o dispositivo virtual escolhido perde apps instalados, containers, itens do Acesso às Chaves, bancos de dados, permissões e outro estado. Antes de apagar, capture logs ou exporte qualquer fixture necessário para reproduzir o problema.

Criar um dispositivo novo costuma ser melhor do que apagar todo simulador. Isso dá uma comparação limpa e preserva o estado que falha até o bug ser entendido.

Limpe o DerivedData por projeto, não por reflexo

O DerivedData contém produtos de build, índices, logs e estado intermediário que o Xcode pode recriar. Em geral o risco é menor do que o dos arquivos de distribuição, mas uma limpeza total faz todo projeto recompilar e reindexar.

Use Xcode › Ajustes › Locais para mostrar a pasta DerivedData. Ordene por tamanho e data de modificação e remova primeiro a pasta de um projeto antigo ou quebrado. Se só um projeto tem índices velhos ou um cache de build inválido, apagar os dados de todos os projetos acrescenta tempo parado sem liberar um espaço útil muito maior.

Depois da limpeza, abra o projeto afetado e espere que o primeiro build, a conclusão de código e o índice de busca fiquem mais lentos. Esse atraso é o custo de recuperação do espaço que você recuperou.

Para um fluxo mais amplo de armazenamento de desenvolvedor, incluindo caches de pacotes e caches de módulos, leia como limpar arquivos do Xcode com segurança.

Trate o DeviceSupport como material de depuração

O DeviceSupport guarda símbolos e dados de suporte para dispositivos físicos e builds de sistema. Entradas antigas podem ser grandes, mas a idade sozinha não prova que são inúteis.

Antes de remover uma entrada, pergunte:

1. Ainda conecto um dispositivo com esse build de sistema?
2. Posso precisar inspecionar ou simbolicar um crash capturado desse dispositivo?
3. O Xcode consegue baixar ou recriar os arquivos de suporte necessários quando precisar?

Se a resposta for incerta, mantenha até a janela do dispositivo e dos crashes relacionados passar. Um mapa de disco pode identificar um diretório grande de versão, mas o Xcode e a necessidade de depuração decidem se ele tem valor.

Arquivos não são um cache

Um .xcarchive contém o app compilado, os dSYMs e os metadados de distribuição de um build específico. O dSYM correspondente pode ser essencial ao simbolicar um crash de uma versão que já está nas mãos dos usuários.

Abra Janela › Organizador › Arquivos e revise os arquivos por produto, versão, status de envio e data. Preserve todo arquivo associado a uma versão publicada, a menos que os mesmos símbolos e artefatos de build estejam guardados e verificados em outro lugar. Apague experimentos locais obsoletos só depois de confirmar que nunca foram distribuídos.

A pergunta útil não é "esse arquivo é antigo?". É "algum usuário ainda pode me enviar um crash deste build?".

Um fluxo de limpeza repetível

Use esta sequência quando o armazenamento do Xcode crescer de forma inesperada:

1. Encerre builds ativos, o Simulator e as ferramentas de linha de comando relacionadas.
2. Meça runtimes, dispositivos, DerivedData, DeviceSupport e Arquivos separadamente.
3. Remova runtimes sem uso nos Ajustes do Xcode, começando pelas versões de plataforma substituídas.
4. Rode xcrun simctl delete unavailable só depois de revisar a lista de dispositivos.
5. Remova DerivedData velho de projetos escolhidos e aceite o custo de rebuild.
6. Revise o DeviceSupport contra as necessidades de dispositivos físicos e de depuração de crashes.
7. Revise os arquivos no Organizador contra cada versão que os usuários ainda podem rodar.
8. Meça de novo antes de fazer outra passada.

Pare quando tiver recuperado espaço suficiente. A limpeza deve responder a um problema específico de armazenamento, não maximizar a quantidade apagada.

O que o Mole faz e o que não faz

O Mole separa descoberta e exclusão. Analisar mapeia DerivedData, CoreSimulator, DeviceSupport e Arquivos para você ver qual categoria é grande. Limpar pode oferecer imagens de runtime substituídas informadas pela Apple e remover uma selecionada pelo simctl depois de uma conferência de segurança nova.

O Mole não apaga dispositivos virtuais disponíveis nem arquivos de distribuição e, fora o cache de sistema recriável do simulador coberto nas perguntas frequentes abaixo, não remove pastas do CoreSimulator. O Xcode continua sendo o dono de componentes, dispositivos e arquivos, e você continua sendo o dono do histórico de testes e de versões que eles contêm.

Perguntas frequentes

Apagar um simulador apaga o código do meu projeto?

Não. O código-fonte do projeto normalmente vive fora do simulador. Apagar ou zerar um dispositivo virtual remove os apps instalados e o estado de teste desse dispositivo, então preserve o que for necessário para reproduzir um bug.

Por que apagar dispositivos recuperou menos espaço do que eu esperava?

Vários dispositivos podem compartilhar um runtime grande. Apagar dados de dispositivos não remove a imagem compartilhada da plataforma. Confira Xcode › Ajustes › Componentes para ver se um runtime sem uso é a camada maior.

É seguro apagar a pasta DeviceSupport inteira?

Não a trate como um cache geral. Revise entradas antigas de build de sistema de forma seletiva, sobretudo se você ainda depura um dispositivo físico ou pode precisar de símbolos associados a essa versão.

Posso apagar todo arquivo do Xcode depois de enviar à App Store?

Não com segurança, por padrão. O arquivo local pode conter o dSYM correspondente e o build distribuível exato de uma versão que os usuários ainda rodam. Mantenha-o, a menos que esses artefatos estejam preservados e verificados em outro lugar.

O Mole encontra runtimes antigos de simulador?

O Mole pode listar runtimes baixados e substituídos que a Apple informa como apagáveis e remover os selecionados pelo simctl. O único local do CoreSimulator que ele limpa por conta própria é o cache de sistema recriável em /Library/Developer/CoreSimulator/Caches, e só enquanto nenhum simulador ou dispositivo iniciado está em execução. Ele não decide qual runtime de teste ativo, estado de simulador ou arquivo de distribuição você ainda precisa.