AskCleanAskClean

Exclua o DerivedData do Xcode e caches de desenvolvedor com segurança

AskClean Team · Updated 2026-07-18

DerivedData é a pasta de rascunho do Xcode para produtos de build e índices, e ela pode crescer em silêncio para dezenas de gigabytes. É seguro excluí-la: encerre o Xcode, remova o conteúdo de ~/Library/Developer/Xcode/DerivedData, e o Xcode reconstrói tudo no próximo build. Este guia cobre isso, mais simuladores, archives e caches de pacotes.

O que é o DerivedData e por que ele fica gigante

DerivedData é onde o Xcode guarda tudo o que deriva do seu código-fonte: objetos intermediários de build, produtos compilados, caches de módulos, índices de símbolos para autocompletar e pular para definições, e logs de build. Ele fica em ~/Library/Developer/Xcode/DerivedData por padrão, com uma subpasta para cada projeto ou workspace que você já abriu.

Ele cresce por uma razão estrutural: o Xcode cria uma pasta de DerivedData para cada projeto que você abre — inclusive aqueles clones avulsos que você compilou uma vez e nunca mais tocou — e nunca exclui nenhuma delas. Cada pasta guarda produtos de build separados por configuração e destino (Debug e Release, simulador e dispositivo), então um único projeto de porte médio pode ocupar vários gigabytes, e a pasta como um todo chega com frequência a 20-50 GB numa máquina de desenvolvimento em uso.

Tudo ali dentro é regenerável por definição — é isso que "derived" quer dizer. Excluir o DerivedData nunca toca no seu código-fonte, nas configurações do projeto nem em nada sob controle de versão. O único custo é tempo: o próximo build de cada projeto é um clean build completo, e a indexação roda de novo em segundo plano por alguns minutos.

Exclua o DerivedData

Há três jeitos de fazer isso, e todos terminam no mesmo lugar. O comando Clean Build Folder do Xcode (Product > Clean Build Folder, ou Command-Shift-K) limpa apenas os produtos de build do projeto aberto no momento — útil para consertar um build esquisito, mas quase não faz diferença no espaço em disco. Para recuperar espaço de verdade, exclua as próprias pastas do DerivedData.

Excluir por projeto é a opção cirúrgica: mantenha o DerivedData dos dois ou três projetos que você compila todo dia e remova as pastas de todo o resto. Excluir tudo de uma vez é a opção rápida, e também funciona — você só paga o custo do rebuild completo em todos os projetos de uma só vez.

  1. Encerre o Xcode primeiro. Excluir o DerivedData com o Xcode aberto pode deixar o indexador confuso, e arquivos que o Xcode mantém abertos podem não ser excluídos de forma limpa.
  2. Encontre a pasta: no Xcode, abra Settings > Locations e clique na setinha ao lado do caminho do DerivedData para revelá-lo no Finder. Ou, no Finder, pressione Command-Shift-G e digite ~/Library/Developer/Xcode/DerivedData diretamente.
  3. Ordene as subpastas de projeto por tamanho, selecione as que você quer eliminar (ou Command-A para todas) e mova-as para a Lixeira. Lixeira primeiro é o hábito mais seguro — dá para restaurar na hora se você mudar de ideia.
  4. Pelo Terminal, em vez disso: rm -rf ~/Library/Developer/Xcode/DerivedData exclui tudo de uma tacada só. É mais rápido que o Finder para pastas muito grandes, mas leia a nota abaixo antes de usar.
  5. Reabra o Xcode e compile. Espere que o primeiro build de cada projeto demore visivelmente mais e que "Indexing" apareça na barra de atividade por um tempo — os dois são custos de uma vez só.

Cuidado com o rm -rf: ele passa por cima da Lixeira e exclui permanentemente, sem desfazer. Digite o caminho exato, nunca o execute com sudo para essa tarefa e, se você não se sente à vontade no Terminal, o caminho pelo Finder faz o mesmo trabalho de forma reversível.

Limpe runtimes antigos de simulador

