AskClean

Cómo borrar DerivedData de Xcode y las cachés de desarrollo sin riesgo

Equipo de AskClean · Actualizado 2026-11-02

DerivedData es la carpeta de trabajo de Xcode para productos de compilación e índices, y puede crecer en silencio hasta ocupar decenas de gigabytes. 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 y, además, los simuladores, los archives y las cachés de paquetes.

Cómo borrar DerivedData de Xcode y las cachés de desarrollo sin riesgo
Borra DerivedData de Xcode sin riesgo, elimina runtimes antiguos del simulador y limpia archives, DeviceSupport y cachés de gestores de paquetes en tu Mac.

Qué es DerivedData y por qué crece tanto

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 la definición, y registros de compilación. Por defecto está 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 no las elimina por su cuenta. Cada carpeta guarda productos de compilación separados por configuración y destino (Debug y Release, simulador y dispositivo), así que mide las subcarpetas de cada proyecto en lugar de suponer cuánto espacio recuperará tu Mac.

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 que esté 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

El comando Clean Build Folder de Xcode (Product > Clean Build Folder, o Mayúsculas + Comando + K) solo borra los productos de compilación del proyecto abierto: sirve para arreglar una compilación rara, pero apenas libera espacio en disco. Para recuperar espacio de verdad, borra las propias carpetas de DerivedData: muéstralas desde Settings > Locations en Xcode, ve a la carpeta en el Finder o elimínalas desde Terminal. Las tres vías llevan al mismo sitio.

Borrar proyecto a 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 todos los demás. Borrarlo todo es la opción rápida, y también es válida: simplemente pagas el coste de recompilar todos los proyectos a la vez.

  1. Sal primero de Xcode. Borrar DerivedData con Xcode abierto puede confundir a su indexador, y los archivos que Xcode tenga abiertos podrían no borrarse limpiamente.
  2. Localiza 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 bien, en el Finder, pulsa Mayúsculas + Comando + G e introduce directamente ~/Library/Developer/Xcode/DerivedData.
  3. Ordena las subcarpetas de proyecto por tamaño, selecciona las que quieras eliminar (o pulsa Comando + A para seleccionarlas 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.
  4. 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.
  5. Vuelve a abrir Xcode y compila. Cuenta con que la primera compilación de cada proyecto tarde bastante más y con que «Indexing» aparezca un rato en la barra de actividad: son costes que se pagan una sola vez.

Cuidado con rm -rf: se salta la Papelera y borra de forma definitiva, sin posibilidad de 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.

Elimina los runtimes antiguos del simulador

Los simuladores suelen ser otra gran categoría del almacenamiento de desarrollo. Cada runtime de iOS, watchOS o tvOS descargado ocupa su propio espacio, y cada dispositivo simulado guarda datos en ~/Library/Developer/CoreSimulator/Devices. Si has pasado por varias actualizaciones de Xcode, revisa los runtimes de versiones del sistema que ya no están entre tus objetivos de prueba.

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 marcados como no disponibles (en su mayoría, huérfanos que dejan los runtimes eliminados y las versiones antiguas de Xcode), junto con las apps y los datos que contienen. Revisa antes la lista con xcrun simctl list devices, sobre todo si tienes instalada más de una versión de Xcode, y exporta lo que quieras conservar.

Para los runtimes en sí, abre Settings > Components en Xcode (Platforms en Xcode 14–15). Verás cada runtime de simulador instalado con su tamaño; selecciona uno antiguo y elimínalo. Conserva solo el runtime más reciente de cada plataforma, salvo que pruebes activamente en versiones anteriores del sistema.

También puedes eliminar dispositivos simulados sueltos en Window > Devices and Simulators: ve a la pestaña Simulators, haz clic derecho en cualquier dispositivo que no uses nunca (como esos seis iPhone duplicados con datos de pruebas antiguas) y elige Delete. Los datos guardados y las apps de cada dispositivo desaparecen con él.

Archives, archivos de soporte de dispositivos y cachés

Los archives se acumulan en ~/Library/Developer/Xcode/Archives cada vez que ejecutas Product > Archive para distribuir una build. Cada archive contiene la app completa y sus símbolos de depuración dSYM, a menudo entre 100 MB y 1 GB cada uno. Antes de borrar, ten en cuenta lo que pierdes: los dSYM que contienen son lo que te permite simbolizar los informes de fallos de esa build exacta. Conserva los archives de las versiones que siguen publicadas en el App Store o en 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 a 5 GB cada una. Las carpetas de versiones de iOS que ya no usa ninguno de tus dispositivos son 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). También hay carpetas equivalentes para dispositivos watchOS y tvOS.

Xcode también guarda sus propias cachés en ~/Library/Caches/com.apple.dt.Xcode, y los simuladores las suyas en ~/Library/Developer/CoreSimulator/Caches. Ambas se regeneran cuando hacen falta, pero vacíalas solo con Xcode y la app Simulator cerrados, y no toques los archivos de caché de CoreSimulator que no reconozcas.

