Xcode: Clean Build Folder frente a borrar DerivedData
Equipo de AskClean · Actualizado 2026-11-02
Clean Build Folder borra los productos de compilación del esquema que tienes abierto. Borrar DerivedData restablece un conjunto más amplio: los productos de compilación más los índices, las cachés de módulos y los registros. Si una compilación falla, empieza por Clean Build Folder; si el índice está dañado, borra la carpeta DerivedData de ese proyecto concreto, y si lo que necesitas es espacio de verdad, borra las carpetas DerivedData de los proyectos que ya no compilas.
La diferencia es el alcance, no la profundidad
Product > Clean Build Folder (Mayúsculas + Comando + K) actúa dentro del proyecto y el esquema que tienes abiertos. Descarta los productos compilados y los archivos intermedios de ese contexto para que la siguiente compilación empiece desde el código fuente. Su alcance es un solo proyecto, y conserva a propósito lo que cuesta reconstruir.
DerivedData es el directorio de nivel superior que comparten todos los proyectos que usan la ubicación predeterminada: ~/Library/Developer/Xcode/DerivedData, con una subcarpeta por cada proyecto o workspace que hayas abierto alguna vez. Borrar una subcarpeta restablece exactamente ese proyecto. Borrar el directorio entero obliga a recompilar y reindexar todos tus proyectos la próxima vez que los abras.
Por eso, describirlos como «limpieza ligera» frente a «limpieza profunda» no es exacto. Clean Build Folder es acotado y barato; borrar DerivedData es amplio y te cuesta el índice. Cuál conviene depende por completo de si lo que está roto vive dentro de los productos de compilación o fuera de ellos.
Si la compilación falla, empieza por lo más acotado
Si el fallo apareció justo después de cambiar de rama, modificar una configuración de compilación o editar archivos de recursos, detén la app en ejecución y usa primero Clean Build Folder. Es el restablecimiento más barato, conserva el índice y te devuelve al trabajo en una sola compilación, en lugar de una compilación más varios minutos de indexación.
Pasa a borrar la carpeta DerivedData de ese proyecto cuando los síntomas no tengan que ver con los productos de compilación: Xcode muestra errores en código que ya corregiste, Jump to Definition te lleva al sitio equivocado o el autocompletado ha dejado de reconocer tus propios tipos. Son síntomas del índice, y Clean Build Folder no toca el índice.
Hay un caso concreto que conviene conocer, porque es el motivo habitual por el que «limpié y no sirvió de nada» acaba en «borré DerivedData y se arregló»: la caché de módulos precompilados (ModuleCache.noindex) está en la raíz de DerivedData, no dentro de la subcarpeta de ningún proyecto. Clean Build Folder nunca llega a ella. Cuando esa caché queda obsoleta tras un cambio de SDK o de cadena de herramientas, solo eliminarla hace desaparecer el error.
Ninguno de los dos comandos corrige un error real en tu código o en tus dependencias. Si el mismo error sobrevive a una compilación limpia, deja de limpiar y lee el mensaje del compilador: la causa está en la configuración del proyecto, en Package.resolved, en el SDK seleccionado o en el propio código.
Ninguno de los dos es una estrategia para liberar disco
Clean Build Folder es una herramienta de diagnóstico que, de paso, libera algunos bytes. Puede devolver espacio del proyecto actual, pero los productos de compilación de los demás proyectos, todos los índices y la caché de módulos siguen exactamente donde estaban. Usarlo para recuperar espacio en disco es apuntar al objetivo equivocado.
Si lo que buscas es espacio, hazlo al revés: mide primero las subcarpetas de DerivedData y borra después las de los proyectos que no abres desde hace meses. Ahí suelen estar las decenas de gigabytes: clones puntuales que compilaste una vez y no volviste a abrir.
No empieces con rm -rf. El Finder te permite mover las carpetas seleccionadas a la Papelera, donde siguen siendo recuperables hasta que la vacías, y esa diferencia importa la primera vez que borras la carpeta de un proyecto que resulta estar compilándose en ese mismo momento. Terminal compensa para automatizar, pero solo después de confirmar la ruta exacta.
Comprueba el resultado en lugar de fiarte de una cifra
Anota el tamaño de DerivedData antes de hacer nada, aplica exactamente una de las dos opciones y vuelve a medir. Después de Clean Build Folder, compila el esquema actual. Después de borrar una carpeta de DerivedData, abre Xcode y espera a que terminen la primera compilación y la indexación.
Hacerlo en ese orden separa el espacio que recuperas del precio que pagas por recuperarlo. No hay una cifra universal que esperar: el resultado depende de cuántos proyectos, configuraciones y arquitecturas se hayan compilado en ese Mac en concreto.
Cuál usar en cada caso
| Situación | Qué hacer | Coste de recuperación |
|---|---|---|
| La compilación falla en el esquema actual | Product > Clean Build Folder | Una recompilación de este proyecto. Se conservan los índices de todos los proyectos. |
| Errores que ya corregiste o Jump to Definition roto | ~/Library/Developer/Xcode/DerivedData/<project> | Recompilación completa y reindexación, solo de ese proyecto. |
| Los errores siguen tras Clean Build Folder después de cambiar de SDK | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | Los módulos se recompilan en la siguiente compilación. Clean Build Folder no llega hasta aquí. |
| De verdad necesitas espacio en disco | ~/Library/Developer/Xcode/DerivedData | Borra las subcarpetas grandes y obsoletas; esos proyectos se recompilan la próxima vez que los abras. |
| Runtimes antiguos del simulador | Xcode Settings > Components | Es una categoría aparte. Ninguno de los dos comandos la toca. |
Esta tabla describe el alcance, no una cantidad de gigabytes garantizada. Mide tu propio Mac antes y después.
Preguntas frecuentes
¿Clean Build Folder borra DerivedData?
No. Borra los productos de compilación del proyecto y el esquema que tienes abiertos. No equivale a borrar el directorio compartido DerivedData, que además guarda los índices, la caché de módulos y los registros de todos los proyectos.
¿Es seguro borrar la carpeta DerivedData de un proyecto?
Sí. Todo lo que contiene se deriva de tu código fuente y Xcode lo regenera. Tu código y tu historial de git no se tocan. El único coste es que la primera compilación posterior es completa y va seguida de una indexación.
¿Tengo que cerrar Xcode antes?
Para borrar DerivedData a mano, sí: así evitas que el indexador retenga o vuelva a crear archivos mientras los eliminas. Para el comando integrado Clean Build Folder, no: es el propio Xcode quien lo ejecuta.
¿Por qué sigue el error después de limpiar?
Lo más probable es que la causa nunca fuera la caché. Revisa el mensaje del compilador, la configuración del esquema, las versiones de las dependencias, Package.resolved, el SDK seleccionado y qué ha cambiado realmente en tu rama actual.
Clean Build Folder no sirvió, pero borrar DerivedData lo arregló. ¿Por qué?
Normalmente, por la caché de módulos precompilados. ModuleCache.noindex está en la raíz de DerivedData y no dentro de la subcarpeta de un proyecto, así que Clean Build Folder no llega a ella; borrar DerivedData, sí.
Fuentes