Saltar al contenido principal
Mole
Resumen Funciones Opiniones Precio FAQ Blog
EnglishEN 简体中文中 繁體中文繁 日本語日 한국어한 FrançaisFR DeutschDE ItalianoIT EspañolES
Comprar ahoraComprar Descargar

    Ayuda, documentación, versiones y artículos.

    Inicio/Blog

    Eliminar restos tras desinstalar apps en Mac

    DesinstalaciónPublicado 29 de julio de 2026Actualizado 8 de agosto de 202610 min de lectura

    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 "quién encuentra más basura" y pasa a ser "cuyos errores duelen menos".

    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. Para opciones de producto, consulta más allá de AppCleaner.

    Respuesta corta: 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 (Delete or uninstall apps).

    Bundle de la aplicación, archivos de soporte en la Biblioteca del usuario y helpers a nivel de sistema como tres capas
    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/<Name or ID> Bases de datos, paquetes offline, estado de proyectos
    Caches/<bundle id> 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/<bundle id>. 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 Bundle identifier encuentra rutas de propiedad exactas; la coincidencia por display-name encuentra más candidatos y más falsos positivos
    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.<bundle id>
    • nombres con alcance de equipo como <TeamID>.<bundle id>
    • 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 identidad del bundle alimenta candidatos a restos mientras las carpetas compartidas del proveedor permanecen protegidas
    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/<Name> \
      ~/Library/Caches/<bundle.id> \
      ~/Library/Containers/<bundle.id> 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

    Mole reúne análisis de disco, mantenimiento de apps y limpieza con revisión primero en una app nativa de Mac. macOS y las apps propietarias siguen gestionando los datos del sistema.

    Los huérfanos no son "cualquier cosa grande en Library"

    Descubrir residuos de apps que olvidaste requiere sustracción de reclamos: enumerar carpetas de soporte candidatas y restar todo lo que aún reclama el software instalado (bundle ids, apps en ejecución, registro de Launch Services, raíces de proveedor). Si el escaneo de reclamos es parcial (timeout, directorios ilegibles), el resultado seguro es cero huérfanos, no una lista a ojo. Las herramientas que siempre encuentran docenas de apps "basura" en un Mac limpio optimizan un número de ventas.

    Las puertas de periodo de silencio también importan: una config reescrita la semana pasada puede pertenecer a una herramienta CLI que el recorrido de reclamos no ve. Los mtimes recientes deben suprimir 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 <token> limpia la asociación (acepta --zap solo cuando quieres la limpieza más amplia de brew). "Cask is not installed" cuando la app ya no está es una asociación obsoleta, no un motivo para rm -rf rutas aleatorias de Caskroom.

    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)

    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).
    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.

    Lecturas adicionales

    • Apple: Delete or uninstall apps on Mac
    • Relacionado: desinstalación completa, alternativas a AppCleaner, lo que los limpiadores nunca deben borrar

    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.

    Libera espacio, gestiona las apps, mantén macOS y mira qué ocupa el disco, todo en una sola app nativa. Un solo pago, sin suscripción.

    Descubre Mole

    Sigue leyendo

    • DesinstalaciónDesinstalar apps de Mac sin perder datos compartidos7 min de lectura
    • DesinstalaciónDesinstalar Office en Mac sin perder el correo de Outlook5 min de lectura
    • DesinstalaciónCómo quitar Docker Desktop sin perder un volumen6 min de lectura

    Mole · 鼴

    Limpieza, apps y estado del Mac.

    v1.13.0 (153) · Versiones

    Soporte

    Ayuda Documentación Versiones

    Legal

    Condiciones del servicio Política de privacidad Política de reembolso

    Recursos

    Blog Herramienta CLI Programa de socios

    Contacto

    Twitter hi@mole.fit

    El único sitio oficial mole.fit · Evita descargas de sitios no verificados

    La CLI sigue siendo gratuita para la terminal.