- El problema. Nuestra función de detección marcó como abandonados 16,9 GB de imágenes del simulador de iOS. macOS no deja que nadie las borre, y la propia herramienta de Apple, al intentarlo, dejó atrás 34 GB de copias fallidas.
- Lo que descubrimos. No estaban abandonadas. Son la base de dos simuladores instalados de los que el registro había perdido la pista, y borrar esos runtimes devuelve 21 MB. Solo el panel Components de Xcode puede eliminarlas.
- Lo que construimos. Mint repara el registro antes de eliminar nada como huérfano y muestra estas imágenes en Keep, con una nota que remite a Xcode. Ya no intenta la vía que dejaba atrás copias de 8 GB.
Publicamos una función de detección que encontró 16,9 GB de runtimes abandonados del simulador de iOS en el Mac de un desarrollador. Incluso indicaba de qué compilaciones se trataba.
Resultó que esos archivos eran las imágenes base de dos simuladores que seguían instalados. La función de detección se había equivocado.
En este artículo contamos cómo una herramienta de disco llega a una conclusión así. Cada paso del camino esconde una trampa, y tres de ellas todavía hoy le cuestan espacio en disco a la gente. Todas las cifras que aparecen a continuación se midieron en un solo Mac entre el 19 y el 21 de agosto de 2026, y puedes reproducirlas todas.
La basura que macOS no te deja borrar
Cada vez que Xcode descarga un simulador de iOS, la imagen del sistema acaba en el almacén de recursos de Apple, en /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/<hash>.asset, y ocupa unos 8 o 9 GB. CoreSimulator, el servicio que ejecuta los simuladores, lleva un registro de los que conoce. xcrun simctl runtime list lo muestra.
Aquella mañana el registro mostraba un runtime (iOS 26.5), pero la carpeta contenía tres. Los otros dos eran iOS 18.2 e iOS 18.4, de 8,4 y 8,5 GB, descargados a principios de 2025.
Dos imágenes grandes y nada en el registro que apuntara a ellas. Así suele verse un archivo huérfano, y eso fue lo que concluyó nuestro escáner.
La primera sorpresa es que, de todos modos, no se pueden borrar:
$ ls -lO /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/
drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Feb 4 2025 3ee34d77….asset
drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Apr 8 2025 6fb1e5fe….asset
restricted es un indicador de la Protección de la integridad del sistema (SIP). Nadie puede tocar la carpeta, ni siquiera con sudo rm. El consejo habitual en internet es «desactiva SIP, reinicia, borra y vuelve a activar SIP», y eso no es algo que vayamos a ofrecerle a nadie.
Lo que sí puede eliminarlas es el propio servicio de runtimes de Apple. Le pides que vuelva a incorporar la imagen a su registro con simctl runtime add <image> --move y luego la borras por su UUID. El daemon hace la eliminación con sus propios permisos, así que no pide ninguna contraseña.
La negativa que te cuesta 8 GB
Se negó a incorporar la imagen:
$ xcrun simctl runtime add …/092-10337-196.dmg --move
SimDiskImageError code=14: Cannot copy the image because the disk is almost full
Había 24,7 GB libres y la imagen ocupa 8,4 GB. Los mensajes del daemon en el log aparecen ocultos, así que miramos dentro del binario:
$ strings …/CoreSimulator.framework/…/simdiskimaged
minFreeSpace = %llu
Because source is on the same volume as inbox and clones are supported
will allow a lower free space limit
Si el servicio puede hacer un clon APFS del origen (copia en escritura, instantáneo, sin ocupar ni un byte más), apenas necesita espacio libre. Si no puede, recurre a una copia completa byte a byte y exige el tamaño de la imagen más una reserva considerable.
Y desde el almacén de recursos protegido por SIP no puede clonar. Así que, antes de que la propia herramienta de Apple te ayude con la carpeta que no tienes permiso para borrar, tiene que hacer una copia completa de ella.
También lo comprobamos desde el otro lado. Un archivo normal de 9 GB en /tmp supera la misma comprobación previa con solo 14,6 GB libres. Mismo volumen, tamaño parecido, sin el indicador de SIP, y el daemon no protesta.
Peor aún: un runtime add rechazado no deja las cosas como estaban. Para cuando el daemon decide que el disco está demasiado lleno, ya ha copiado la imagen en su propio almacén y la ha registrado como runtime Unusable, y deja ambas cosas ahí. Tres rechazos dejaron tres copias de 8,38 GB en /Library/Developer/CoreSimulator/Cryptex/Images/, más una copia de 9 GB en su Inbox.
Son 34 GB de restos de operaciones que, sin excepción, informaron de un fallo. Ninguna herramienta los muestra. du sobre tu carpeta de inicio nunca los ve, y el runtime al que pertenecen no aparece en la salida normal de simctl runtime list.
La basura que no era basura
Llegados a este punto, nuestra conclusión era que nadie podía borrar esos 16,9 GB y que la vía de la reincorporación empeoraba las cosas cada vez que fallaba. Un solo comando demostró que nos equivocábamos.
xcrun simctl runtime scan-and-mount es el comando de reparación de la propia Apple. Le pide a CoreSimulator que recorra su almacenamiento y vuelva a incorporar todo aquello de lo que haya perdido la pista, y tarda alrededor de una décima de segundo. Después de ejecutarlo, el registro quedó así:
$ xcrun simctl runtime list
iOS 18.2 (22C150) - 87410283-… (Ready)
iOS 26.5 (23F77) - 8E56E104-… (Ready)
iOS 18.4 (22E238) - 10B15C7F-… (Ready)
Total Disk Images: 3 (24.2G)
El registro pasó de uno a tres runtimes. Además, la entrada JSON completa de iOS 18.4 tenía un campo que el listado resumido nunca muestra:
parentImagePath = /System/Library/AssetsV2/…/6fb1e5fe….asset/AssetData/090-44150-318.dmg
El recurso «huérfano» era la imagen padre de un runtime instalado y en funcionamiento. CoreSimulator había dejado de tener registrados los dos paquetes Cryptex que contenían iOS 18.2 y 18.4, y mientras faltaba ese registro, nada en el equipo reclamaba esos recursos. Los archivos no habían cambiado. Era el registro el que había perdido su rastro.
A partir de ahí, la limpieza fue fácil. Ejecutar simctl runtime delete <UUID> sobre los tres restos Unusable eliminó los 34 GB de copias provisionales. No hizo falta contraseña ni espacio para copias provisionales, y también vació el Inbox. Los dos runtimes 18.x aparecen ahora correctamente en nuestro análisis: uno sin usar y otro sustituido por una compilación más reciente, y los dos se pueden borrar por su UUID.
Y volvimos a equivocarnos
Borrarlos no libera casi nada. Hicimos el borrado desde Mint y lo medimos: eliminar el runtime de iOS 18.2 devolvió 21 MB, muy lejos de los 8,4 GB. La entrada del registro desapareció y el paquete se desmontó, pero el .asset de 8,4 GB se quedó exactamente donde estaba. simctl runtime delete nunca elimina el MobileAsset desde el que se instaló. Apple incluso ofrece la opción --keep-asset, lo que da a entender que por defecto sí lo elimina, y en un runtime basado en Cryptex esa opción no cambia nada.
Eso dejaba una sola forma de recuperar el espacio, o eso concluimos: runtime add --move, que saca la imagen del almacén protegido. Esa vía no puede clonar, así que exige espacio libre para la imagen más alrededor de una décima parte del volumen. En un disco de 494 GB con 16,9 GB de simuladores muertos, eso supone unos 58 GB que tienes que liberar antes.
Actualización, una semana después, tras liberar esos 58 GB y probarlo: esa vía tampoco funciona. El daemon incorpora su copia y luego muestra «--move was specified but unable to remove original file: Operation not permitted». El propio servicio de Apple, con sus permisos especiales, no puede eliminar un archivo del almacén de recursos sellado, como tampoco puedes tú. Además, cada intento deja una copia provisional de 8 GB en Images/Inbox de CoreSimulator, y nada de lo que probamos consiguió eliminarla: ni simctl ni rm ejecutado como root con la contraseña de administrador. Ningún programa puede recuperar los bytes de un runtime que vive en el almacén de recursos de Apple. El único sitio que todavía puede hacerlo es Xcode, en Settings ▸ Components, donde un runtime registrado tiene un botón para eliminarlo.
Visto en retrospectiva, las cuentas del espacio libre siempre fueron correctas. Primero nos equivocamos al clasificar las imágenes y luego al elegir la vía.
Al medir aparecieron dos problemas más. Si borrabas un runtime y volvías a analizar, reaparecía: nuestro propio paso de reparación volvía a registrar el recurso que quedaba y deshacía el borrado. Y un borrado que había funcionado se notificaba como fallo, porque CoreSimulator aún no había actualizado su registro cuando lo comprobábamos. Los dos están corregidos. Solo los encontramos cuando empezamos a medir el sistema de archivos en lugar de fiarnos del registro.
Una rareza más de Apple, por si estás escribiendo tu propia herramienta de limpieza: simctl runtime delete --notUsedSinceDays 90 no encontró nada aquí, aunque los dos runtimes 18.x tienen lastUsedAt con valor null. El filtro de Apple para «borrar lo que no has usado» se salta los runtimes que no se han usado nunca.
Una carpeta, dos nombres
Mientras construíamos el gráfico que muestra adónde va el espacio en disco, una comprobación interna empezó a saltar. Las subcategorías de Developer sumaban 18,1 GB más que la propia categoría. Eso no debería ser posible, porque cada subcategoría se mide desde dentro de la categoría que la contiene. La comprobación saltó 502 veces, y el exceso era siempre de 18,1 GB exactos.
La causa era un firmlink. Desde Catalina, macOS guarda el sistema en un volumen sellado de solo lectura y tus datos en otro, y luego los une para que el sistema de archivos parezca un único árbol. Algunas rutas acaban teniendo dos formas de escribirse que apuntan al mismo directorio:
$ stat -f '%d %i %N' /System/Library/AssetsV2 /System/Volumes/Data/System/Library/AssetsV2
16777233 210916113 /System/Library/AssetsV2
16777233 210916113 /System/Volumes/Data/System/Library/AssetsV2
Las dos líneas muestran el mismo dispositivo y el mismo inodo con dos nombres. Nuestra pasada por todo el disco anotó la carpeta de simuladores con una de esas formas y el escáner informó de los runtimes con la otra. Una comparación de cadenas los trató como lugares distintos, así que se sumaron 18,1 GB a una categoría que ya los incluía.
Todas las herramientas de disco cruzan sus mediciones por ruta, y cualquiera que lo haga tendrá este error a menos que compare a través de la tabla de firmlinks. El problema de fondo es anterior a APFS. Dos rutas distintas pueden ser el mismo archivo, así que compara dispositivo e inodo, no cadenas.
Los 46,7 GB que nunca estuvieron ahí
Ejecuta du sobre los restos de las actualizaciones de Chrome y te dirá que hay 46,7 GB repartidos en 34 directorios llamados *.code_sign_clone. Bórralos todos y tu espacio libre no cambia lo más mínimo.
Son clones APFS. Durante la firma de código, Chrome crea una instantánea de su propio paquete con copia en escritura, y el clon comparte todos los bloques con el original hasta que uno de los dos se modifica, cosa que nunca ocurre. du informa del tamaño lógico, así que cuenta 34 veces una aplicación de 1,4 GB.
Un limpiador que ordena por du los pone al principio de la lista y te deja «liberar» 46,7 GB, y después tu espacio libre marca lo mismo que antes. Nosotros medimos los bloques asignados y dejamos los directorios clonados fuera de la vista general. Preferimos no mencionarlos antes que prometer 46,7 GB y no liberar nada.
El borrado que llegó un segundo tarde
La última es pequeña. Nos la encontramos el mismo día en que escribimos esto.
En aquel momento, nuestro comprobante tras una limpieza mostraba la variación del espacio libre observada en el volumen, medida justo después de que desapareciera el último archivo, en lugar del tamaño de lo eliminado. El espacio libre es la única cifra que un usuario puede contrastar con el Finder, por eso lo hacíamos así, y llevaba meses funcionando.
Entonces alguien borró dos carpetas de 9 GB y el comprobante decía que se habían liberado 0 bytes. Los archivos ya no estaban y la entrada del historial registraba 17,5 GB eliminados de forma permanente, pero el espacio libre del volumen, leído 375 milisegundos después, no se había movido.
APFS recupera los bloques de un árbol grande de forma asíncrona. Unos cientos de megabytes vuelven casi al instante; decenas de gigabytes tardan segundos, y una medición tomada en ese intervalo no ve nada. La cifra principal, en la parte superior de la ventana, leía el valor una sola vez, así que tampoco se movió. Para el usuario, eso es exactamente igual que un borrado que ha fallado.
La solución es aburrida. Ahora Mint da tiempo al volumen para que se estabilice antes de dar una cifra, y vuelve a leer la cifra principal después de cualquier acción que libere espacio, sea cual sea el botón que la inició.
Lo que cambiamos
Mantuvimos la función de detección, pero ya no puede marcar nada basándose en un registro que no haya verificado. Antes de considerar huérfano cualquier almacenamiento de simuladores, Mint le pide a CoreSimulator que vuelva a incorporar su propio almacenamiento y después lee otra vez el registro. En nuestra medición, así se identifican correctamente las dos imágenes «huérfanas» como imágenes base de dos runtimes instalados. Mint las muestra en Keep, con una nota que remite al panel Components de Xcode, el único sitio que puede eliminarlas. Un botón en Mint habría liberado 21 MB y habría informado del resto como «no se eliminó nada».
Actualización, octubre de 2026: un análisis normal ya no le pide a CoreSimulator que vuelva a incorporar su almacenamiento. Solo lee el registro. Esa reparación se ejecuta ahora únicamente cuando eliminas almacenamiento de simuladores desde Mint.
Mint ya no intenta la vía de runtime add --move, así que no puede dejar atrás 8 GB de copias provisionales. Las copias que CoreSimulator ya muestra como Unusable se borran por su UUID, y con una copia provisional que haya quedado en el Inbox se hace un único intento con la contraseña de administrador. Si la eliminación se rechaza incluso con esa contraseña, Mint lo recuerda y deja de ofrecer esa fila hasta que cambie el archivo o el sistema operativo.
Ninguna de estas trampas es un error de macOS. Los volúmenes de sistema sellados, los firmlinks, los clones con copia en escritura, la recuperación diferida del espacio y un registro de runtimes que se repara solo tienen sentido como ingeniería, y nunca los notas cuando simplemente usas tu Mac. Dan problemas a un programa que dice saber adónde ha ido tu espacio, porque cada uno abre una brecha entre lo que ocupa una carpeta y el espacio que devuelve borrarla.
La forma barata de hacer un limpiador de disco es recorrer el árbol, ordenar por tamaño y poner casillas junto a lo más grande. Con cada una de las trampas anteriores, ese enfoque muestra una cifra mayor que la que el usuario va a recuperar, y solo lo descubre después de hacer clic.
Nuestro error más caro no tuvo nada que ver con medir: nos fiamos del registro cuando decía que nada hacía referencia a esas imágenes, y nunca comprobamos si había terminado de contar.
Tomamos todas las mediciones con el análisis de solo lectura de Mint en el Mac de un desarrollador en agosto de 2026, y puedes reproducirlas en tu Mac. Sobre lo que dejan atrás los agentes de programación, lee Tu agente de programación se está comiendo tu disco.
Aplícalo a tu Mac
Para los pasos que funcionan hoy, lee la guía sobre el espacio que ocupa el simulador de iOS. Distingue entre runtimes, datos de dispositivos y cachés. Si tu carpeta grande es DerivedData, lee en su lugar la guía sobre los archivos de compilación de Xcode: son otros datos, y eliminarlos tiene otras consecuencias.