Cómo liberar decenas de GB en un Mac sin borrar tus archivos personales

Cuando un Mac empieza a quedarse sin espacio, borrar Descargas, vaciar la papelera o eliminar unas cuantas aplicaciones puede servir de poco. En equipos utilizados para desarrollo el verdadero consumo puede estar escondido en instantáneas APFS, copias antiguas de iPhone, imágenes de Docker, simuladores de Xcode, DerivedData, cachés de Homebrew o proyectos abandonados con varios node_modules. Antes de recurrir a una aplicación de limpieza, macOS y las propias herramientas de desarrollo permiten localizar buena parte de ese almacenamiento.

Las claves para liberar espacio en un Mac en 30 segundos

• macOS agrupa bajo Datos del sistema archivos muy diferentes, por lo que esa cifra no identifica por sí sola qué está ocupando el SSD.
• Time Machine administra automáticamente sus instantáneas locales y Apple considera su espacio como disponible.
• Docker, Xcode y sus simuladores pueden acumular decenas de gigabytes en un Mac de desarrollo.
• Conviene medir primero y borrar después: varios comandos populares de Internet pueden eliminar copias de seguridad o volúmenes necesarios.
• Homebrew, Docker y Xcode incorporan sus propios mecanismos para recuperar espacio de forma controlada.

La primera diferencia respecto a muchas guías de limpieza es precisamente esa: no conviene empezar ejecutando varios rm -rf encontrados en Internet. Es mejor averiguar primero dónde están los gigabytes y decidir después qué puede desaparecer.

Apple explica que la categoría Datos del sistema es genérica: incluye archivos de Apple y de terceros que no encajan en categorías más concretas. Por eso dos Mac que muestran 100 GB de Datos del sistema pueden tener problemas completamente diferentes.

Antes de borrar nada: descubrir dónde está el espacio

El punto de partida está en Ajustes del Sistema > General > Almacenamiento. Desde ahí macOS permite revisar aplicaciones, documentos y otras categorías.

En Terminal también puede comprobarse cuánto espacio queda realmente:

df -h /

Para buscar directorios grandes dentro de la carpeta personal:

