¿DerivedData de Xcode ocupando demasiado espacio en Mac? Que limpiar primero

Si compilas apps en Mac todos los días, DerivedData eventualmente se convierte en una de esas carpetas que sabes que es importante, pero también una que esperas que alguien más ya haya limpiado.

Luego un día la carpeta es enorme, el disco está ajustado, Xcode se siente más pesado de lo normal, y la pregunta de limpieza se vuelve inmediata: ¿puedes eliminarla de forma segura, o estás 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 más 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 rápida

Qué suele ser seguro limpiar frente a qué necesita precaución

Qué 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 términos prácticos, eso normalmente significa productos de build, índices, archivos intermedios, output relacionado con previews y otros artefactos generados que ayudan a Xcode a moverse más rápido la próxima vez que compilas o abres el proyecto.

Por eso la carpeta crece tan fácil. Cada proyecto, target, branch, combinación de SDK y flujo de simulador agrega más estado generado con el tiempo.

Esto también explica por qué los desarrolladores tratan DerivedData diferente de los archivos ordinarios del proyecto:

• no es la fuente de verdad de tu código de app;
• existe para ahorrar tiempo de build e indexación;
• se espera que se regenere cuando se necesite.

Ese comportamiento de regeneración es la razón por la que DerivedData suele clasificarse como un objetivo de limpieza más seguro que muchas rutas propiedad de apps o del sistema.

¿Dónde está DerivedData en Mac?

Por defecto, Xcode guarda DerivedData en ~/Library/Developer/Xcode/DerivedData. Eso está dentro de tu carpeta Library de usuario, que Finder oculta por defecto, así que la mayoría de los desarrolladores nunca tropieza con ella directamente.

Dos formas fiables de abrirla:

• Desde Xcode: abre Xcode → Settings → Locations y haz clic en la flecha pequeña junto a la ruta de Derived Data para mostrar la carpeta en Finder.
• Desde Finder: elige Ir → Ir a la carpeta y pega ~/Library/Developer/Xcode/DerivedData.

Dentro verás normalmente una subcarpeta por proyecto más un ModuleCache compartido. Cada carpeta de proyecto es el estado generado de build e índice para ese espacio de trabajo, y eso es lo que hace posible limpiar por proyecto en vez de borrar todo o nada.

Por qué DerivedData de Xcode se vuelve tan grande

La respuesta más simple es acumulación.

Una app activa ya puede generar mucho output de build. Múltiples apps, múltiples branches, previews, ejecuciones de simulador, builds de prueba e historial de resolución de paquetes pueden empujar la carpeta mucho más alto de lo que la mayoría de desarrolladores esperan.

Razones comunes por las que DerivedData se infla:

• varios proyectos activos comparten la misma máquina;
• carpetas stale por proyecto permanecen mucho después de que el proyecto dejó de importar;
• trabajo pesado de preview, indexación y simulador genera churn extra;
• entornos de Xcode de larga vida mantienen output de build antiguo más 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 más es grande y si tu timing es bueno.

Qué 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 áreas adyacentes a Xcode porque no comparten el mismo modelo de riesgo:

Esta es la verdadera razón por la que un escaneo completo de Developer Folder es más útil que la visión de túnel 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 quizás 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 caché desechable. Puede contener entornos de simulador que todavía te importan.

Si el almacenamiento de simuladores es el problema real, la guía 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 área crece a medida que se acumulan diferentes versiones de dispositivos físicos y assets de soporte. Suele pasar desapercibida porque es menos famosa que DerivedData, pero todavía lo suficientemente grande como para importar.

Cachés relacionadas con paquetes

Estas pueden ser objetivos de limpieza más seguros que los datos de simulador o archives, pero todavía son separadas de DerivedData. Si estás persiguiendo espacio recuperable en serio, trata cada perfil como su propio problema de limpieza.

Cuándo 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 tamaño;
• necesitas builds rápidos 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 más razonable cuando:

• toda la carpeta está hinchada a través 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 decisión de timing disfrazada de decisión de almacenamiento. Los ahorros de espacio pueden ser similares, pero el costo en el flujo de trabajo es diferente.

Cómo borrar DerivedData en Mac

Cuando ya has decidido que la limpieza es lo correcto, hay tres formas habituales de borrar DerivedData, de la más segura a la más agresiva.

1. Por proyecto, desde Xcode. Abre Xcode → Settings → Locations, haz clic en la flecha junto a Derived Data para abrir la carpeta y borra solo las subcarpetas de proyectos antiguos que ya no compilas. Así conservas los rebuilds rápidos del trabajo activo.

2. Todo, desde la Terminal. Cuando la carpeta entera está hinchada y aceptas una recompilación puntual, vacíala sin borrar la carpeta en sí:

