Se o Simulador do Xcode está ocupando espaço no teu Mac, separa os runtimes do simulador dos dados dos dispositivos de simulador antes de apagar qualquer coisa. Começa revisando o que está indisponível, o que está inativo e o que ainda precisas para testes, porque a limpeza do simulador fica arriscada quando tratas toda pasta do lado da Apple como cache descartável.
Esse é o erro que desenvolvedores cometem depois de aprender uma regra de limpeza e aplicá-la em todo lugar. DerivedData é uma coisa. Runtimes do simulador e estado dos dispositivos de simulador são outra.
O armazenamento pode ser recuperável. As consequências são apenas menos uniformes.
Regra principal: limpe o armazenamento do simulador por camada. Remova dispositivos indisponíveis primeiro, apague dados do dispositivo apenas quando quiseres resetá-lo e delete runtimes apenas quando não precisares mais daquela versão do SO.
Resposta rápida
- Verifica se a pegada real é runtimes do simulador, dados dos dispositivos do simulador, ou ambos.
- Use
xcrun simctl list devicesexcrun simctl list runtimesantes de apagar qualquer coisa. - Delete dispositivos indisponíveis primeiro com
xcrun simctl delete unavailablequando eles aparecerem na seção unavailable. - Use
eraseapenas quando quiseres resetar os conteúdos e configurações de um dispositivo de simulador. - Delete runtimes apenas quando tiveres certeza de que não precisas mais daquela versão de plataforma para builds, previews ou testes.
- Se o armazenamento do lado da Apple é mais amplo do que apenas simuladores, revise
DerivedData,ArchiveseCoreSimulatorjuntos em vez de adivinhar a partir de uma pasta.
O que os simuladores do Xcode armazenam e por que isso se acumula
O armazenamento do simulador não é uma coisa só. São várias camadas que se acumulam juntas.
Em alto nível, o armazenamento do simulador do Xcode geralmente inclui:
- imagens de runtime para diferentes versões de plataforma iOS;
- dispositivos de simulador criados para diferentes modelos de iPhone e iPad;
- dados de apps, configurações e estado por dispositivo dentro desses simuladores;
- rotatividade de desenvolvimento do lado da Apple que cresce quando alternas entre SDKs, tipos de dispositivos e versões do Xcode.
É por isso que desenvolvedores frequentemente se sentem confusos com o CoreSimulator. É fácil olhar para o tamanho da pasta e assumir que tudo é apenas cache. Na prática, parte é mais como estado de teste descartável e parte é suporte de runtime do qual ainda dependes.
O padrão de crescimento é normal:
- instalas um Xcode ou SDK novo;
- novos runtimes aparecem;
- novos dispositivos de simulador são criados;
- apps, dados de teste e configurações se acumulam dentro deles;
- dispositivos antigos tornam-se indisponíveis após mudanças de SDK ou upgrades do Xcode;
- nada é revisado por meses porque a máquina ainda tem espaço livre suficiente.
Então um dia o armazenamento do simulador é a história principal, não apenas um detalhe.
Runtimes do simulador vs dados do simulador: Qual é a diferença?
Essa é a distinção que mais importa.
As ferramentas simctl da Apple tratam operações de runtime separadamente de operações de dispositivos. Isso por si só te diz que o modelo de limpeza é em camadas: dispositivos não são a mesma coisa que runtimes, e apagar um dispositivo não é a mesma coisa que deletar uma imagem de runtime.
| Camada | O que representa | Ação de limpeza típica | Principal tradeoff |
|---|---|---|---|
| Runtimes do simulador | As imagens de runtime do SO usadas para inicializar versões específicas de plataforma | simctl runtime delete para um runtime que realmente não precisas mais | Perdes aquele runtime para uso futuro do simulador até adicioná-lo de novo |
| Dispositivos do simulador | Instâncias de simulador criadas para modelos específicos de dispositivos | simctl delete <device> ou delete unavailable | A instância do dispositivo desaparece |
| Conteúdos e configurações dos dispositivos do simulador | Apps instalados, dados de apps, configurações e estado dentro de um dispositivo | simctl erase <device> | O dispositivo permanece, mas seus conteúdos e configurações são resetados |
É por isso que afirmações amplas como “simplesmente limpe o CoreSimulator” são conselhos fracos. Elas colapsam diferentes consequências de limpeza em uma ação emocional.
Onde o DerivedData se encaixa
DerivedData é adjacente, mas não é o mesmo problema.
DerivedData é geralmente saída de build gerada. O armazenamento do simulador é mais misto. Pode incluir runtimes que ainda precisas, dispositivos criados que não precisas mais e estado dentro de dispositivos que podes ou não importar.
Se a pressão é principalmente saída de build gerada, o guia certo é Xcode DerivedData ocupando muito espaço no Mac? O que limpar primeiro. Se a pressão é principalmente imagens de runtime e estado do simulador, fica com o fluxo de trabalho do simulador.
Como verificar quanto espaço os simuladores estão usando
O primeiro passo é inspeção, não exclusão.
Usa as próprias ferramentas da Apple para ver quais dispositivos e runtimes realmente existem:
xcrun simctl list devices
xcrun simctl list runtimesSe quiseres inspecionar a pegada ampla de armazenamento do lado da Apple no disco, também podes comparar as pastas principais diretamente:
du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/ArchivesIsso importa porque a maior pasta do lado da Apple nem sempre é a que assumiste. Às vezes DerivedData é o problema dominante. Às vezes CoreSimulator discretamente a ultrapassa.
O que procurar primeiro
- dispositivos listados em
Unavailable; - runtimes para versões de SO que não testas mais;
- muitos dispositivos criados através de várias gerações de runtime;
- estado pesado de simulador em uma máquina que não foi limpa desde múltiplas atualizações do Xcode;
- uma pasta
CoreSimulatorgrande que não corresponde às tuas necessidades atuais de teste.
Esse é o ponto onde a limpeza começa a se tornar racional em vez de reativa.
É seguro apagar runtimes do simulador no Mac?
Às vezes, mas esse não é o primeiro passo mais seguro.
A ajuda do simctl runtime da Apple deixa claro que as imagens de runtime são objetos gerenciados próprios. Apagar um runtime é diferente de limpar os conteúdos de um simulador. Também é diferente de deletar um dispositivo indisponível.
Isso significa que exclusão de runtime é melhor quando:
- não precisas mais daquela versão do iOS para testes;
- passaste de uma geração mais antiga de Xcode ou SDK;
- o runtime está sem uso suficiente que o espaço vale mais que a conveniência;
- verificaste a lista de runtimes primeiro e sabes exatamente o que estás removendo.
É uma pior ideia quando:
- um projeto ativo ainda tem como target aquela família de runtime;
- previews do SwiftUI, passos de reprodução de QA ou testes de regressão ainda dependem dele;
- estás prestes a fazer demo ou debugar um problema em um target mais antigo;
- estás apagando baseado apenas em tamanho em vez de necessidades reais de teste.
Melhor primeiro passo: remova o peso morto óbvio
A limpeza mais segura do simulador frequentemente começa com dispositivos indisponíveis.
A Apple documenta isso diretamente em simctl delete: o alias unavailable deleta dispositivos que não são suportados pelo SDK atual do Xcode.
xcrun simctl delete unavailableIsso não é uma resposta universal, mas é uma das primeiras passagens mais limpas porque tem como alvo dispositivos já marcados como não suportados pelo teu contexto de SDK atual.
Limpando dados do simulador sem perder teu ambiente de desenvolvimento
É aqui que desenvolvedores frequentemente usam a ferramenta errada para o trabalho.
Se teu problema é dados de app obsoletos ou estado de dispositivo inchado dentro dos simuladores, podes não precisar apagar runtimes. Podes apenas precisar resetar os dispositivos do simulador.
A ajuda do simctl erase da Apple define erase como apagar os conteúdos e configurações de um dispositivo:
xcrun simctl erase <device>Isso é uma operação de reset, não uma operação de remoção de runtime.
Para que erase serve
- limpar estado de app dentro de um simulador;
- resetar ambientes de teste;
- remover conteúdos em nível de dispositivo inchados sem remover a imagem de runtime em si;
- manter o fluxo de trabalho do dispositivo enquanto descarta seu estado acumulado.
O que erase não é
- não é um comando de limpeza de runtime;
- não é um comando de limpeza de
DerivedData; - não é uma boa substituição para revisar quais dispositivos e runtimes ainda precisas realmente.
Essa distinção é toda a história da limpeza do simulador: apagar (erase) um dispositivo, deletar um dispositivo e deletar um runtime são três decisões diferentes.
Como gerenciar o armazenamento do simulador daqui para frente
O objetivo prático não é “nunca deixar os simuladores crescerem.” O objetivo prático é “parar de deixar o armazenamento do simulador se tornar invisível.”
Usa um ritmo de revisão como este:
- Liste dispositivos e runtimes após mudanças grandes de Xcode ou SDK.
- Delete dispositivos indisponíveis quando aparecerem.
- Reset dispositivos de simulador parados quando o problema é estado do dispositivo, não inventário de runtimes.
- Revise o uso de runtimes antes de remover uma versão de SO inteiramente.
- Compare
CoreSimulator,DerivedDataeArchivesjuntos quando o armazenamento do lado da Apple começar a subir.
Isso mantém a decisão de limpeza alinhada com a camada que está realmente cara.
Um modelo mental melhor para armazenamento do lado da Apple
DerivedDataé principalmente saída de build gerada.Archivespreservam entregáveis e histórico de builds.CoreSimulatormistura suporte de runtime com estado de dispositivos de simulador.- a limpeza mais segura depende de qual camada está grande, não apenas de qual pasta está visível.
Uma vez que penses em camadas, a limpeza do simulador fica muito menos caótica.
Por que a limpeza de desenvolvedor funciona melhor quando permanece consciente do ecossistema
Se usares apenas o Finder, uma pasta de 20 GB ou 30 GB do lado da Apple parece um alvo de limpeza óbvio. Não é.
Um navegador de arquivos pode te mostrar que CoreSimulator é grande. Não consegue te dizer se o espaço realmente recuperável é:
- dispositivos não suportados;
- conteúdos de simulador resetáveis;
- runtimes que não precisas mais;
- ou um perfil do Xcode vizinho que simplesmente acontece de estar perto.
É por isso que a limpeza do simulador pertence à limpeza de desenvolvedor, não à limpeza genérica de arquivos.
Se teu problema real é “simuladores mais DerivedData mais outro armazenamento de dev Apple,” esse fluxo de trabalho mais amplo consciente de perfis é muito mais útil do que caçar um caminho de pasta de cada vez.
Conclusão
Se o Simulador do Xcode está ocupando espaço no teu Mac, não trates o CoreSimulator como um único bucket de cache descartável.
Revise dispositivos e runtimes primeiro. Delete dispositivos indisponíveis como a primeira passagem limpa, use erase apenas quando quiseres resetar conteúdos e configurações do simulador, e remova runtimes apenas quando realmente não precisares mais daquela versão do SO.
Esse é o caminho de limpeza mais seguro: separa imagens de runtime de estado de dispositivos, separa armazenamento do simulador de DerivedData e mantém a limpeza do lado da Apple ligada às necessidades reais de testes em vez de exclusão cega de pastas.
Perguntas frequentes
Por que o Simulador do Xcode ocupa tanto espaço em disco no Mac?
O armazenamento do simulador cresce porque o Xcode mantém imagens de runtime, dispositivos de simulador criados, dados de apps dentro desses simuladores e outro estado de desenvolvimento da Apple ao longo do tempo. Testar em várias versões de iOS e tipos de dispositivos faz a pegada expandir rapidamente.
Qual é a diferença entre runtimes do simulador e dados do simulador?
Runtimes do simulador são as imagens de runtime do SO que o Xcode usa para inicializar simuladores para versões específicas de plataforma. Dados do simulador são o estado em nível de dispositivo dentro dos simuladores criados, como apps instalados, dados de apps e configurações.
É seguro apagar dispositivos de simulador indisponíveis?
Geralmente sim. A ferramenta simctl da Apple suporta explicitamente a exclusão de dispositivos indisponíveis, que são dispositivos não mais suportados pelo SDK atual do Xcode. Essa é frequentemente uma das etapas de limpeza de simulador mais seguras.
É seguro apagar runtimes do simulador no Mac?
Às vezes, mas apenas quando sabes que não precisas mais daquele runtime para testes, previews ou targets de projetos mais antigos. Remover um runtime é uma decisão maior do que apagar conteúdos do simulador porque remove a imagem de runtime em si.
Apagar (erase) um simulador remove o runtime?
Não. A ajuda do simctl da Apple descreve erase como limpar os conteúdos e configurações de um dispositivo. Isso reseta o dispositivo do simulador, mas é diferente de apagar a imagem de runtime por trás dele.