La mayoría de los archives de Xcode se pueden borrar sin problema, y unos pocos valen más de lo que su tamaño sugiere. Cada archive es un build que exportaste o subiste, y sus dSYM guardan los símbolos de ese binario exacto. Borra los archives de builds que ya nadie ejecuta. Conserva los que hay detrás de cada versión que siga instalada en algún sitio, salvo que tu servicio de informes de fallos o App Store Connect ya tengan sus símbolos.
Regla principal: conserva el archive de cada build que la gente sigue usando y borra el resto desde el Organizer de Xcode, no desde la terminal.
Respuesta rápida
- Mide la carpeta con
du -sh ~/Library/Developer/Xcode/Archives/* | sort -h | tail. - Abre Xcode y ve a Window, Organizer, Archives.
- Conserva el último build publicado de cada app y cualquier build anterior que tus usuarios sigan usando.
- Comprueba que tu servicio de informes de fallos o App Store Connect tengan los símbolos de los builds que piensas borrar.
- Borra las exportaciones de prueba, las subidas reemplazadas y los builds de TestFlight caducados.
- Mueve a un disco externo los archives de los que no estés seguro, en lugar de borrarlos.
Qué hay dentro de un archive de Xcode
Xcode escribe un archive cada vez que ejecutas Product, Archive, o xcodebuild archive. Los guarda en ~/Library/Developer/Xcode/Archives, en una carpeta por día, y nombra cada paquete con el scheme y la hora, por ejemplo MyApp 21.09.2026, 14.13.xcarchive.
| Elemento dentro del .xcarchive | Qué guarda |
|---|---|
dSYMs | símbolos de depuración de la app y de sus frameworks integrados |
Products | la app compilada |
Info.plist | versión, número de build y fecha de creación |
Signatures | metadatos de firma |
Medí la carpeta en mi Mac el 25 de octubre de 2026, con macOS 27.0.1 y Xcode 27.1. Ocupaba 3,9 GB: 35 archives de 11 apps, todos creados entre el 16 de agosto y el 24 de octubre. Un archive típico ocupaba unos 165 MB y el más grande 407 MB. En un archive de StorageRadar, la carpeta dSYMs ocupaba 84 MB y la app en sí 39 MB, así que los símbolos pesaban más que el producto.
Por qué importan los dSYM
Un informe de fallos de un build de release muestra direcciones de memoria, no nombres de funciones. Xcode y los servicios de informes de fallos traducen esas direcciones con el dSYM cuyo UUID coincide con el del binario que falló. Puedes comprobar a qué build pertenece un dSYM:
dwarfdump --uuid ~/Library/Developer/Xcode/Archives/2026-09-21/*.xcarchive/dSYMs/*.dSYMVolver a archivar el mismo commit te da un binario nuevo y, en la mayoría de las configuraciones, un UUID nuevo. Por eso un archive borrado no se puede recrear a efectos de los informes de fallos: los informes del build antiguo necesitan el dSYM antiguo.
Hay dos sitios que pueden guardar una segunda copia:
- App Store Connect. Cuando distribuyes con la opción de subir los símbolos de tu app, Apple simboliza los informes de fallos que ves en el Organizer de Xcode.
- Tu servicio de informes de fallos. Servicios como Sentry y Firebase Crashlytics suben los dSYM durante la compilación cuando el proyecto está configurado para ello, y los guardan en su plataforma.
Si ninguno de los dos se aplica a un build, su archive es la única copia de sus símbolos.
Qué archives puedes borrar
Puedes borrar sin pensarlo mucho:
- archives de exportaciones locales o Ad Hoc que hiciste para probar algo;
- builds que subiste y luego reemplazaste por un build más reciente de la misma versión;
- builds de TestFlight de más de 90 días, porque en TestFlight caducan pasado ese plazo.
Conserva:
- el archive del build que está publicado en el App Store, y el de los uno o dos anteriores si tus usuarios tardan en actualizar;
- los archives de builds que distribuyes fuera del App Store, porque puede que tengas que volver a exportar o notarizar ese build exacto;
- todo lo que no tenga una segunda copia de sus símbolos, mientras sigan llegando informes de fallos de ese build.
Cómo borrar archives
En Xcode. Abre Window, Organizer, y elige Archives. Selecciona una app a la izquierda, elige uno o varios archives y bórralos desde el menú contextual. Organizer lee la carpeta de archives, así que esto elimina los paquetes del disco.
En el Finder. Ejecuta open ~/Library/Developer/Xcode/Archives y mueve carpetas de fecha completas a la Papelera. Organizer deja de mostrar lo que hayas movido.
A un disco externo. Copia las carpetas de fecha antiguas a un disco externo y luego bórralas del Mac. Xcode no necesita los archives en el disco interno para seguir funcionando, y puedes volver a copiar uno si algún día aparece un informe de fallos de un build antiguo.
También puedes hacer que Xcode use otra carpeta de archives desde Xcode Settings, Locations.
Archives frente a DerivedData
Estas dos carpetas están una junto a otra en ~/Library/Developer/Xcode y se comportan de forma opuesta. DerivedData es salida de compilación que Xcode recrea en la siguiente compilación, así que borrarla te cuesta una compilación más lenta. Los archives son el registro de los builds que publicaste, y nada los recrea. Limpia DerivedData sin miedo y revisa Archives uno por uno.
Conclusión
Borrar archives de Xcode es seguro para builds que nadie ejecuta y caro para builds que la gente sigue usando. Mide la carpeta, abre Organizer, conserva el archive de cada versión activa y comprueba dónde están los símbolos de los builds antiguos antes de borrarlos. Ante la duda, un disco externo cuesta menos que un informe de fallos que no puedes leer.
Preguntas frecuentes
¿Es seguro borrar los archives de Xcode?
Sí, en el caso de builds que ya nadie ejecuta: exportaciones de prueba, subidas que reemplazaste por otras, builds de TestFlight caducados. Conserva el archive de cada build que siga instalado en algún sitio, porque sus dSYM convierten los informes de fallos de ese build en trazas de pila legibles.
¿Borrar un archive de Xcode retira mi app del App Store?
No. App Store Connect conserva el build que subiste. El archive es tu copia local de ese build y de sus símbolos de depuración.
¿Puedo recrear un archive borrado?
Puedes volver a archivar el mismo commit, pero en la mayoría de las configuraciones el binario nuevo recibe un UUID nuevo. Los informes de fallos antiguos necesitan el dSYM con el UUID antiguo, así que siguen sin simbolizar salvo que ese dSYM exista en otro sitio, como App Store Connect o tu servicio de informes de fallos.
¿Dónde guarda Xcode los archives en Mac?
En ~/Library/Developer/Xcode/Archives, en una carpeta por día con nombres como 2026-10-24. La ruta aparece en Xcode, en Settings, Locations. Cada archive es un paquete .xcarchive con la app, sus dSYM y un Info.plist.
¿Cuánto espacio ocupan los archives de Xcode?
Depende de la app. En mi Mac, un archive típico ocupaba unos 165 MB y el más grande 407 MB. Treinta y cinco de ellos sumaban 3,9 GB en diez semanas, porque cada subida deja uno atrás.