# Limpiar Xcode sin perder artefactos de release > Separa DerivedData, dispositivos del simulador, runtimes, DeviceSupport y archivos de release antes de borrar almacenamiento de Xcode. Published: 2026-07-12 | Updated: 2026-08-08 Xcode reparte el almacenamiento entre salidas de compilación, índices, archivos, soporte de dispositivos, dispositivos del simulador y runtimes de plataforma descargables. Parte es reproducible; parte es la única copia de un archive de release o de sus dSYM. El enfoque seguro es medir cada categoría, eliminarla desde Xcode cuando sea posible y conservar los artefactos ligados a builds publicados. ## Dónde se van los gigabytes de Xcode Empieza por las dos raíces principales a nivel de usuario: ``` du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h ``` Los habituales grandes consumidores son: - **DerivedData**: productos de compilación, índices y caches de módulos, normalmente una carpeta por proyecto. Se puede regenerar, pero un vaciado completo encarece el indexado y las compilaciones posteriores. Apunta primero al proyecto obsoleto. - **DeviceSupport**: símbolos y artefactos de soporte capturados para dispositivos físicos y builds de SO. Las entradas antiguas aún pueden servir para simbolizar crashes. - **Archives**: builds guardados cada vez que exportaste o publicaste una app. Apple indica conservar el archive de cada build que distribuyas porque sus binarios y los dSYM correspondientes pueden hacer falta para diagnosticar reportes de crash posteriores. Los archives de builds que nunca salieron de tu Mac son los candidatos más seguros de limpieza. - **Dispositivos del simulador y platform runtimes**: los dispositivos viven bajo CoreSimulator, mientras que los runtimes descargables se gestionan como componentes de Xcode. No son una sola cache. ## Cómo limpiar cada uno con seguridad **DerivedData** se maneja mejor por proyecto. Cierra Xcode, usa **Xcode > Settings > Locations** para revelar Derived Data, identifica la carpeta del proyecto obsoleto y mueve esa carpeta a la Papelera. Limpia todo solo cuando un problema global de índice o de compilación justifique el coste de reconstruir. **Los dispositivos del simulador no disponibles** tienen un comando dedicado: ``` xcrun simctl delete unavailable ``` Esto elimina los registros de dispositivos cuyos runtimes no están disponibles; no desinstala las imágenes de runtime en sí. Usa **Xcode > Settings > Components** para revisar las plataformas y los simulator runtimes instalados con sus tamaños recuperables, y elimina los runtimes que puedas volver a descargar. La [guía de componentes de Xcode](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components) de Apple documenta el mismo camino de eliminación gestionada. Usa **Window > Devices and Simulators** para los registros de dispositivos. Revisa los Archives en **Window > Organizer**. Conserva el archive y el dSYM de cada build distribuido, incluidas las versiones de producción más antiguas que sigan en uso. La [guía de información de depuración](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information) de Apple indica que binarios y dSYM solo funcionan juntos cuando coinciden sus UUID de build. DeviceSupport también merece una revisión selectiva en lugar de un borrado total. Cierra Xcode antes de mover DerivedData para que los índices y las bases de datos de compilación no estén a mitad de escritura. Espera que la siguiente apertura y compilación reindexen, resuelvan dependencias y recreen la salida; la duración depende del proyecto y de lo que siga disponible. ## Bajo el capó: por qué DerivedData es seguro y DeviceSupport no es lo mismo DerivedData es salida reproducible de compilación e índice. Por cada proyecto Xcode crea una carpeta con un nombre hasheado a partir de la ruta del proyecto y la llena con objetos compilados, caches de módulos, índices y productos de build derivados del código fuente, ajustes, toolchains y dependencias. Si la eliminas, Xcode reconstruye lo que siga disponible, lo que puede llevar tiempo y acceso a la red. DeviceSupport es distinto en naturaleza: al depurar un dispositivo físico, Xcode captura datos de soporte y símbolos para esa build del SO. Los dispositivos del simulador y las imágenes de runtime también son objetos gestionados distintos, no carpetas de cache ordinarias. Los Archives son el conjunto que conviene conservar de forma selectiva, porque guardan los dSYM que necesitas para simbolizar reportes de crash de builds de la App Store. Saber qué es una cache regenerable y qué es un artefacto capturado es toda la línea entre seguro de limpiar y conservar.
La carpeta de desarrollador de Xcode dividida en cachés reconstruibles, DerivedData y module cache, y artefactos capturados, DeviceSupport, Archives y simuladores
La huella de Xcode se divide en salida reproducible y artefactos capturados. Los Archives y dSYM pueden seguir siendo operativamente importantes mucho después de publicar un build.
## Dónde ayuda un mapa de disco Un mapa de disco como la vista Analyze de [Mole](https://mole.fit/) puede mostrar si DerivedData, CoreSimulator o Archives es la verdadera fuente de presión. Las vistas Components, Devices y Organizer de Xcode deben encargarse de la eliminación porque entienden runtimes, dispositivos y artefactos de release. ## Un orden seguro de operaciones Cierra las compilaciones activas, mide Xcode y CoreSimulator por separado, elimina el DerivedData obsoleto por proyecto, borra los dispositivos del simulador no disponibles y desinstala los runtimes sin uso desde Components. Revisa los Archives frente a las versiones publicadas y las necesidades de simbolización antes de eliminar. Abre de nuevo un proyecto importante y ejecuta una compilación antes de vaciar la Papelera. --- Canonical HTML page: https://mole.fit/es/blog/how-to-clean-up-xcode-mac Blog index for agents: https://mole.fit/es/blog/llms.txt Site index for agents: https://mole.fit/llms.txt