Cómo borrar DerivedData de Xcode y las cachés de desarrollo de forma segura
AskClean Team · Updated 2026-07-18
DerivedData es la carpeta de trabajo de Xcode para productos de compilación e índices, y puede crecer en silencio hasta decenas de gigas. Es seguro borrarla: sal de Xcode, elimina el contenido de ~/Library/Developer/Xcode/DerivedData y Xcode lo reconstruirá todo en la siguiente compilación. Esta guía cubre eso, más los simuladores, los archivos de distribución y las cachés de paquetes.
Qué es DerivedData y por qué se hace enorme
DerivedData es donde Xcode guarda todo lo que deriva de tu código fuente: objetos intermedios de compilación, productos compilados, cachés de módulos, índices de símbolos para el autocompletado y el salto a definición, y registros de compilación. Vive por defecto en ~/Library/Developer/Xcode/DerivedData, con una subcarpeta por cada proyecto o workspace que hayas abierto alguna vez.
Crece por una razón estructural: Xcode crea una carpeta de DerivedData por cada proyecto que abres — incluidos los clones puntuales que compilaste una vez y no volviste a tocar — y nunca borra ninguna. Cada carpeta contiene productos de compilación separados por configuración y destino (Debug y Release, simulador y dispositivo), así que un solo proyecto de tamaño medio puede ocupar varios gigas, y la carpeta completa suele alcanzar 20-50 GB en una máquina de desarrollo en uso.
Todo lo que contiene es regenerable por definición: eso es justo lo que significa «derivado». Borrar DerivedData nunca toca tu código fuente, la configuración de tus proyectos ni nada bajo control de versiones. El único coste es tiempo: la siguiente compilación de cada proyecto será una compilación limpia completa, y la indexación volverá a ejecutarse en segundo plano durante unos minutos.
Borra DerivedData
Hay tres formas de hacerlo, y las tres acaban en el mismo sitio. El comando Clean Build Folder de Xcode (Product > Clean Build Folder, o Comando + Mayúsculas + K) solo limpia los productos de compilación del proyecto abierto: útil para arreglar una compilación rara, pero apenas mueve la aguja del espacio en disco. Para recuperar espacio de verdad, borra las carpetas de DerivedData en sí.
Borrar por proyecto es la opción quirúrgica: conserva el DerivedData de los dos o tres proyectos que compilas a diario y elimina las carpetas de todo lo demás. Borrarlo todo es la opción rápida, y también es válida: solo pagas el coste de la recompilación completa en todos los proyectos a la vez.
- Sal de Xcode primero. Borrar DerivedData con Xcode en ejecución puede dejar confundido a su indexador, y los archivos que Xcode tenga abiertos pueden no borrarse limpiamente.
- Encuentra la carpeta: en Xcode, abre Settings > Locations y haz clic en la flechita junto a la ruta de DerivedData para mostrarla en el Finder. O, en el Finder, pulsa Comando + Mayúsculas + G e introduce directamente ~/Library/Developer/Xcode/DerivedData.
- Ordena las subcarpetas de proyecto por tamaño, selecciona las que quieras eliminar (o Comando + A para todas) y muévelas a la Papelera. Pasar primero por la Papelera es el hábito más seguro: puedes restaurarlas al instante si cambias de opinión.
- Desde Terminal, como alternativa: rm -rf ~/Library/Developer/Xcode/DerivedData lo borra todo de una vez. Es más rápido que el Finder con carpetas muy grandes, pero lee la nota de abajo antes de usarlo.
- Vuelve a abrir Xcode y compila. Cuenta con que la primera compilación de cada proyecto tardará bastante más y con que «Indexing» aparecerá un rato en la barra de actividad: ambos son costes de una sola vez.
Cuidado con rm -rf: se salta la Papelera y borra de forma definitiva, sin deshacer. Escribe la ruta exacta, nunca lo ejecutes con sudo para esta tarea y, si no te sientes cómodo en Terminal, la vía del Finder hace el mismo trabajo de forma reversible.
Limpia los runtimes de simulador antiguos
Los simuladores suelen ser el segundo mayor devorador de espacio de desarrollo después de DerivedData. Cada runtime de iOS, watchOS o tvOS que hayas descargado ocupa 5-8 GB, y cada dispositivo simulado mantiene su propia carpeta de datos bajo ~/Library/Developer/CoreSimulator/Devices. Si has pasado por unas cuantas actualizaciones de Xcode, probablemente tengas runtimes de versiones de iOS que dejaste de usar hace años.
La vía más rápida es el comando de limpieza integrado: ejecuta xcrun simctl delete unavailable en Terminal. Elimina todos los dispositivos de simulador cuyo runtime ya no está instalado — los huérfanos que dejaron atrás versiones antiguas de Xcode — y no toca nada que aún puedas usar.
Para los runtimes en sí, abre Settings > Platforms en Xcode (llamado Components en versiones anteriores). Verás cada runtime de simulador instalado con su tamaño; selecciona uno antiguo y bórralo. Conserva solo el runtime más reciente de cada plataforma, salvo que pruebes activamente en versiones de sistema anteriores.
También puedes podar dispositivos simulados sueltos en Window > Devices and Simulators: cambia a la pestaña Simulators, haz clic derecho en cualquier dispositivo que nunca uses — los seis modelos de iPhone duplicados con datos de pruebas antiguas — y elige Delete. Los datos guardados y las apps de cada dispositivo se van con él.
Archivos de distribución, soporte de dispositivos y cachés
Los archives se acumulan en ~/Library/Developer/Xcode/Archives cada vez que ejecutas Product > Archive para distribuir una compilación. Cada archive contiene la app completa más sus símbolos de depuración dSYM, a menudo entre 100 MB y 1 GB cada uno. Antes de borrar, conoce la contrapartida: los dSYM que contienen son lo que te permite simbolizar los informes de fallos de esa compilación exacta. Conserva los archives de las versiones aún vivas en el App Store o TestFlight (o confirma que App Store Connect tiene los dSYM) y borra el resto; la vía más segura es el Organizer de Xcode (Window > Organizer > Archives), donde puedes revisarlos y eliminarlos con contexto.
iOS DeviceSupport, en ~/Library/Developer/Xcode/iOS DeviceSupport, guarda los símbolos de depuración que Xcode copia de cada iPhone o iPad físico que hayas conectado alguna vez: una carpeta por versión de iOS, normalmente de 2-5 GB cada una. Las carpetas de versiones de iOS que ya no usa ninguno de tus dispositivos son puro peso muerto: bórralas y, si algún día vuelves a conectar un dispositivo con esa versión, Xcode simplemente volverá a copiar los símbolos (verás «Preparing debugger support» una vez). Existen carpetas hermanas para dispositivos watchOS y tvOS.
Xcode también mantiene sus propias cachés en ~/Library/Caches/com.apple.dt.Xcode, y los simuladores guardan las suyas en ~/Library/Developer/CoreSimulator/Caches: ambas se pueden limpiar sin riesgo cuando Xcode y la app Simulator no están en ejecución, y ambas se reconstruyen bajo demanda.
Cachés de gestores de paquetes (SwiftPM, CocoaPods, npm, Homebrew)
Los gestores de paquetes conservan cada dependencia que han descargado para que las instalaciones futuras sean rápidas. Eso es buena ingeniería y mala higiene de disco: las cachés solo crecen, y en una máquina con unos años de proyectos suman en silencio 10-20 GB. Todas se pueden limpiar sin riesgo: en el peor de los casos, la próxima instalación vuelve a descargar los paquetes.
Swift Package Manager guarda los paquetes descargados en ~/Library/Caches/org.swift.swiftpm, y los checkouts resueltos de cada proyecto también viven dentro de su carpeta de DerivedData, así que limpiar DerivedData ya limpia esos. La caché compartida puedes borrarla desde el Finder o con rm -rf sobre esa ruta.
CocoaPods mantiene los pods descargados en ~/Library/Caches/CocoaPods. La forma limpia de vaciarla es el comando integrado: pod cache clean --all. Las carpetas Pods de tus proyectos no se tocan; solo desaparece la caché de descargas.
La caché de npm vive en ~/.npm y puede llegar a muchos gigas en una máquina cargada de JavaScript. Ejecuta npm cache clean --force para vaciarla (npm insiste en la opción porque la caché se autorrepara y normalmente nunca necesita limpieza; borrarla sigue siendo perfectamente seguro). Los usuarios de pnpm pueden ejecutar pnpm store prune en su lugar.
Homebrew atesora descargas antiguas y versiones obsoletas de paquetes. brew cleanup elimina versiones obsoletas y descargas caducadas; brew cleanup --prune=all vacía además toda la caché de descargas. Ejecuta antes brew cleanup -n si quieres una lista de simulación con lo que se eliminaría.
Automatízalo
Todo lo anterior funciona, pero la basura de desarrollo es una rueda de hámster: DerivedData vuelve en una semana de trabajo normal, las cachés se rellenan y cada actualización de Xcode deja huérfano otro runtime. Si prefieres no repetir seis procedimientos manuales cada mes, esta es la parte que merece la pena automatizar, con una herramienta que muestre su razonamiento en lugar de borrar en bloque a ciegas.
AskClean trata los archivos de desarrollo como categorías de primera clase: un solo escaneo detalla el DerivedData de Xcode por proyecto, los runtimes de simulador antiguos (leídos con simctl, conservando el más reciente de cada plataforma), los archivos de soporte de dispositivos y las cachés de gestores de paquetes de npm, SwiftPM, cargo, uv y más. También detecta los nuevos devoradores de espacio — las cachés de modelos de Hugging Face y Ollama — que lista por modelo y deja sin marcar por defecto.
Cada elemento llega con una explicación — qué es, si se puede reconstruir, qué cuesta borrarlo — y nada se ejecuta hasta que lo confirmas. Los borrados van a la Papelera, así que un clic equivocado se deshace con un arrastrar y soltar, y tu código fuente, tus documentos y tus fotos no se tocan jamás. Es la misma lista de tareas que esta guía, pero sin la hora de Terminal.
FAQ
¿Es seguro borrar DerivedData?
Sí: es uno de los borrados grandes más seguros en un Mac. DerivedData solo contiene archivos que Xcode genera a partir de tu código fuente: productos de compilación, cachés de módulos, índices y registros. Tu código, los archivos de proyecto y el historial de git viven en otro sitio y nunca se ven afectados. La única consecuencia es que la siguiente compilación de cada proyecto es una recompilación completa y la indexación vuelve a ejecutarse.
¿Cada cuánto debería limpiar DerivedData?
No hay un calendario obligatorio: límpialo cuando sea lo bastante grande como para importar, lo que para la mayoría de los desarrolladores activos significa cada mes o dos. Dos momentos siempre lo justifican: cuando necesitas espacio en disco ya, y cuando un proyecto muestra errores de compilación inexplicables o autocompletado desfasado, donde borrar DerivedData es el primer arreglo estándar.
¿Xcode irá más lento después de borrar DerivedData?
Temporalmente, sí. La primera compilación de cada proyecto es una compilación limpia, que puede tardar varias veces más que una incremental, y la indexación en segundo plano necesita unos minutos antes de que el autocompletado y la búsqueda vuelvan del todo. Tras ese primer ciclo, el rendimiento es exactamente el de antes: DerivedData contiene cachés, no optimizaciones que pierdas para siempre.
¿Y ~/Library/Developer/CoreSimulator? ¿Puedo borrarla?
No a ciegas: contiene los simuladores instalados actualmente y sus datos, y borrarla en bloque los rompe hasta que reinstales los runtimes. Pódala como es debido: ejecuta xcrun simctl delete unavailable para los dispositivos huérfanos, elimina runtimes antiguos en Settings > Platforms de Xcode, borra dispositivos sin usar en Devices and Simulators y limpia a mano solo la subcarpeta Caches.
¿Clean Build Folder hace lo mismo?
No. Product > Clean Build Folder (Comando + Mayúsculas + K) limpia los productos de compilación solo del proyecto actual y deja en su sitio los índices, las cachés de módulos y las carpetas de todos los demás proyectos. Es una herramienta para arreglar compilaciones, no para ganar espacio en disco: recuperar espacio de verdad implica borrar las propias carpetas de DerivedData.
Sources