Simuladores costumam ser o segundo maior devorador de espaço de desenvolvedor, atrás só do DerivedData. Cada runtime de iOS, watchOS ou tvOS que você já baixou ocupa 5-8 GB, e cada dispositivo simulado mantém sua própria pasta de dados em ~/Library/Developer/CoreSimulator/Devices. Se você já passou por algumas atualizações do Xcode, provavelmente tem runtimes de versões do iOS que você deixou de suportar anos atrás.

A vitória mais rápida é o comando de limpeza embutido: execute xcrun simctl delete unavailable no Terminal. Ele exclui todo dispositivo de simulador cujo runtime não está mais instalado — os órfãos deixados para trás por versões antigas do Xcode — e não toca em nada que você ainda possa usar.

Para os runtimes em si, abra Settings > Platforms no Xcode (chamado de Components em versões mais antigas do Xcode). Você verá cada runtime de simulador instalado com o tamanho; selecione um antigo e exclua. Mantenha só o runtime mais recente por plataforma, a menos que você teste ativamente em versões mais antigas do sistema.

Também dá para podar dispositivos simulados individuais em Window > Devices and Simulators: mude para a aba Simulators, clique com o botão direito em qualquer dispositivo que você nunca usa — os seis modelos duplicados de iPhone com dados de testes antigos — e escolha Delete. Os dados e apps salvos de cada dispositivo vão junto.

Archives, arquivos de device support e caches

Os archives se acumulam em ~/Library/Developer/Xcode/Archives toda vez que você executa Product > Archive para distribuir um build. Cada archive contém um build completo do app mais seus símbolos de depuração dSYM, muitas vezes de 100 MB a 1 GB cada. Antes de excluir, conheça o trade-off: os dSYMs lá dentro são o que permite simbolizar relatórios de travamento daquele build exato. Mantenha os archives das versões ainda ativas na App Store ou no TestFlight (ou confirme que o App Store Connect tem os dSYMs) e exclua o resto — o caminho mais seguro é o Organizer do Xcode (Window > Organizer > Archives), onde você revisa e exclui com contexto.

O iOS DeviceSupport, em ~/Library/Developer/Xcode/iOS DeviceSupport, guarda símbolos de depuração que o Xcode copia de cada iPhone ou iPad físico que você já conectou — uma pasta por versão do iOS, tipicamente com 2-5 GB cada. Pastas de versões do iOS que nenhum dos seus dispositivos roda mais são peso morto puro: exclua-as e, se um dia você conectar de novo um dispositivo naquela versão, o Xcode simplesmente copia os símbolos outra vez (você verá "Preparing debugger support" uma vez). Existem pastas irmãs para dispositivos watchOS e tvOS também.

O Xcode também mantém seus próprios caches em ~/Library/Caches/com.apple.dt.Xcode, e os simuladores mantêm os deles em ~/Library/Developer/CoreSimulator/Caches — os dois são seguros de limpar quando o Xcode e o app Simulator não estão rodando, e os dois são reconstruídos sob demanda.

Caches de gerenciadores de pacotes (SwiftPM, CocoaPods, npm, Homebrew)

Gerenciadores de pacotes guardam toda dependência que já baixaram para que as próximas instalações sejam rápidas. Isso é boa engenharia e má higiene de disco: os caches só crescem, e numa máquina com alguns anos de projetos eles somam discretamente 10-20 GB. Todos são seguros de limpar — o pior caso é a sua próxima instalação baixar os pacotes de novo.

O Swift Package Manager guarda os pacotes baixados em ~/Library/Caches/org.swift.swiftpm, e os checkouts resolvidos de cada projeto também vivem dentro da pasta de DerivedData dele — então limpar o DerivedData já limpa esses. O cache compartilhado você pode excluir pelo Finder, ou com rm -rf naquele caminho.

O CocoaPods mantém os pods baixados em ~/Library/Caches/CocoaPods. O jeito limpo de esvaziar é o comando embutido: pod cache clean --all. As pastas Pods dos seus projetos ficam intocadas; só o cache de downloads vai embora.

