Si el Simulador de Xcode esta 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 todavia necesitas para testing, porque la limpieza de simuladores se vuelve riesgosa cuando tratas cada carpeta del lado de Apple como cache desechable.
Ese es el error que cometen los desarrolladores despues 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 version del SO.
Respuesta rapida
- 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 seccion de no disponibles. - Usa
erasesolo cuando quieras reiniciar los contenidos y configuraciones de un dispositivo de simulador. - Elimina runtimes solo cuando estes seguro de que ya no necesitas esa version de plataforma para builds, previews o testing.
- Si el almacenamiento del lado de Apple es mas amplio que solo simuladores, revisa
DerivedData,ArchivesyCoreSimulatorjuntos en vez de adivinar desde una carpeta.
Que almacenan los simuladores de Xcode y por que se acumula
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:
- imagenes 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 facil ver el tamano de la carpeta y asumir que todo es solo cache. En la practica, parte es mas como estado de prueba desechable y parte es soporte de runtime del que todavia dependes.
El patron 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 despues de cambios de SDK o actualizaciones de Xcode;
- nada se revisa durante meses porque la maquina todavia tiene suficiente espacio libre.
Luego un dia el almacenamiento de simuladores es la historia principal, no solo un detalle.
Runtimes de simuladores vs datos de simuladores: Cual es la diferencia?
Esta es la distincion que mas 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 | Accion de limpieza tipica | Tradeoff principal |
|---|---|---|---|
| Runtimes de simuladores | Las imagenes de runtime del SO usadas para arrancar versiones de plataforma especificas | 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 especificos | 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 debil. Colapsan diferentes consecuencias de limpieza en una accion emocional.
Donde encaja DerivedData
DerivedData es adyacente, pero no es el mismo problema.
DerivedData es generalmente output de build generado. El almacenamiento de simuladores es mas mixto. Puede incluir runtimes que todavia necesitas, dispositivos creados que ya no necesitas y estado dentro de dispositivos que puede o no importarte.
Si la presion es mayormente output de build generado, la guia correcta es DerivedData de Xcode ocupando demasiado espacio en Mac? Que limpiar primero. Si la presion es mayormente imagenes de runtime y estado de simuladores, mantente en el flujo de simuladores.
Como verificar cuanto espacio estan usando los simuladores
El primer movimiento es inspeccion, no eliminacion.
Usa el propio tooling de Apple para ver que 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, tambien 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 mas grande del lado de Apple no siempre es la que asumiste. A veces DerivedData es el problema dominante. A veces CoreSimulator la supera silenciosamente.
Que buscar primero
- dispositivos listados bajo
Unavailable; - runtimes para versiones de SO que ya no testeas;
- muchos dispositivos creados a traves de varias generaciones de runtime;
- estado pesado de simuladores en una maquina que no se ha limpiado desde multiples 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.
Es seguro eliminar runtimes de simuladores en Mac?
A veces, pero este no es el primer movimiento mas seguro.
La ayuda de simctl runtime de Apple deja claro que las imagenes de runtime son sus propios objetos gestionados. Eliminar un runtime es diferente de limpiar los contenidos de un simulador. Tambien es diferente de eliminar un dispositivo no disponible.
Eso significa que la eliminacion de runtime es mejor cuando:
- ya no necesitas esa version de iOS para testing;
- has pasado a una generacion de Xcode o SDK mas antigua;
- el runtime esta suficientemente sin uso como para que el espacio valga mas que la conveniencia;
- has revisado la lista de runtimes primero y sabes exactamente que estas eliminando.
Es una peor idea cuando:
- un proyecto activo todavia apunta a esa familia de runtime;
- previews de SwiftUI, pasos de repro de QA o testing de regresion todavia dependen de ella;
- estas a punto de hacer demo o debugear un issue en un target antiguo;
- estas eliminando basandote solo en el tamano en vez de en las necesidades reales de testing.
Mejor primer movimiento: elimina el peso muerto obvio
La limpieza de simuladores mas segura suele empezar con dispositivos no disponibles.
Apple documenta esto directamente en simctl delete: el alias unavailable elimina dispositivos que no estan soportados por el SDK actual de Xcode.
xcrun simctl delete unavailableEso no es una respuesta universal, pero es una de las primeras pasadas mas 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
Aqui 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 operacion de reinicio, no una operacion de eliminacion 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.
Que 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 que dispositivos y runtimes realmente todavia necesitas.
Esa distincion es toda la historia de limpieza de simuladores: borrar un dispositivo, eliminar un dispositivo y eliminar un runtime son tres decisiones diferentes.
Como 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 revision como este:
- Lista dispositivos y runtimes despues 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 version de SO completamente.
- Compara
CoreSimulator,DerivedDatayArchivesjuntos cuando el almacenamiento del lado de Apple empiece a subir.
Eso mantiene la decision 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 mas 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 caotica.
Por que 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 generica de archivos.
Si tu problema real es “simuladores mas DerivedData mas otro almacenamiento de desarrollador de Apple,” ese flujo mas amplio consciente del perfil es mucho mas util que perseguir una ruta de carpeta a la vez.
Conclusion
Si el Simulador de Xcode esta ocupando espacio en tu Mac, no trates CoreSimulator como un bucket de cache 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 version del SO.
Ese es el camino de limpieza mas seguro: separa las imagenes 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 eliminacion ciega de carpetas.
Preguntas frecuentes
Por que el Simulador de Xcode ocupa tanto espacio en disco en Mac?
El almacenamiento del simulador crece porque Xcode mantiene imagenes 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 rapidamente.
Cual es la diferencia entre runtimes de simuladores y datos de simuladores?
Los runtimes de simuladores son las imagenes de runtime del SO que Xcode usa para arrancar simuladores para versiones especificas 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 explicitamente la eliminacion 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 mas 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 decision mas 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 detras de el.