Si compilas apps en Mac todos los dias, DerivedData eventualmente se convierte en una de esas carpetas que sabes que es importante, pero tambien una que esperas que alguien mas ya haya limpiado.
Luego un dia la carpeta es enorme, el disco esta ajustado, Xcode se siente mas pesado de lo normal, y la pregunta de limpieza se vuelve inmediata: puedes eliminarla de forma segura, o estas a punto de convertir tu jornada en un caos de rebuilds?
La respuesta corta es que DerivedData suele ser uno de los objetivos de limpieza de Xcode mas seguros. La respuesta larga es que los desarrolladores a menudo se enfocan demasiado en DerivedData y pasan por alto el resto de la huella del ecosistema de Apple sentada cerca.
Respuesta rapida
DerivedDataes output generado de build e indexacion de Xcode.- Normalmente es mas seguro de eliminar que muchas otras carpetas de desarrollador porque Xcode puede reconstruirlo.
- El tradeoff es tiempo: builds mas lentos, reindexacion e inicio de simulador o preview mas pesado despues de la limpieza.
DerivedDatano es toda la huella de desarrollador de Apple.Archives,CoreSimulatoreiOS DeviceSupportsuelen crecer cerca.- La limpieza selectiva suele ser mejor que eliminar todo si solo algunos proyectos antiguos son grandes.
- La limpieza de desarrollador deberia ser consciente del ecosistema y del riesgo, no solo "elimina la carpeta mas grande que encuentres."
Que suele ser seguro limpiar versus que necesita precaucion
Normalmente seguro primero
Output generadoDerivedData y artefactos de desarrollador Apple tipo cache suelen ser los primeros objetivos de revision porque estan disenados para regenerarse.
Perfiles de precaucion
Estado y entregablesArchives, CoreSimulator e iOS DeviceSupport pueden preservar artefactos, runtimes o estado de simulador que todavia necesitas.
Costo esperado de rebuild
Tradeoff principalEl costo normal despues de la limpieza es builds mas lentos, reindexacion e inicio de simulador o preview mas pesado, no perdida permanente de datos del proyecto.
Que es realmente DerivedData de Xcode
DerivedData es donde Xcode guarda el output generado de build y los datos de trabajo relacionados para los flujos de desarrollo. En terminos practicos, eso normalmente significa productos de build, indices, archivos intermedios, output relacionado con previews y otros artefactos generados que ayudan a Xcode a moverse mas rapido la proxima vez que compilas o abres el proyecto.
Por eso la carpeta crece tan facil. Cada proyecto, target, branch, combinacion de SDK y flujo de simulador agrega mas estado generado con el tiempo.
Esto tambien explica por que los desarrolladores tratan DerivedData diferente de los archivos ordinarios del proyecto:
- no es la fuente de verdad de tu codigo de app;
- existe para ahorrar tiempo de build e indexacion;
- se espera que se regenere cuando se necesite.
Ese comportamiento de regeneracion es la razon por la que DerivedData suele clasificarse como un objetivo de limpieza mas seguro que muchas rutas propiedad de apps o del sistema.
Por que DerivedData de Xcode se vuelve tan grande
La respuesta mas simple es acumulacion.
Una app activa ya puede generar mucho output de build. Multiples apps, multiples branches, previews, ejecuciones de simulador, builds de prueba e historial de resolucion de paquetes pueden empujar la carpeta mucho mas alto de lo que la mayoria de desarrolladores esperan.
Razones comunes por las que DerivedData se infla:
- varios proyectos activos comparten la misma maquina;
- carpetas stale por proyecto permanecen mucho despues de que el proyecto dejo de importar;
- trabajo pesado de preview, indexacion y simulador genera churn extra;
- entornos de Xcode de larga vida mantienen output de build antiguo mas de lo que piensas;
- limpias otras cosas pero nunca tocas artefactos de desarrollador Apple generados.
El punto importante es que un DerivedData grande no es inusual en un Mac de desarrollador. Se convierte en problema solo cuando asumes que la respuesta correcta es siempre “elimina todo ahora” sin verificar que mas es grande y si tu timing es bueno.
Que otra cosa cerca de DerivedData suele crecer
Los desarrolladores a menudo culpan a DerivedData porque les es familiar, pero es solo un perfil en la huerta del ecosistema de Apple.
Los perfiles actuales de StorageRadar del lado de Apple separan estas areas adyacentes a Xcode porque no comparten el mismo modelo de riesgo:
| Perfil | Ruta tipica | Por que crece | Perfil de riesgo |
|---|---|---|---|
| Xcode DerivedData | ~/Library/Developer/Xcode/DerivedData | Productos de build, indices, intermedios, output generado del proyecto | Seguro |
| Xcode Archives | ~/Library/Developer/Xcode/Archives | Archives de distribucion e historial de builds exportados | Precaucion |
| CoreSimulator Data | ~/Library/Developer/CoreSimulator | Runtimes instalados, estado de simulador, datos de apps dentro de simuladores | Precaucion |
| iOS DeviceSupport | ~/Library/Developer/Xcode/iOS DeviceSupport | Assets de soporte de dispositivo para versiones de iOS conectadas | Precaucion |
| SwiftPM Cache | ~/Library/Caches/org.swift.swiftpm | Datos de cache del gestor de paquetes | Seguro |
Esta es la verdadera razon por la que un escaneo completo de Developer Folder es mas util que la vision de tunel en un directorio. Si DerivedData es 12 GB pero CoreSimulator es 35 GB y Archives es 18 GB, el plan de limpieza cambia completamente.
Carpetas de desarrollador de Apple que suelen crecer con DerivedData
Archives
Los Archives no son solo espacio temporal generado. Pueden representar entregables que quizas realmente quieras conservar. Por eso pertenecen a un bucket de limpieza diferente de DerivedData.
CoreSimulator
Los datos de simulador pueden superar silenciosamente a DerivedData, especialmente si pruebas en muchos runtimes o conservas estado de simulador por mucho tiempo. No es solo una carpeta de cache desechable. Puede contener entornos de simulador que todavia te importan.
Si el almacenamiento de simuladores es el problema real, la guia enfocada en Simulador de Xcode ocupando espacio en Mac? Que limpiar primero profundiza en runtimes, estado de dispositivos y tradeoffs de limpieza.
iOS DeviceSupport
Esta area crece a medida que se acumulan diferentes versiones de dispositivos fisicos y assets de soporte. Suele pasar desapercibida porque es menos famosa que DerivedData, pero todavia lo suficientemente grande como para importar.
Caches relacionadas con paquetes
Estas pueden ser objetivos de limpieza mas seguros que los datos de simulador o archives, pero todavia son separadas de DerivedData. Si estas persiguiendo espacio recuperable en serio, trata cada perfil como su propio problema de limpieza.
Cuando la limpieza selectiva es mejor que eliminar todo
El reflejo predeterminado del desarrollador suele ser limpieza total: elimina toda la carpeta, deja que Xcode reconstruya, sigue adelante.
Eso puede estar bien, pero no siempre es el mejor movimiento.
La limpieza selectiva suele ser mejor cuando:
- solo algunos proyectos antiguos son responsables de la mayor parte del tamano;
- necesitas builds rapidos y predecibles para tus apps activas actuales;
- no quieres forzar una reindexacion completa de todo hoy;
- sospechas que branches stale o workspaces retirados son el problema real, no los proyectos actuales.
Una limpieza completa es mas razonable cuando:
- toda la carpeta esta hinchada a traves de muchos proyectos antiguos;
- quieres un reinicio limpio del output generado;
- la lentitud actual vale la pena intercambiar por una ventana de rebuild controlada;
- sospechas que el estado generado global es parte del problema.
Esto realmente es una decision de timing disfrazada de decision de almacenamiento. Los ahorros de espacio pueden ser similares, pero el costo en el flujo de trabajo es diferente.
Regla de limpieza de desarrollador: Elimina la certeza mas antigua primero. Si algunas carpetas de proyectos stale explican la mayor parte del tamano, la limpieza selectiva suele ser mejor que un reinicio completo.
Como limpiar DerivedData de Xcode sin crear caos de rebuild
El objetivo seguro no es solo “liberar espacio.” El objetivo seguro es “liberar el espacio correcto mientras mantienes las proximas horas de desarrollo predecibles.”
1. Revisa toda la imagen de desarrollador primero
Empieza desde Developer Folder si lo tienes, no desde DerivedData en aislamiento. El punto es ver si el output de Xcode es realmente el problema dominante o si otros perfiles de desarrollador de Apple son mas grandes.
Si la huella de desarrollador mas amplia es el problema, limpiar solo DerivedData puede recuperar menos de lo que esperas.
2. Separa el output generado seguro de los perfiles de precaucion
Esta distincion importa:
DerivedDatay caches suelen ser objetivos de limpieza de estilo seguro porque son generados;Archives,CoreSimulatoreiOS DeviceSupportmerecen mas precaucion porque pueden preservar artefactos, runtimes o estado que todavia necesitas.
Una vez que difuminas esos juntos, “limpieza de desarrollador” se convierte en solo otra purga peligrosa de carpetas.
3. Decide entre limpieza selectiva y total deliberadamente
Antes de eliminar cualquier cosa, responde estas preguntas:
- Los directorios
DerivedDatamas grandes estan vinculados a proyectos stale o activos? - Necesitas builds rapidos e indexacion hoy?
- Los perfiles vecinos son realmente mas grandes que
DerivedData? - Una ventana de rebuild completo dolera en tu sprint, demo o trabajo de release actual?
Esa revision corta previene la mayoria de las limpiezas completas innecesarias.
4. Espera costo de rebuild, no perdida de datos
Para DerivedData, el costo normal de limpieza suele ser:
- proximo build mas lento;
- rebuilds de indices;
- previews o inicio de simulador mas pesados;
- friccion temporal mientras el output generado vuelve.
Eso es muy diferente de eliminar datos de soporte de app, archives que todavia necesitas o estado de simulador que te importaba. La limpieza de desarrollador solo se mantiene segura cuando mantienes esas categorias separadas.
5. Usa un flujo de limpieza de desarrollador, no eliminacion generica de archivos
Un navegador de archivos plano puede decirte que algo es grande. No puede decirte si la ruta es un perfil de desarrollador conocido, si esta en un bucket Safe o Caution, cuales son las probables consecuencias o si se necesita un guided preflight antes de la limpieza.
Ese contexto faltante es por que la limpieza de desarrollador no deberia colapsar en limpieza ordinaria de “archivos mas grandes” una vez que las apuestas suben.
Por que la limpieza de Xcode es diferente de la limpieza ordinaria de archivos
La limpieza ordinaria de archivos hace una pregunta simple: que es grande?
Si quieres la guia mas amplia a traves de Xcode, Docker, setups pesados de SDK y perfiles de riesgo de desarrollador, lee Como limpiar caches de desarrollador en Mac de forma segura.
La limpieza de desarrollador necesita hacer preguntas mas dificiles:
- esto es generado o escrito por el usuario;
- este perfil es
Safe,CautionoDangerous; - necesito
Dry Runantes de confiar en el tamano recuperable; - necesito
Guided Preflightporque el perfil tiene riesgo de flujo de trabajo; - que bloqueadores, advertencias o consecuencias deberia revisar primero?
Esa diferencia esta integrada en el modelo Dev Cleanup de StorageRadar. No opera como eliminacion arbitraria. Trabaja desde perfiles de desarrollador conocidos y una politica de riesgo.
Por ejemplo, los perfiles actuales de desarrollador de Apple se dividen:
Xcode DerivedDatacomoSafe;Xcode ArchivescomoCaution;CoreSimulator DatacomoCaution;iOS DeviceSupportcomoCaution;SwiftPM CachecomoSafe.
Eso es lo opuesto al caos de limpieza. Es un flujo consciente del ecosistema que trata las caches generadas diferente de los artefactos retenidos y el estado de simulador.
Donde encaja StorageRadar
Eso cambia el flujo de trabajo practico:
- usa
Developer Foldercuando toda el area de desarrollador de Apple puede estar hinchada; - usa
Dev Cleanupcuando quieres limpieza consciente del perfil en vez de eliminacion ordinaria de archivos; - mantén los perfiles
SafecomoDerivedDataseparados de los perfilesCautioncomoArchivesy almacenamiento relacionado con simuladores.
Esa distincion es todo el valor para una maquina de desarrollador. El producto no solo te dice que una carpeta es grande. Te dice que tipo de almacenamiento de desarrollador es y que tipo de proceso de limpieza merece.
Revisa la huella de desarrollador antes de eliminar la carpeta equivocada de Xcode.
Ver Dev CleanupQue no hacer
Evita estos errores comunes:
- no asumas que
DerivedDataes la unica carpeta de Xcode que vale la pena revisar; - no elimines
Archives,CoreSimulatoreiOS DeviceSupportcomo si tuvieran el mismo perfil de riesgo; - no hagas un reinicio completo justo antes de un deadline si el tiempo de rebuild importa;
- no uses logica de archivos mas grandes sola para artefactos de desarrollador que necesitan contexto de ecosistema;
- no confundas output de build generado con datos de proyecto, entregables o estado de simulador retenido.
Si los artefactos de desarrollador de Apple tambien estan haciendo que System Data parezca sospechosamente grande, la guia complementaria sobre System Data demasiado grande en Mac es la proxima lectura correcta.
Conclusion
Si DerivedData esta ocupando demasiado espacio en tu Mac, la parte tranquilizadora es que suele ser uno de los objetivos de limpieza de Xcode mas seguros porque es output generado. La parte menos obvia es que DerivedData rara vez es toda la historia.
La mejor decision de limpieza viene de revisar la huella de desarrollador mas amplia, separar perfiles seguros de perfiles de precaucion y elegir limpieza selectiva o total basada en tu flujo de trabajo actual en vez de en el panico.
Preguntas frecuentes
Puedo eliminar DerivedData de Xcode en Mac?
En la mayoria de los casos, si. DerivedData es output generado de build e indexacion, asi que Xcode puede reconstruirlo. El tradeoff es builds mas lentos, reindexacion y inicio de simulador o preview mas pesado justo despues de la limpieza.
Por que DerivedData de Xcode se vuelve tan grande?
Crece porque Xcode acumula productos de build, indices, intermedios, previews y output generado especifico del proyecto a traves de multiples proyectos, branches, SDKs y combinaciones de simuladores.
Que otra cosa cerca de DerivedData suele crecer?
Los consumidores de almacenamiento vecinos comunes de Xcode incluyen Archives, datos de CoreSimulator, iOS DeviceSupport y a veces caches relacionadas con paquetes. Si la limpieza de DerivedData apenas cambia el espacio libre, esos son los siguientes lugares para revisar.
Deberia eliminar todo DerivedData o solo algunos proyectos?
Depende de tu flujo de trabajo. Si solo algunos proyectos antiguos estan stale, la limpieza selectiva suele ser mejor porque preserva la velocidad de rebuild para el trabajo activo. Una limpieza completa tiene mas sentido cuando toda la carpeta esta hinchada o corrupta.
En que se diferencia Dev Cleanup de la limpieza ordinaria de archivos?
Dev Cleanup usa perfiles de ecosistema conocidos, etiquetas de riesgo, Dry Run y Guided Preflight para rutas de mayor riesgo. La limpieza ordinaria de archivos solo te dice que los archivos son grandes; no agrega contexto especifico de desarrollador ni verificaciones de flujo de trabajo.
DerivedData es lo mismo que Archives o datos de simuladores?
No. DerivedData es generalmente output de build generado y mas seguro de eliminar. Archives, datos de CoreSimulator e iOS DeviceSupport tienen un perfil de riesgo diferente porque pueden preservar entregables, assets de soporte de dispositivos o estado de simulador que todavia necesitas.