Si el Simulador de Xcode está ocupando espacio en tu Mac, separa los runtimes de simuladores de los datos de dispositivo de simuladores antes de eliminar cualquier cosa. Empieza revisando que no esta disponible, que esta inactivo y que todavía necesitas para testing, porque la limpieza de simuladores se vuelve riesgosa cuando tratas cada carpeta del lado de Apple como caché desechable.
Ese es el error que cometen los desarrolladores después de aprender una regla de limpieza y aplicarla en todos lados. DerivedData es una cosa. Los runtimes de simuladores y el estado de dispositivo de simuladores son otra.
El almacenamiento puede ser recuperable. Las consecuencias simplemente son menos uniformes.
Regla principal: limpia el almacenamiento de simuladores por capas. Elimina dispositivos no disponibles primero, borra datos de dispositivo solo cuando quieres reiniciarlos y elimina runtimes solo cuando ya no necesitas esa versión del SO.
Respuesta rápida
- Verifica si la huella real son runtimes de simuladores, datos de dispositivo de simuladores o ambos.
- Usa
xcrun simctl list devicesyxcrun simctl list runtimesantes de eliminar cualquier cosa. - Elimina dispositivos no disponibles primero con
xcrun simctl delete unavailablecuando aparezcan en la sección de no disponibles. - Usa
erasesolo cuando quieras reiniciar los contenidos y configuraciones de un dispositivo de simulador. - Elimina runtimes solo cuando estés seguro de que ya no necesitas esa versión de plataforma para builds, previews o testing.
- Si el almacenamiento del lado de Apple es más amplio que solo simuladores, revisa
DerivedData,ArchivesyCoreSimulatorjuntos en vez de adivinar desde una carpeta.
¿Qué es CoreSimulator en Mac?
CoreSimulator es la carpeta gestionada por Apple donde Xcode guarda los runtimes de simulador y los dispositivos simulados que usa para compilar y probar apps de iOS, iPadOS, watchOS y tvOS. En la mayoría de los Mac está en ~/Library/Developer/CoreSimulator y crece a medida que añades runtimes, creas dispositivos y acumulas datos de apps dentro de ellos.
No es una caché cualquiera. La carpeta mezcla dos cosas distintas: imágenes de runtime de las que quizá todavía dependes y estado de dispositivo que en muchos casos puedes reiniciar o eliminar. Por eso “CoreSimulator ocupa decenas de gigas” tiene más de una respuesta.
¿Puedo borrar la carpeta CoreSimulator?
A ciegas y de una vez, no. Recuperas casi todo el espacio vaciando la capa correcta en lugar de borrar la ruta entera.
Si borras ~/Library/Developer/CoreSimulator a mano, Xcode tiene que reconstruir el estado de los simuladores y desaparecen runtimes que todavía necesitas. El equivalente seguro es dejar que la propia herramienta simctl de Apple retire lo que sí es desechable:
- elimina los dispositivos que el SDK actual ya no admite con
xcrun simctl delete unavailable; - reinicia el contenido y los ajustes de un dispositivo con
xcrun simctl erase <device>cuando el problema es el estado inflado de las apps; - elimina un runtime con
xcrun simctl runtime deletesolo cuando ya no pruebas esa versión del sistema.
El espacio de CoreSimulator se recupera por capas, no borrando la carpeta y esperando que Xcode se recupere.
Qué almacenan los simuladores de Xcode y por qué se acumulan
El almacenamiento de simuladores no es una cosa. Son varias capas que se acumulan juntas.
A nivel alto, el almacenamiento de simuladores de Xcode suele incluir:
- imágenes de runtime para diferentes versiones de plataforma iOS;
- dispositivos de simulador creados para diferentes modelos de iPhone e iPad;
- datos de app por dispositivo, configuraciones y estado dentro de esos simuladores;
- churn de desarrollo del lado de Apple que crece cuando cambias de SDKs, tipos de dispositivos y versiones de Xcode.
Por eso los desarrolladores a menudo se sienten confundidos por CoreSimulator. Es fácil ver el tamaño de la carpeta y asumir que todo es solo caché. En la práctica, parte es más como estado de prueba desechable y parte es soporte de runtime del que todavía dependes.
El patrón de crecimiento es normal:
- instalas un Xcode o SDK nuevo;
- aparecen nuevos runtimes;
- se crean nuevos dispositivos de simulador;
- apps, datos de prueba y configuraciones se acumulan dentro de ellos;
- dispositivos viejos se vuelven no disponibles después de cambios de SDK o actualizaciones de Xcode;
- nada se revisa durante meses porque la máquina todavía tiene suficiente espacio libre.
Luego un día el almacenamiento de simuladores es la historia principal, no solo un detalle.
Runtimes de simuladores vs datos de simuladores: ¿Cuál es la diferencia?
Esta es la distinción que más importa.
El tooling simctl de Apple trata las operaciones de runtime separadamente de las operaciones de dispositivo. Eso solo te dice que el modelo de limpieza es por capas: los dispositivos no son lo mismo que los runtimes, y borrar un dispositivo no es lo mismo que eliminar una imagen de runtime.
| Capa | Que representa | Acción de limpieza típica | Tradeoff principal |
|---|---|---|---|
| Runtimes de simuladores | Las imágenes de runtime del SO usadas para arrancar versiones de plataforma específicas | simctl runtime delete para un runtime que realmente ya no necesitas | Pierdes ese runtime para uso futuro de simulador hasta que lo vuelvas a agregar |
| Dispositivos de simuladores | Instancias de simulador creadas para modelos de dispositivos específicos | simctl delete o delete unavailable | La instancia del dispositivo desaparece |
| Contenidos y configuraciones de dispositivos de simuladores | Apps instaladas, datos de apps, configuraciones y estado dentro de un dispositivo | simctl erase | El dispositivo permanece, pero sus contenidos y configuraciones se reinician |
Por eso afirmaciones amplias como “simplemente limpia CoreSimulator” son un consejo débil. Colapsan diferentes consecuencias de limpieza en una acción emocional.
Dónde encaja DerivedData
DerivedData es adyacente, pero no es el mismo problema.
DerivedData es generalmente output de build generado. El almacenamiento de simuladores es más mixto. Puede incluir runtimes que todavía necesitas, dispositivos creados que ya no necesitas y estado dentro de dispositivos que puede o no importarte.
Si la presión es mayormente output de build generado, la guía correcta es ¿DerivedData de Xcode ocupando demasiado espacio en Mac? Que limpiar primero. Si la presión es mayormente imágenes de runtime y estado de simuladores, mantente en el flujo de simuladores.
Cómo verificar cuánto espacio están usando los simuladores
El primer movimiento es inspección, no eliminación.
Usa el propio tooling de Apple para ver qué dispositivos y runtimes realmente existen:
xcrun simctl list devices
xcrun simctl list runtimesSi quieres inspeccionar la huerta amplia de almacenamiento del lado de Apple en disco, también puedes comparar las carpetas principales directamente:
du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/ArchivesEsto importa porque la carpeta más grande del lado de Apple no siempre es la que asumiste. A veces DerivedData es el problema dominante. A veces CoreSimulator la supera silenciosamente.
Qué buscar primero
- dispositivos listados bajo
Unavailable; - runtimes para versiones de SO que ya no testeas;
- muchos dispositivos creados a través de varias generaciones de runtime;
- estado pesado de simuladores en una máquina que no se ha limpiado desde múltiples actualizaciones de Xcode;
- una carpeta
CoreSimulatorgrande que no coincide con tus necesidades actuales de testing.
Ese es el punto donde la limpieza empieza a ser racional en vez de reactiva.
Cómo eliminar simuladores en Xcode paso a paso
Cuando quieres eliminar simuladores y no solo inspeccionarlos, tienes dos caminos seguros: la interfaz de Xcode y la línea de comandos con simctl. Ambos retiran simuladores viejos sin tocar los runtimes que aún necesitas.
Desde la app Xcode:
- Abre Xcode y ve a Window → Devices and Simulators.
- Selecciona la pestaña Simulators.
- Haz clic derecho en un simulador que ya no necesitas y elige Delete, o usa Delete Unavailable Simulators para los dispositivos que el SDK actual ya no admite.
Desde la línea de comandos:
# primero, listar todo
xcrun simctl list devices
# eliminar todos los dispositivos marcados como unavailable por el SDK actual
xcrun simctl delete unavailable
# eliminar un dispositivo concreto por su UDID
xcrun simctl delete <device-UDID>Eliminar los simuladores no disponibles es la primera pasada más limpia, porque solo retira dispositivos que Apple ya marca como no admitidos. Eliminar un dispositivo concreto quita esa instancia de simulador pero deja su imagen de runtime en su sitio, así que puedes recrearlo si un proyecto lo necesita.
Si tu objetivo es recuperar espacio, empieza aquí antes de pensar en los runtimes: un dispositivo borrado se vuelve a crear rápido, un runtime borrado es la decisión más pesada.
¿Es seguro eliminar runtimes de simuladores en Mac?
A veces, pero este no es el primer movimiento más seguro.
La ayuda de simctl runtime de Apple deja claro que las imágenes de runtime son sus propios objetos gestionados. Eliminar un runtime es diferente de limpiar los contenidos de un simulador. También es diferente de eliminar un dispositivo no disponible.
Eso significa que la eliminación de runtime es mejor cuando:
- ya no necesitas esa versión de iOS para testing;
- has pasado a una generación de Xcode o SDK más antigua;
- el runtime esta suficientemente sin uso como para que el espacio valga más que la conveniencia;
- has revisado la lista de runtimes primero y sabes exactamente que estás eliminando.
Es una peor idea cuando:
- un proyecto activo todavía apunta a esa familia de runtime;
- previews de SwiftUI, pasos de repro de QA o testing de regresión todavía dependen de ella;
- estás a punto de hacer demo o debugear un issue en un target antiguo;
- estás eliminando basándote solo en el tamaño en vez de en las necesidades reales de testing.
Mejor primer movimiento: elimina el peso muerto obvio
La limpieza de simuladores más segura suele empezar con dispositivos no disponibles.
Apple documenta esto directamente en simctl delete: el alias unavailable elimina dispositivos que no están soportados por el SDK actual de Xcode.
xcrun simctl delete unavailableEso no es una respuesta universal, pero es una de las primeras pasadas más limpias porque apunta a dispositivos ya marcados como no soportados por tu contexto de SDK actual.
Limpiar datos de simuladores sin perder tu entorno de desarrollo
Aquí es donde los desarrolladores a menudo usan la herramienta equivocada para el trabajo.
Si tu problema son datos de app stale o estado de dispositivo hinchado dentro de los simuladores, puede que no necesites eliminar runtimes en absoluto. Puede que solo necesites reiniciar los dispositivos de simulador.
La ayuda de simctl erase de Apple define erase como borrar los contenidos y configuraciones de un dispositivo:
xcrun simctl erase <device>Eso es una operación de reinicio, no una operación de eliminación de runtime.
Para que es bueno erase
- limpiar estado de app dentro de un simulador;
- reiniciar entornos de prueba;
- eliminar contenidos a nivel de dispositivo hinchados sin eliminar la imagen de runtime en si;
- mantener el flujo de trabajo del dispositivo mientras se descarta su estado acumulado.
Qué no es erase
- no es un comando de limpieza de runtime;
- no es un comando de limpieza de
DerivedData; - no es un buen reemplazo para revisar qué dispositivos y runtimes realmente todavía necesitas.
Esa distinción es toda la historia de limpieza de simuladores: borrar un dispositivo, eliminar un dispositivo y eliminar un runtime son tres decisiones diferentes.
Dónde vive CoreSimulator en el disco
Cuando auditas el almacenamiento de simuladores, importan dos rutas.
~/Library/Developer/CoreSimulator/Devices contiene los dispositivos simulados que has creado. Cada dispositivo es una carpeta con su UDID por nombre, y el data/ de dentro lleva las apps instaladas, sus datos y los ajustes. Esta es la capa que simctl erase reinicia y que simctl delete retira.
La carpeta /Library/Developer/CoreSimulator a nivel de sistema lleva el lado de los runtimes. Según tu versión de Xcode, las imágenes están bajo Profiles/Runtimes como paquetes .simruntime, o Xcode las gestiona como runtimes descargables que muestra xcrun simctl runtime list. Lo que retires ahí afecta a todas las cuentas de usuario del Mac, así que trátalo como la decisión más pesada.
du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh /Library/Developer/CoreSimulator
xcrun simctl runtime listSi domina Devices, tu problema es el estado acumulado de los dispositivos y los que el SDK actual ya no admite. Si domina la carpeta de sistema, el problema son las imágenes de runtime.
¿Se puede mover CoreSimulator a un disco externo?
La pregunta aparece cuando el disco interno es pequeño y la carpeta de simuladores pasa de 40 GB. Apple no ofrece ningún ajuste admitido para moverla, así que los desarrolladores tiran de enlace simbólico: copiar ~/Library/Developer/CoreSimulator al volumen externo, verificar la copia, retirar el original y enlazar la ruta antigua con la nueva.
A lo que te comprometes:
- Xcode no puede arrancar simuladores cuando el disco no está montado, porque la ruta desaparece;
- en un disco USB alimentado por el bus los simuladores arrancan más lento que en el SSD interno;
- una actualización de Xcode o del SDK puede recrear parte de la estructura en la ruta original;
- las copias de seguridad y los permisos se comportan distinto en volúmenes externos.
Mide el espacio recuperable antes de mover la carpeta entera. Eliminar dispositivos no disponibles y runtimes que ya no pruebas libera a menudo más de lo que aporta el traslado, y deja la configuración tal como Apple la admite.
Cómo gestionar el almacenamiento de simuladores hacia adelante
El objetivo practico no es “nunca dejar crecer los simuladores.” El objetivo practico es “evitar que el almacenamiento de simuladores se vuelva invisible.”
Usa un ritmo de revisión como este:
- Lista dispositivos y runtimes después de cambios importantes de Xcode o SDK.
- Elimina dispositivos no disponibles cuando aparezcan.
- Reinicia dispositivos de simuladores stale cuando el problema es estado de dispositivo, no inventario de runtimes.
- Revisa el uso de runtimes antes de eliminar una versión de SO completamente.
- Compara
CoreSimulator,DerivedDatayArchivesjuntos cuando el almacenamiento del lado de Apple empiece a subir.
Eso mantiene la decisión de limpieza alineada con la capa que realmente es costosa.
Un mejor modelo mental para el almacenamiento del lado de Apple
DerivedDataes mayormente output de build generado.Archivespreservan entregables e historial de builds.CoreSimulatormezcla soporte de runtime con estado de dispositivos de simulador.- la limpieza más segura depende de que capa es grande, no solo de que carpeta es visible.
Una vez que piensas en capas, la limpieza de simuladores se vuelve mucho menos caótica.
Por qué la limpieza de desarrollador funciona mejor cuando se mantiene consciente del ecosistema
Si solo usas Finder, una carpeta del lado de Apple de 20 GB o 30 GB parece un objetivo de limpieza obvio. No lo es.
Un navegador de archivos puede mostrarte que CoreSimulator es grande. No puede decirte si el espacio realmente recuperable es:
- dispositivos no soportados;
- contenidos de simuladores reiniciables;
- runtimes que ya no necesitas;
- o un perfil vecino de Xcode que solo vive cerca.
Por eso la limpieza de simuladores pertenece dentro de la limpieza de desarrollador, no limpieza genérica de archivos.
Si tu problema real es “simuladores más DerivedData más otro almacenamiento de desarrollador de Apple,” ese flujo más amplio consciente del perfil es mucho más útil que perseguir una ruta de carpeta a la vez.
Conclusión
Si el Simulador de Xcode está ocupando espacio en tu Mac, no trates CoreSimulator como un bucket de caché desechable.
Revisa dispositivos y runtimes primero. Elimina dispositivos no disponibles como la primera pasada limpia, usa erase solo cuando quieras reiniciar contenidos y configuraciones del simulador, y elimina runtimes solo cuando realmente ya no necesitas esa versión del SO.
Ese es el camino de limpieza más seguro: separa las imágenes de runtime del estado de dispositivo, separa el almacenamiento de simuladores de DerivedData y mantén la limpieza del lado de Apple vinculada a las necesidades reales de testing en vez de eliminación ciega de carpetas.
Preguntas frecuentes
¿Por qué el Simulador de Xcode ocupa tanto espacio en disco en Mac?
El almacenamiento del simulador crece porque Xcode mantiene imágenes de runtime, dispositivos de simulador creados, datos de apps dentro de esos simuladores y otro estado de desarrollo del lado de Apple con el tiempo. Probar en varias versiones de iOS y tipos de dispositivos hace que la huella se expanda rápidamente.
¿Cuál es la diferencia entre runtimes de simuladores y datos de simuladores?
Los runtimes de simuladores son las imágenes de runtime del SO que Xcode usa para arrancar simuladores para versiones específicas de plataforma. Los datos de simuladores son el estado a nivel de dispositivo dentro de los simuladores creados, como apps instaladas, datos de apps y configuraciones.
¿Es seguro eliminar dispositivos de simulador no disponibles?
Normalmente si. La herramienta simctl de Apple soporta explícitamente la eliminación de dispositivos no disponibles, que son dispositivos que ya no soporta el SDK actual de Xcode. Ese suele ser uno de los pasos de limpieza de simulador más seguros.
¿Es seguro eliminar runtimes de simuladores en Mac?
A veces, pero solo cuando sabes que ya no necesitas ese runtime para testing, previews o targets de proyectos antiguos. Eliminar un runtime es una decisión más grande que borrar contenidos del simulador porque remueve la imagen de runtime en si.
¿Borrar un simulador elimina el runtime?
No. La ayuda de simctl de Apple describe erase como borrar los contenidos y configuraciones de un dispositivo. Eso reinicia el dispositivo del simulador, pero es diferente de eliminar la imagen de runtime detrás de el.
¿Qué es CoreSimulator en Mac?
CoreSimulator es la carpeta gestionada por Apple en ~/Library/Developer/CoreSimulator donde Xcode guarda los runtimes de simulador y los dispositivos simulados creados para pruebas. Crece con cada runtime añadido, cada dispositivo creado y los datos de app acumulados dentro, así que mezcla almacenamiento que todavía necesitas con almacenamiento que puedes reiniciar o eliminar.
¿Puedo borrar la carpeta CoreSimulator?
No de forma segura como carpeta única, porque eso retira runtimes que aún necesitas y obliga a Xcode a reconstruir el estado de los simuladores. Recupera el espacio por capas: xcrun simctl delete unavailable retira los dispositivos no admitidos, xcrun simctl erase reinicia el contenido de un dispositivo, y xcrun simctl runtime delete solo para una versión del sistema que ya no pruebas.
¿Cómo elimino simuladores en Xcode?
En Xcode abre Window y luego Devices and Simulators, selecciona la pestaña Simulators y elimina un simulador con clic derecho, o usa Delete Unavailable Simulators. Desde la línea de comandos, xcrun simctl delete unavailable retira los dispositivos que el SDK actual ya no admite, y xcrun simctl delete <UDID> retira un dispositivo concreto dejando su imagen de runtime en su sitio.
¿Dónde está la carpeta CoreSimulator en Mac?
Los dispositivos simulados están en ~/Library/Developer/CoreSimulator/Devices, donde cada carpeta lleva su UDID por nombre y guarda apps instaladas y ajustes en data/. Las imágenes de runtime están en la carpeta de sistema /Library/Developer/CoreSimulator, como paquetes .simruntime bajo Profiles/Runtimes o como runtimes descargables que muestra xcrun simctl runtime list, según la versión de Xcode.
¿Puedo mover los simuladores de Xcode a un disco externo?
Apple no ofrece un ajuste admitido para hacerlo. Los desarrolladores lo resuelven con un enlace simbólico desde ~/Library/Developer/CoreSimulator a una carpeta del volumen externo, pero después Xcode depende de que el disco siga montado, los simuladores arrancan más lento por USB y una actualización de Xcode puede recrear parte de la estructura en la ruta original. Eliminar dispositivos no disponibles y runtimes sin usar libera a menudo más espacio con menos riesgo.