Cachés de gestores de paquetes (SwiftPM, CocoaPods, npm, Homebrew)

Los gestores de paquetes conservan las dependencias descargadas para que las instalaciones futuras sean rápidas. Es útil, pero en una máquina con años de proyectos puede convertirse en una categoría importante del disco. Estas cachés de descargas se pueden reconstruir, pero la próxima instalación tendrá que volver 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 al limpiar DerivedData ya se borran. La caché compartida puedes borrarla desde el Finder o con rm -rf sobre esa ruta.

CocoaPods guarda los pods descargados en ~/Library/Caches/CocoaPods. La forma limpia de vaciarla es su 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 está en ~/.npm y puede ocupar muchos gigabytes en una máquina con mucho JavaScript. Ejecuta npm cache clean --force para vaciarla (npm exige esa opción porque la caché se repara sola y normalmente nunca necesita limpieza; borrarla es seguro: los paquetes simplemente se vuelven a descargar en la siguiente instalación). Si usas pnpm, puedes ejecutar pnpm store prune en su lugar.

Homebrew acumula descargas antiguas y versiones obsoletas de paquetes. brew cleanup elimina las versiones obsoletas y las descargas caducadas y, si lo ejecutas sin nombres de paquete, también desinstala las dependencias que ya nada necesita, salvo que HOMEBREW_NO_AUTOREMOVE esté definido; brew cleanup --prune=all vacía además toda la caché de descargas. Ejecuta antes brew cleanup -n si quieres ver una simulación de lo que se eliminaría.

Automatízalo

Todo lo anterior funciona, pero la basura de desarrollo vuelve una y otra vez: DerivedData se recupera en una semana de trabajo normal, las cachés se vuelven a llenar 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 explique su razonamiento en lugar de borrar en bloque sin avisar.

AskClean trata los archivos de desarrollo como categorías propias: un solo escaneo desglosa el DerivedData de Xcode por proyecto, los runtimes antiguos del simulador (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 otros. También detecta los nuevos devoradores de espacio, los modelos de IA locales: muestra los modelos de Hugging Face uno a uno y la biblioteca de modelos de Ollama como un único elemento, todos 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 elementos de limpieza que confirmas se eliminan de forma permanente, sin pasar por la Papelera, así que revisa cada selección antes de confirmar; tu código fuente y tu fototeca nunca se tocan. Es la misma lista de tareas que esta guía, sin la hora de Terminal.

Qué se puede reconstruir y qué no

Esta tabla marca los límites del borrado; no promete un ahorro universal. Mide tu Mac antes y después de cada acción: el script de auditoría de solo lectura de la guía sobre el almacenamiento del simulador de Xcode mide estas carpetas sin cambiar nada.

CategoríaUbicación predeterminadaConsecuencia del borrado
DerivedData~/Library/Developer/Xcode/DerivedDataSe recompila y se reindexa; el código fuente y el historial de git no se tocan.
Dispositivos del simulador~/Library/Developer/CoreSimulator/DevicesSe pierden las apps y los datos de prueba de los dispositivos elegidos; bórralos con simctl o desde Xcode.
Archives~/Library/Developer/Xcode/ArchivesPuedes perder los dSYM necesarios para simbolizar fallos; revísalos antes en Organizer.
DeviceSupport~/Library/Developer/Xcode/iOS DeviceSupportLos símbolos de depuración se vuelven a copiar si conectas de nuevo un dispositivo con esa versión.

Preguntas frecuentes

¿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 están en otro sitio y nunca se ven afectados. La única consecuencia es que la siguiente compilación de cada proyecto será completa y la indexación volverá a ejecutarse.

¿Cada cuánto conviene limpiar DerivedData?

No hay un calendario obligatorio: límpialo cuando ocupe lo bastante como para importar, lo que para la mayoría de los desarrolladores activos significa cada uno o dos meses. Hay dos momentos en que siempre está justificado: cuando necesitas espacio en disco con urgencia y cuando un proyecto muestra errores de compilación inexplicables o un autocompletado desfasado, porque borrar DerivedData es el primer remedio habitual.

¿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 a funcionar 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 y sus datos, y borrarla entera los deja inservibles hasta que reinstales los runtimes. Límpiala por partes: ejecuta xcrun simctl delete unavailable para los dispositivos huérfanos (sus apps y datos se van con ellos), elimina los runtimes antiguos en Settings > Components de Xcode, borra los dispositivos que no uses en Devices and Simulators y vacía a mano solo la subcarpeta Caches, con Xcode y Simulator cerrados.

¿Clean Build Folder hace lo mismo?

No. Product > Clean Build Folder (Mayúsculas + Comando + K) borra solo los productos de compilación 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 liberar disco: recuperar espacio de verdad implica borrar las propias carpetas de DerivedData.

Fuentes

Almacenamiento de desarrollo, paso a paso