# Eliminar restos tras desinstalar apps en Mac
> Atribuye residuos de Library por identidad del bundle, protege datos compartidos del proveedor y revisa restos tras la Papelera o una instalación ya desaparecida.
Published: 2026-07-29 | Updated: 2026-09-25
Apunta dos escáneres de residuos a la misma app desinstalada y obtendrás dos listas.
Eso no es un bug. Cada herramienta elige su propia regla de pertenencia, su propia lista
de exclusiones y su propio límite de trabajo de administrador. Esas tres decisiones
determinan todo lo que ves en pantalla. Cuando entiendes la atribución, limpiar residuos
deja de ser una carrera por encontrar más basura: importa qué herramienta reduce mejor el riesgo de equivocarse.
Esta guía trata del estado posterior: la app ya no está, o acaba de caer en la
Papelera, y quieres revisar el residuo con el mismo cuidado que debería haber tenido un
desinstalador. Para la secuencia completa mientras la app aún está en ejecución, consulta
[desinstalación completa](https://mole.fit/es/blog/how-to-completely-uninstall-apps-on-mac). Para opciones de
producto, consulta [más allá de AppCleaner](https://mole.fit/es/blog/appcleaner-alternative).
Arrastrar una app a la Papelera solo elimina el bundle; sus datos
siguen en `~/Library` en Application Support, Caches, Preferences y Containers. Atribuye
los residuos por identificador de bundle, nunca por tamaño o nombre, y revisa cada
candidato antes de borrar, o usa un desinstalador que haga exactamente eso.
## Qué significa en realidad "desinstalar" en macOS
macOS no trata una aplicación como un solo objeto con un solo botón de borrar. Hay al
menos tres capas:
| Capa | Ubicación típica | Quién debería eliminarla |
|---|---|---|
| App bundle | `/Applications`, `~/Applications`, Setapp, etc. | Tú, Papelera o gestor de paquetes |
| Soporte de usuario | `~/Library/…` | Escáner de residuos o revisión manual cuidadosa |
| Sistema / privilegiado | `/Library`, helpers, receipts, extensions | **Desinstalador del proveedor** primero |
Arrastrar a la Papelera solo garantiza la primera capa. La capa media es donde ayudan las
herramientas genéricas. La tercera es donde a menudo fingen y fallan: drivers, extensiones
de red, helpers privilegiados, daemons de licencias. Apple sigue recomendando preferir la
app Uninstall del proveedor por esa razón
([guía de Apple para desinstalar apps](https://support.apple.com/102610)).
Eliminar el bundle de la app es solo la capa superior. El residuo de Library del usuario y los helpers del sistema son decisiones separadas con distinto riesgo.
## Dónde viven realmente los residuos de usuario
La mayor parte del residuo de terceros se concentra en la Library del home:
| Área | Qué suele ser |
|---|---|
| `Application Support/` | Bases de datos, paquetes offline, estado de proyectos |
| `Caches/` | Caché regenerable |
| `Containers/` y `Group Containers/` | Homes en sandbox y grupos compartidos |
| `Preferences/` (+ ByHost) | Plists de ajustes |
| `Logs/`, DiagnosticReports | Diagnósticos |
| `Saved Application State/` | Restauración de ventanas |
| `HTTPStorages/`, WebKit, cookies | Estado de red de esa identidad |
| `LaunchAgents/` | Helpers de inicio de sesión con un plist |
| `Application Scripts/` | Paquetes de scripts del sandbox |
Las rutas de sistema bajo `/Library` (LaunchDaemons, PrivilegedHelperTools, receipts bajo
`/private/var/db/receipts`) son un nivel de mayor riesgo. Prefiere el removedor del
proveedor; trata ahí a los escáneres genéricos como solo-revisión.
Una app en sandbox a menudo parece ordenada: contenedor principal en
`~/Library/Containers/`. Aun así puede usar App Groups, Application Scripts,
cachés compartidas, CloudKit o ítems de Keychain. El sandbox limita el acceso directo a
archivos; no garantiza un rastro de un solo directorio. Una app sin sandbox puede
dispersarse por Application Support, Caches, Preferences, Logs, Saved Application State,
WebKit y Cookies. Más dispersión significa más espacio para que dos herramientas no
coincidan.
## La atribución es toda la habilidad
El descubrimiento seguro de residuos se basa en la **identidad**, no en nombres de
marketing.
### Identificador de bundle frente a nombre visible
`com.example.widget` es estable ante renombres y localizaciones. Los nombres visibles no.
Dos productos pueden compartir una carpeta de empresa (`…/Application Support/Google`)
mientras solo uno está desinstalado. Emparejar "Google" como cadena es cómo los escáneres
inventan falsos positivos de varios gigabytes.
La **coincidencia por identificador** es precisa y casi nunca propone datos de una app
hermana. Se pierde carpetas que la app nombró con su propio nombre.
La **coincidencia por nombre** encuentra esas carpetas, y también cosas que solo
comparten una palabra. Encuentra más y se equivoca más a menudo.
La coincidencia por identidad es más estrecha y más segura. La coincidencia por nombre encuentra más residuos y se equivoca más a menudo cuando dos productos comparten una carpeta de proveedor.
Comprobaciones prácticas antes de cualquier borrado:
```
mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null
```
Si algo con ese id aún existe, trata las rutas de soporte compartidas como **vivas**.
### Helpers e identidades embebidas
Las apps modernas traen helpers con ids relacionados: `com.example.widget.helper`, nombres
declarados en `SMPrivilegedExecutables`, login items bajo `Contents/Library/LoginItems`.
Un escáner exhaustivo recolecta esos ids del bundle **antes** de que la app desaparezca.
Cuando el bundle ya no está, solo tienes lo que se registró o lo que sigue en disco bajo
nombres exactos.
### Contenedores de grupo
`~/Library/Group Containers/` guarda datos compartidos de suite a propósito:
- `group.`
- nombres con alcance de equipo como `.`
- espacios compartidos `group.*` usados por varias apps
Solo las rutas con propietario exacto son candidatas a asociación automática. Los árboles
de grupo compartidos deben quedarse en solo-revisión o sin tocar cuando queda algún
hermano. Esta es la categoría donde las herramientas de "más encontrado" causan daño real.
### Variantes de nombre y builds de canal
`Foo Beta` puede dejar `Foo Beta`, `FooBeta` y a veces una carpeta estable `Foo` que
pertenece al canal de release aún instalado. Los nombres base sin el canal son alto
riesgo de falso positivo: déjalos en solo-revisión salvo que demuestres que la app estable
ya no está.
La atribución debe seguir la identidad del bundle hacia rutas propias, no carpetas de todo el proveedor que otras apps aún necesitan.
## Tres puntos de entrada seguros
### 1. Desinstaladores del proveedor primero
Agentes de seguridad, clientes VPN, drivers de audio y herramientas de endpoint conocen
sus propios receipts y el orden de desmontaje de extensiones. Ejecútalos antes de
cualquier recorrido por Library. Borrar archivos no es un flujo fiable de desactivación
para extensiones de sistema o de red; macOS las registra.
### 2. Revisar cuando la app ya no está
Cuando el `.app` ya no está, busca rutas aún etiquetadas con ese bundle id o variantes
exactas de nombre. Valores predeterminados conservadores:
- **Suele estar bien si es propio:** cachés, logs, estado guardado, informes de crash
- **Revisa con cuidado:** Application Support, Containers, Preferences (licencias, correo
offline, bases de datos de proyectos)
- **Normalmente deja:** Group Containers sin propiedad exacta, Documents fuera de Library,
cualquier cosa que otro id aún necesite
Mide los candidatos:
```
du -sh ~/Library/Application\ Support/ \
~/Library/Caches/ \
~/Library/Containers/ 2>/dev/null
```
Los errores de permiso suelen significar que Terminal no tiene Full Disk Access, no que
la carpeta esté vacía.
### 3. El momento en que la app cae en la Papelera
Mucha gente tira primero y piensa después. Un watcher que detecta un `.app` nuevo en
`~/.Trash`, lee la identidad de su Info.plist, escanea archivos de soporte relacionados y
abre un **panel de revisión** atrapa el residuo sin una cacería de residuos. Restricciones
de diseño que separan lo útil de lo dañino:
- Nunca borrar automáticamente el bundle de la app en la Papelera (Put Back debe funcionar)
- Nunca saltar para clases protegidas / AV / MDM
- Consumir una supresión de un solo uso cuando **el propio limpiador** tiró la app durante
la desinstalación, o el panel compite con el flujo de desinstalación
- Condicionar a Full Disk Access; fallar en silencio sin él en lugar de pedir permiso desde
el fondo
El análisis de residuos de [Mole](https://mole.fit/es/mac-app-uninstaller) resta primero las rutas que aún reclaman apps instaladas, identificadores de bundle o recibos y deja sin marcar los candidatos ambiguos. Muestra identidad y tamaño y envía a la Papelera los borrados recuperables; ser grande dentro de Library nunca basta.
## Los huérfanos no son "cualquier cosa grande en Library"
Para encontrar restos de apps antiguas hay que **excluir primero las rutas que siguen en uso**.
Revisa las carpetas candidatas contra los identificadores de bundle, apps en ejecución,
registros de Launch Services y carpetas compartidas del proveedor. Si esa comprobación queda
incompleta por un tiempo de espera o un directorio ilegible, lo seguro es **no proponer restos**,
no adivinar. Desconfía de una lista que siempre encuentra docenas de apps "basura" sin explicar su origen.
La fecha de modificación también importa: una configuración cambiada la semana pasada
puede pertenecer a una herramienta CLI que no aparece en el inventario de apps.
Los archivos con mtimes recientes deben quedar fuera de los candidatos.
## Ejemplo práctico: dos herramientas, una suite de proveedor
Desinstalas el Producto A de una empresa que también publica el Producto B, aún instalado.
- Herramienta 1 (centrada en identificadores): lista pequeña, sobre todo rutas
`com.vendor.productA.*`.
- Herramienta 2 (centrada en nombres): añade `~/Library/Application Support/Vendor`
(4 GB) y un contenedor de grupo que usan ambos productos.
La herramienta 2 parece más exhaustiva. Está proponiendo el borrado que puede romper el
Producto B. El total al pie de la pantalla no es una puntuación de calidad. Las categorías
encima sí lo son.
## El receipt huérfano de Homebrew
Si la app vino de Homebrew Cask, quitar solo el `.app` puede dejar un registro en Caskroom
que bloquea la reinstalación. Tras los residuos de archivos:
```
brew list --cask
```
Si el token sigue ahí, `brew uninstall --cask ` limpia la asociación (acepta
`--zap` solo cuando quieres la limpieza más amplia de brew). "Cask is not installed"
indica que debes comprobar el token y la instalación de Homebrew que estás usando; no
demuestra una asociación obsoleta ni justifica usar `rm -rf` en rutas de Caskroom al azar.
## Qué rechazar aunque el nombre coincida
- Hermanos y gemelos de canal aún instalados
- Contenedores de grupo compartidos y carpetas padre de proveedor
- Receipts y helpers privilegiados sin un removedor validado
- Documentos de usuario fuera de Library
- Almacenes de chat de IA y directorios de modelos cerca de rutas de caché
([limpieza de IA](https://mole.fit/es/blog/how-to-remove-ai-tool-leftovers-mac))
## Errores comunes
**Maximizar la lista encontrada.** Más candidatos a menudo significa peor atribución.
**Borrar Group Containers por defecto.** Se comparten a propósito.
**Saltar el desinstalador del proveedor** en VPN, AV, audio, virtualización.
**Medir sin Full Disk Access** y concluir que "no queda nada".
**Vaciar la Papelera de inmediato** tras un borrado masivo de residuos. Mantén un día de
uso normal si algo importante pudo atribuirse mal.
## Verificar
1. Vuelve a medir las rutas eliminadas.
2. Confirma que no queda login item ni launch agent con ese id
([ítems de inicio](https://mole.fit/es/blog/how-to-disable-startup-programs-on-mac)).
3. Abre apps hermanas del mismo proveedor.
4. Vacía la Papelera solo cuando aceptes las eliminaciones.
## Orden de operaciones
1. Busca un desinstalador del proveedor si la app tenía drivers, extensiones o helpers.
2. Exporta o desautoriza mientras la app aún corre, si eso importa.
3. Cierra la app y los helpers visibles.
4. Elimina el bundle (o confirma que ya está en la Papelera).
5. Revisa residuos por identidad; deja en paz los contenedores compartidos.
6. Gestiona receipts de Homebrew cask si aplica.
7. Mantén los ítems en la Papelera mientras usas el Mac con normalidad, luego vacía.
## El primer día después de desinstalar
Mucha gente vacía la Papelera en el instante en que la app desaparece. Un ritmo más lento
no cuesta nada y deja un camino de vuelta:
1. El primer día, manda a la Papelera el bundle de la app y solo las cachés que hayas
confirmado que se regeneran.
2. Deja Application Support y Containers donde están, y usa el Mac con normalidad un día.
3. Si las apps hermanas y los otros productos del proveedor siguen arrancando limpios,
elimina el segundo lote.
4. Para las rutas de las que aún dudas, anota el tamaño con `du -sh` y decide una semana
después.
La Papelera ocupa el mismo volumen, así que no se libera nada hasta que la vacías. Lo que
ganas esperando es una ventana de recuperación. Si el disco está realmente lleno, vacía
primero las cachés regenerables para respirar y deja las rutas en disputa para después.
## Permisos y visibilidad
Sin Full Disk Access, Terminal y la mayoría de escáneres no ven dentro de Containers ni de
parte de Library. `du` imprime errores de permiso y aun así termina con un total, y a ese
total le falta todo lo que no pudo abrir. Eso no se lee como "no queda nada", sino como
"no tienes derecho a mirar".
- Dale Full Disk Access a Terminal, o a la herramienta que hace el escaneo, y vuelve a
medir.
- Compara los números de antes y después. Decidir a partir de la pasada medio ciega es así como
un contenedor de varios gigabytes acaba declarado vacío.
- Quítale Full Disk Access a las herramientas que ya no usas. Es el permiso de lectura más
amplio del Mac, y una vez concedido sobrevive al motivo por el que lo concediste.
## Cómo se relaciona esta guía con la desinstalación completa
[Desinstalación completa](https://mole.fit/es/blog/how-to-completely-uninstall-apps-on-mac) es el orden que se
sigue mientras la app todavía está instalada: primero el desinstalador del proveedor,
exportar o desautorizar, salir, eliminar el bundle y luego revisar lo que queda. Esta guía
da por hecho que el bundle ya no está, que es lo que quita las pruebas fáciles, y dedica su
extensión a la mitad que queda: decidir qué archivos eran de la app y cuáles solo estaban
compartidos.
## Lecturas adicionales
- Apple: [Eliminar o desinstalar apps en el Mac](https://support.apple.com/102610)
- Relacionado: [desinstalación completa](https://mole.fit/es/blog/how-to-completely-uninstall-apps-on-mac),
[alternativas a AppCleaner](https://mole.fit/es/blog/appcleaner-alternative),
[lo que los limpiadores nunca deben borrar](https://mole.fit/es/blog/what-mac-cleaners-should-never-delete)
Limpiar residuos es mantenimiento de identidad. La habilidad no es maximizar gigabytes;
es probar propiedad, proteger estado compartido y mantener los borrados recuperables.
## Preguntas frecuentes
### ¿Es seguro borrar yo mismo archivos residuales bajo ~/Library?
Solo con atribución: asocia la carpeta al identificador de bundle de la app, no a su
tamaño ni a un nombre parecido, y revisa cada ítem antes de que se vaya. Un error puede
llevarse datos de otra app o tus propios documentos.
### ¿Por qué las apps dejan archivos en absoluto?
macOS no tiene un contrato de desinstalación: arrastrar el bundle a la Papelera es todo el
mecanismo, y todo lo que la app escribió en tiempo de ejecución se queda donde se escribió.
### ¿Una reinstalación recreará lo que borré?
El estado reconstruible, sí: cachés, receipts y preferencias por defecto vuelven en el
primer arranque. Documentos, historial de chat y licencias no, por eso una herramienta
cuidadosa preselecciona solo lo que una reinstalación recrearía.
---
Canonical HTML page: https://mole.fit/es/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps
Blog index for agents: https://mole.fit/es/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