du -sh ~/* 2>/dev/null | sort -hr | head -20

Hay una limitación importante: el comando anterior no incluye directorios ocultos. Y precisamente muchos datos de desarrollo viven en ~/Library.

Por eso merece la pena revisar también:

du -sh ~/Library/* 2>/dev/null | sort -hr | head -20

En un Mac utilizado para programar suelen aparecer rápidamente sospechosos como Developer, Caches, Application Support o Containers.

A partir de ahí puede repetirse du dentro del directorio problemático hasta localizar el origen.

1. Time Machine: las instantáneas pueden engañar al medir el espacio

Uno de los consejos más repetidos consiste en borrar agresivamente las instantáneas locales de Time Machine. En los macOS actuales conviene matizarlo.

Time Machine crea aproximadamente una instantánea local cada hora y conserva las horarias durante unas 24 horas. También puede mantener la correspondiente a la última copia correcta hasta que necesite ese espacio y macOS crea una instantánea adicional antes de determinadas actualizaciones.

Se pueden consultar desde Terminal:

tmutil listlocalsnapshots /

Pero que existan no significa necesariamente que estén provocando una falta real de almacenamiento. Apple contabiliza el espacio utilizado por las instantáneas locales como almacenamiento disponible y Time Machine las elimina automáticamente cuando necesita espacio.

También existe una opción gráfica que muchas guías pasan por alto. Utilidad de Discos permite seleccionar Visualización > Mostrar instantáneas APFS, consultar su tamaño y eliminar instantáneas concretas.

Por tanto, borrarlas compulsivamente como mantenimiento periódico tiene poco sentido. Resulta más razonable inspeccionarlas cuando se está investigando un problema concreto de almacenamiento.

2. Las copias locales del iPhone pueden ocupar mucho más de lo esperado

Un culpable mucho más tangible son las copias antiguas de iPhone y iPad.

Apple confirma que macOS almacena estas copias en:

~/Library/Application Support/MobileSync/Backup/

Puede comprobarse cuánto ocupan:

du -sh ~/Library/Application\ Support/MobileSync/Backup/

Aunque técnicamente sería posible eliminar el contenido mediante rm -rf, no es la mejor primera opción. Finder permite identificar las copias y administrarlas antes de borrarlas, reduciendo el riesgo de eliminar precisamente el backup que se quería conservar.

Un Mac que haya pasado por varios iPhone durante años puede mantener copias de dispositivos que ya ni siquiera se utilizan.

3. Docker: uno de los grandes consumidores en un Mac de desarrollo

Para desarrolladores, Docker merece una revisión propia.

Antes de borrar nada:

docker system df -v

El comando muestra cuánto espacio utilizan imágenes, contenedores, volúmenes y caché de construcción.

Una limpieza conservadora puede comenzar con:

docker system prune

Docker indica que elimina contenedores detenidos, redes no utilizadas, imágenes colgantes y caché de construcción.

Existe una versión mucho más agresiva:

docker system prune -a --volumes

Pero no debería presentarse como un comando de mantenimiento rutinario. -a amplía la eliminación a imágenes no utilizadas y --volumes incorpora volúmenes que Docker considere susceptibles de limpieza. Un volumen puede contener una base de datos local o información de desarrollo que el usuario sí quiera conservar.

Conviene empezar por:

docker system df -v

y limpiar después únicamente aquello que se entienda.

Docker Desktop añade otro detalle importante en macOS. Los contenedores e imágenes se almacenan dentro de una imagen de disco de la máquina virtual Linux. En Settings > Resources > Advanced puede verse su ubicación, tamaño máximo y consumo real. Docker permite incluso trasladar esa imagen a otra unidad, pero recomienda hacerlo desde Docker Desktop y no moviendo manualmente el archivo desde Finder.

4. Xcode DerivedData: gigabytes que pueden volver a generarse

Otro clásico:

~/Library/Developer/Xcode/DerivedData/

Aquí Xcode mantiene datos derivados de compilaciones y proyectos.

Puede comprobarse su tamaño:

du -sh ~/Library/Developer/Xcode/DerivedData

Si realmente se necesita recuperar ese espacio, puede limpiarse el contenido:

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

La contrapartida es que Xcode tendrá que regenerar posteriormente parte de esa información, así que las siguientes compilaciones pueden tardar más.

Pero en 2026 hay otro candidato que merece incluso más atención.

5. Los runtimes de Simulator pueden ocupar varios gigabytes cada uno

Quien desarrolla para iPhone, iPad, Apple Watch, Apple TV, Vision Pro u otras plataformas puede terminar acumulando versiones antiguas de los simuladores.

La opción más segura está en:

Xcode > Settings > Components

Las versiones actuales de Xcode muestran los componentes instalados y cuánto almacenamiento puede recuperarse al eliminarlos. Desde allí pueden borrarse runtimes de Simulator que ya no sean necesarios.

Es una mejora importante respecto a entrar manualmente en ~/Library/Developer y borrar directorios sin conocer sus dependencias.

Apple también permite gestionar dispositivos simulados desde Window > Devices and Simulators.

Para un desarrollador que prueba varias generaciones de iOS, esta revisión puede resultar mucho más productiva que borrar las cachés generales de macOS.

6. node_modules: el almacenamiento repartido entre decenas de proyectos

JavaScript y TypeScript presentan un problema diferente. No suele existir un único directorio gigantesco, sino muchos proyectos que contienen su propio node_modules.

Para encontrarlos:

find ~ -type d -name node_modules -prune 2>/dev/null

También puede utilizarse npkill, una herramienta diseñada específicamente para localizar estos directorios y eliminarlos de manera interactiva:

npx npkill

La ventaja del enfoque interactivo es que permite revisar cada proyecto antes de eliminar nada. Si se conserva package.json y el correspondiente archivo de bloqueo (package-lock.json, pnpm-lock.yaml o yarn.lock), las dependencias normalmente pueden instalarse de nuevo.

7. Homebrew tiene su propia limpieza y permite simularla primero

Homebrew acumula versiones y descargas que dejan de ser necesarias.

Antes de hacer cambios puede comprobarse qué eliminaría:

brew cleanup --dry-run

Y después ejecutar:

brew cleanup

La documentación actual de Homebrew indica que cleanup elimina versiones antiguas instaladas, bloqueos obsoletos y descargas antiguas. Además elimina por defecto descargas con más de 120 días, un comportamiento configurable.

Para una limpieza más agresiva existe:

brew cleanup --prune=all

No siempre es necesario. El modo --dry-run resulta especialmente recomendable para saber primero cuánto se puede recuperar.

8. Las cachés: mejor no borrar ~/Library/Caches a ciegas

Aquí merece la pena corregir otro consejo habitual:

rm -rf ~/Library/Caches/*

Aunque muchas aplicaciones pueden reconstruir sus cachés, borrar indiscriminadamente toda la carpeta no debería ser el primer paso.

Es preferible localizar cuáles ocupan realmente espacio:

du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -20

Puede ocurrir que dos aplicaciones concentren prácticamente todo el almacenamiento recuperable. En ese caso tiene más sentido cerrar esas aplicaciones y limpiar sus cachés concretas que eliminar las de todo el sistema.

La misma filosofía sirve para logs:

du -sh ~/Library/Logs/* 2>/dev/null | sort -hr | head -20

Una limpieza segura empieza midiendo, no borrando

En un Mac convencional, Fotos, vídeos y aplicaciones probablemente continúen siendo los grandes consumidores de almacenamiento. En una máquina utilizada durante años para desarrollo la situación puede cambiar por completo.

Un antiguo runtime de iOS, varias imágenes de contenedores, una base de datos guardada en un volumen Docker, tres copias locales de iPhone, DerivedData y veinte proyectos JavaScript abandonados pueden sumar decenas o incluso cientos de gigabytes sin que exista un único archivo evidente que borrar.

Por eso una rutina más segura podría comenzar con estos comandos:

df -h /

du -sh ~/* 2>/dev/null | sort -hr | head -20

du -sh ~/Library/* 2>/dev/null | sort -hr | head -20

docker system df -v

du -sh ~/Library/Developer/* 2>/dev/null | sort -hr

du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -20

brew cleanup --dry-run

Después llega la decisión humana.

Un caché regenerable no tiene el mismo valor que una copia de seguridad de un iPhone. Un runtime antiguo de Simulator no es lo mismo que un volumen Docker que contiene PostgreSQL. Y una instantánea APFS que macOS puede purgar automáticamente no debería tratarse como un archivo inútil simplemente porque una herramienta de análisis le atribuya varios gigabytes.

Ese es probablemente el mejor cambio respecto a las típicas guías de “recupera 100 GB en cinco minutos”: el objetivo no debería ser borrar todo lo que sea técnicamente eliminable, sino identificar qué está consumiendo el SSD y utilizar primero los mecanismos de limpieza de la herramienta que creó esos datos.

Preguntas frecuentes

¿Qué son los Datos del sistema de macOS?

Es una categoría genérica utilizada por macOS para archivos de Apple y de terceros que no pertenecen a categorías más específicas. Por eso puede incluir tipos de datos muy diferentes y no existe una única carpeta llamada “Datos del sistema”.

¿Es seguro borrar las instantáneas locales de Time Machine?

Time Machine las administra automáticamente y Apple contabiliza el espacio que ocupan como disponible. Pueden inspeccionarse y eliminarse, pero normalmente no es necesario hacerlo como mantenimiento habitual.

¿Es seguro ejecutar docker system prune -a --volumes?

Es un comando agresivo y conviene revisar antes docker system df -v. Especialmente importante es comprobar los volúmenes, ya que pueden contener datos persistentes de bases de datos y otras aplicaciones.

¿Qué suele ocupar más espacio en un Mac utilizado para programar?

Depende del entorno, pero Docker, runtimes de Simulator, Xcode DerivedData, dependencias de proyectos y cachés de gestores de paquetes son buenos candidatos para revisar. Xcode y Docker ofrecen además herramientas propias para medir y gestionar parte de ese almacenamiento.