rm -rf ~/Library/Developer/Xcode/DerivedData/*

3. Cierra Xcode primero. Sal de Xcode antes de un borrado completo para que no esté escribiendo estado de build mientras eliminas. Xcode recrea DerivedData en la siguiente compilación.

El intercambio es el mismo en todos los casos: cambias espacio en disco por el coste de la siguiente compilación y reindexación, no borras código fuente ni ajustes del proyecto. Si no tienes claro qué subcarpetas están obsoletas, revísalas por tamaño y fecha de modificación antes de eliminar nada.

Cómo 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 próximas 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 más grandes.

Si la huella de desarrollador más amplia es el problema, limpiar solo DerivedData puede recuperar menos de lo que esperas.

2. Separa el output generado seguro de los perfiles de precaución

Esta distinción importa:

• DerivedData y cachés suelen ser objetivos de limpieza de estilo seguro porque son generados;
• Archives, CoreSimulator e iOS DeviceSupport merecen más precaución porque pueden preservar artefactos, runtimes o estado que todavía 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:

1. ¿Los directorios DerivedData más grandes están vinculados a proyectos stale o activos?
2. ¿Necesitas builds rápidos e indexación hoy?
3. ¿Los perfiles vecinos son realmente más grandes que DerivedData?
4. ¿Una ventana de rebuild completo dolerá en tu sprint, demo o trabajo de release actual?

Esa revisión corta previene la mayoría de las limpiezas completas innecesarias.

4. Espera costo de rebuild, no pérdida de datos

Para DerivedData, el costo normal de limpieza suele ser:

• próximo build más lento;
• rebuilds de índices;
• previews o inicio de simulador más pesados;
• fricción temporal mientras el output generado vuelve.

Eso es muy diferente de eliminar datos de soporte de app, archives que todavía necesitas o estado de simulador que te importaba. La limpieza de desarrollador solo se mantiene segura cuando mantienes esas categorías separadas.

5. Usa un flujo de limpieza de desarrollador, no eliminación genérica 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 está en un bucket Safe o Caution, cuáles son las probables consecuencias o si se necesita un guided preflight antes de la limpieza.

Ese contexto faltante es por qué la limpieza de desarrollador no debería colapsar en limpieza ordinaria de “archivos más grandes” una vez que las apuestas suben.

Por qué la limpieza de Xcode es diferente de la limpieza ordinaria de archivos

La limpieza ordinaria de archivos hace una pregunta simple: ¿qué es grande?

Si quieres la guía más amplia a través de Xcode, Docker, setups pesados de SDK y perfiles de riesgo de desarrollador, lee Como limpiar cachés de desarrollador en Mac de forma segura.

La limpieza de desarrollador necesita hacer preguntas más difíciles:

• esto es generado o escrito por el usuario;
• este perfil es Safe, Caution o Dangerous;
• necesito Dry Run antes de confiar en el tamaño recuperable;
• necesito Guided Preflight porque el perfil tiene riesgo de flujo de trabajo;
• ¿qué bloqueadores, advertencias o consecuencias debería revisar primero?

Esa diferencia está integrada en el modelo Dev Cleanup de StorageRadar. No opera como eliminación arbitraria. Trabaja desde perfiles de desarrollador conocidos y una política de riesgo.

Por ejemplo, los perfiles actuales de desarrollador de Apple se dividen:

• Xcode DerivedData como Safe;
• Xcode Archives como Caution;
• CoreSimulator Data como Caution;
• iOS DeviceSupport como Caution;
• SwiftPM Cache como Safe.

Eso es lo opuesto al caos de limpieza. Es un flujo consciente del ecosistema que trata las cachés generadas diferente de los artefactos retenidos y el estado de simulador.

Dónde encaja StorageRadar

Eso cambia el flujo de trabajo practico:

• usa Developer Folder cuando toda el área de desarrollador de Apple puede estar hinchada;
• usa Dev Cleanup cuando quieres limpieza consciente del perfil en vez de eliminación ordinaria de archivos;
• mantén los perfiles Safe como DerivedData separados de los perfiles Caution como Archives y almacenamiento relacionado con simuladores.

Esa distinción es todo el valor para una máquina de desarrollador. El producto no solo te dice que una carpeta es grande. Te dice qué tipo de almacenamiento de desarrollador es y que tipo de proceso de limpieza merece.

Qué no hacer

Evita estos errores comunes:

• no asumas que DerivedData es la única carpeta de Xcode que vale la pena revisar;
• no elimines Archives, CoreSimulator e iOS DeviceSupport como 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 lógica de archivos más 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 también están haciendo que System Data parezca sospechosamente grande, la guía complementaria sobre System Data demasiado grande en Mac es la próxima lectura correcta.

Conclusión

Si DerivedData está ocupando demasiado espacio en tu Mac, la parte tranquilizadora es que suele ser uno de los objetivos de limpieza de Xcode más seguros porque es output generado. La parte menos obvia es que DerivedData rara vez es toda la historia.

La mejor decisión de limpieza viene de revisar la huella de desarrollador más amplia, separar perfiles seguros de perfiles de precaución y elegir limpieza selectiva o total basada en tu flujo de trabajo actual en vez de en el pánico.