A maioria dos archives do Xcode pode ser apagada sem problema, e alguns valem mais do que o tamanho sugere. Cada archive é um build que você exportou ou enviou, e os dSYMs dele guardam os símbolos daquele binário exato. Apague os archives de builds que ninguém mais roda. Guarde os que estão por trás de cada versão ainda instalada em algum lugar, a menos que o seu serviço de crash reporting ou o App Store Connect já tenha os símbolos delas.
Regra principal: guarde o archive de cada build que as pessoas ainda usam e apague o resto pelo Organizer do Xcode, não pelo terminal.
Resposta rápida
- Meça a pasta com
du -sh ~/Library/Developer/Xcode/Archives/* | sort -h | tail. - Abra o Xcode e vá em Window, Organizer, Archives.
- Guarde o build publicado mais recente de cada app e qualquer build mais antigo que seus usuários ainda rodam.
- Confira se o seu serviço de crash reporting ou o App Store Connect tem os símbolos dos builds que você pretende apagar.
- Apague exportações de teste, uploads substituídos e builds do TestFlight expirados.
- Mova para um disco externo os archives sobre os quais você tem dúvida, em vez de apagá-los.
O que há dentro de um archive do Xcode
O Xcode grava um archive toda vez que você roda Product, Archive ou xcodebuild archive. Ele os organiza em ~/Library/Developer/Xcode/Archives, uma pasta por dia, e dá a cada bundle o nome do scheme e o horário, por exemplo MyApp 21.09.2026, 14.13.xcarchive.
| Item dentro do .xcarchive | O que guarda |
|---|---|
dSYMs | símbolos de depuração do app e dos frameworks embutidos nele |
Products | o app compilado |
Info.plist | versão, número do build e data de criação |
Signatures | metadados de assinatura |
Medi a pasta no meu Mac em 25 de outubro de 2026, com macOS 27.0.1 e Xcode 27.1. Ela tinha 3,9 GB: 35 archives de 11 apps, todos criados entre 16 de agosto e 24 de outubro. Um archive típico ocupava cerca de 165 MB, e o maior, 407 MB. Em um archive do StorageRadar, a pasta dSYMs ocupava 84 MB e o app em si, 39 MB: os símbolos pesavam mais que o produto.
Por que os dSYMs importam
Um relatório de falhas de um build de release lista endereços de memória, não nomes de funções. O Xcode e os serviços de crash reporting traduzem esses endereços com o dSYM cujo UUID corresponde ao binário que travou. Dá para conferir a qual build um dSYM pertence:
dwarfdump --uuid ~/Library/Developer/Xcode/Archives/2026-09-21/*.xcarchive/dSYMs/*.dSYMFazer o archive do mesmo commit de novo gera um binário novo e, na maioria das configurações, um UUID novo. Por isso um archive apagado não pode ser recriado para fins de crash reporting: os relatórios do build antigo precisam do dSYM antigo.
Dois lugares podem guardar uma segunda cópia:
- App Store Connect. Quando você distribui com a opção de enviar os símbolos do app, a Apple simbolica os relatórios de falhas que você vê no Organizer do Xcode.
- Seu serviço de crash reporting. Serviços como Sentry e Firebase Crashlytics enviam os dSYMs durante o build, quando o projeto está configurado para isso, e os guardam do lado deles.
Se nenhum dos dois vale para um build, o archive dele é a única cópia dos seus símbolos.
Quais archives você pode apagar
Pode apagar sem pensar muito:
- archives de exportações locais ou Ad Hoc que você fez para testar alguma coisa;
- builds que você enviou e depois substituiu por um build mais novo da mesma versão;
- builds do TestFlight com mais de 90 dias, já que o TestFlight expira os builds depois desse prazo.
Guarde:
- o archive do build que está no ar na App Store, e também o do anterior ou dos dois anteriores se seus usuários demoram para atualizar;
- archives de builds que você distribui fora da App Store, porque talvez precise exportar ou notarizar aquele build exato de novo;
- qualquer archive sem uma segunda cópia dos símbolos, enquanto ainda chegarem relatórios de falhas daquele build.
Como apagar archives
No Xcode. Abra Window, Organizer e escolha Archives. Selecione um app à esquerda, marque um ou mais archives e apague-os pelo menu de contexto. O Organizer lê a pasta de archives, então isso remove os bundles do disco.
No Finder. Rode open ~/Library/Developer/Xcode/Archives e mova pastas de data inteiras para o Lixo. O Organizer deixa de listar o que você moveu.
Para um disco externo. Copie as pastas de datas antigas para um disco externo e depois apague-as do Mac. O Xcode não precisa dos archives no disco interno para continuar funcionando, e você pode copiar um de volta se algum dia aparecer um relatório de falhas de um build antigo.
Você também pode apontar o Xcode para outra pasta de archives em Xcode Settings, Locations.
Archives versus DerivedData
As duas pastas ficam lado a lado em ~/Library/Developer/Xcode e se comportam de formas opostas. O DerivedData é saída de build que o Xcode recria no build seguinte, então apagá-lo custa um build mais lento. Os Archives são o registro dos builds que você publicou, e nada os recria. Limpe o DerivedData à vontade e revise os Archives um por um.
Conclusão
Apagar archives do Xcode é seguro para builds que ninguém roda e caro para builds que as pessoas ainda usam. Meça a pasta, abra o Organizer, guarde o archive por trás de cada versão no ar e confira onde estão os símbolos dos builds mais antigos antes de apagá-los. Na dúvida, um disco externo custa menos que um relatório de falhas que você não consegue ler.
Perguntas frequentes
É seguro apagar archives do Xcode?
Sim, para archives de builds que ninguém mais roda: exportações de teste, uploads substituídos, builds do TestFlight expirados. Guarde o archive de cada build que ainda está instalado em algum lugar, porque os dSYMs dele transformam os relatórios de falhas daquele build em stack traces legíveis.
Apagar um archive do Xcode tira meu app da App Store?
Não. O App Store Connect mantém o build que você enviou. O archive é a sua cópia local daquele build e dos símbolos de depuração dele.
Dá para recriar um archive apagado?
Você pode fazer o archive do mesmo commit de novo, mas na maioria das configurações o binário novo ganha um UUID novo. Os relatórios de falhas antigos precisam do dSYM com o UUID antigo, então continuam sem simbolicação, a não ser que esse dSYM exista em outro lugar, como no App Store Connect ou no seu serviço de crash reporting.
Onde o Xcode guarda os archives no Mac?
Em ~/Library/Developer/Xcode/Archives, uma pasta por dia, com nomes como 2026-10-24. O caminho aparece em Xcode Settings, Locations. Cada archive é um bundle .xcarchive com o app, os dSYMs e um Info.plist.
Quanto espaço os archives do Xcode ocupam?
Depende do app. No meu Mac, um archive típico ocupava cerca de 165 MB, e o maior, 407 MB. Trinta e cinco deles somavam 3,9 GB em dez semanas, porque cada upload deixa um para trás.