O cache do npm vive em ~/.npm e pode chegar a muitos gigabytes numa máquina pesada em JavaScript. Execute npm cache clean --force para esvaziá-lo (o npm insiste na flag porque o cache se autocorrige e normalmente nunca precisa de limpeza — excluí-lo continua sendo perfeitamente seguro). Quem usa pnpm pode executar pnpm store prune em vez disso.

O Homebrew acumula downloads antigos e versões desatualizadas de pacotes. brew cleanup remove versões obsoletas e downloads velhos; brew cleanup --prune=all também esvazia o cache de downloads inteiro. Execute brew cleanup -n antes se quiser uma lista de simulação do que seria removido.

Automatize

Tudo o que está acima funciona, mas limpar entulho de desenvolvedor é enxugar gelo: o DerivedData volta em uma semana de trabalho normal, os caches se reenchem e cada atualização do Xcode abandona mais um runtime. Se você prefere não repetir seis procedimentos manuais todo mês, esta é a parte que vale automatizar — com uma ferramenta que mostra o próprio raciocínio, em vez de excluir em massa em silêncio.

O AskClean trata arquivos de desenvolvedor como categorias de primeira classe: uma varredura detalha o Xcode DerivedData por projeto, runtimes antigos de simulador (lidos via simctl, mantendo o mais recente por plataforma), arquivos de device support e caches de gerenciadores de pacotes para npm, SwiftPM, cargo, uv e mais. Ele também pega os devoradores de espaço mais novos — caches de modelos do Hugging Face e do Ollama — que ele lista por modelo e deixa desmarcados por padrão.

Cada item vem com uma explicação — o que é, se dá para reconstruir, o que a exclusão custa — e nada roda até você confirmar. As exclusões vão para a Lixeira, então um clique errado se desfaz com um arrastar-e-soltar, e seu código-fonte, documentos e fotos nunca são tocados. É a mesma lista de tarefas deste guia, menos a hora de trabalho no Terminal.

FAQ

É seguro excluir o DerivedData?

Sim — é uma das exclusões grandes mais seguras num Mac. O DerivedData contém apenas arquivos que o Xcode gera a partir do seu código: produtos de build, caches de módulos, índices e logs. Seu código, os arquivos de projeto e o histórico do git vivem em outro lugar e nunca são afetados. A única consequência é que o próximo build de cada projeto é um rebuild completo e a indexação roda de novo.

Com que frequência devo limpar o DerivedData?

Não existe cronograma obrigatório — limpe quando ele estiver grande o bastante para importar, o que para a maioria dos desenvolvedores ativos significa a cada mês ou dois. Dois momentos sempre justificam: quando você precisa de espaço em disco rápido, e quando um projeto apresenta erros de build inexplicáveis ou autocompletar desatualizado, situação em que zerar o DerivedData é a primeira correção padrão.

O Xcode vai ficar mais lento depois que eu excluir o DerivedData?

Temporariamente, sim. O primeiro build de cada projeto é um clean build, que pode levar várias vezes mais tempo que um incremental, e a indexação em segundo plano precisa de alguns minutos até o autocompletar e a busca voltarem por completo. Depois desse primeiro ciclo, o desempenho é exatamente o que era — o DerivedData guarda caches, não otimizações que você perde para sempre.

E a pasta ~/Library/Developer/CoreSimulator — posso excluir?

Não às cegas — ela guarda os simuladores instalados no momento e os dados deles, e excluí-la por inteiro os quebra até você reinstalar os runtimes. Faça a poda do jeito certo: execute xcrun simctl delete unavailable para os dispositivos órfãos, remova runtimes antigos em Settings > Platforms no Xcode, exclua dispositivos sem uso em Devices and Simulators e limpe à mão apenas a subpasta Caches.

O Clean Build Folder faz a mesma coisa?

Não. Product > Clean Build Folder (Command-Shift-K) limpa apenas os produtos de build do projeto atual e deixa no lugar os índices, os caches de módulos e as pastas de todos os outros projetos. É uma ferramenta de solução de problemas de build, não de espaço em disco — recuperar espaço de verdade significa excluir as próprias pastas do DerivedData.

Sources