Una app de Mac no se desinstala: siete causas que revisar

DesinstalaciónPublicado Actualizado 16 min de lectura

Una desinstalación fallida en macOS no es un solo problema. El Finder puede negarse a mover el bundle. El movimiento puede tener éxito y la app puede volver en el siguiente inicio de sesión. El bundle puede desaparecer mientras el helper que te molestaba sigue corriendo. Cada uno es un mecanismo distinto con un arreglo distinto, así que empieza por lo que exactamente hizo tu Mac. Para la secuencia normal, revisa desinstalar por completo; lo que sigue asume que eso ya falló.

Empieza por el síntoma

Seis síntomas de desinstalación fallida, una alerta de elemento abierto, la app volviendo después de borrarla, nada ocurriendo en absoluto, una petición de contraseña de administrador, un error de operación no permitida como root, y un elemento atenuado en Ajustes, cada uno dirigido a su causa distinta.
El texto exacto de la negativa es diagnóstico. Dos de estos seis no producen ningún diálogo en absoluto, por eso se leen como que la herramienta está rota.
  • "El elemento no se puede mover a la Papelera porque está abierto." Algo está corriendo, con frecuencia no la app que cerraste.
  • Se borró y volvió. Distingue una app reinstalada de un proceso auxiliar que seguía en disco y se ha vuelto a ejecutar.
  • Finder pide una contraseña de administrador. Un .pkg dejó el bundle propiedad de root. Normal.
  • No pasa nada. Ni diálogo ni error. Una posible causa es el permiso de Gestión de apps.
  • rm como root dice "Operation not permitted". Hay una restricción de permisos o protección; el mensaje por sí solo no identifica SIP.
  • Atenuado, o reaparece en un Mac de trabajo. Un perfil de configuración o MDM es su dueño.

1. La app, o uno de sus helpers, sigue corriendo

Finder se niega a mover un bundle cuyos archivos están abiertos, y cerrar el proceso que puedes ver no detiene todo lo que la app arrancó. El Monitor de Actividad lista cada proceso, no solo los que tienen una ventana. Busca el nombre del proveedor y lee todo el conjunto de resultados: una app llamada Foo suele traer Foo Helper, un FooUpdater, y un bundle de ítem de inicio con un nombre visible que no tiene relación. La ventana de menú Apple > Forzar salida no es un sustituto, porque solo lista aplicaciones con presencia de interfaz.

pgrep -fl -i foo
lsof +D /Applications/Foo.app 2>/dev/null | awk '{print $1, $2}' | sort -u

pgrep -fl coincide con la línea de comando completa, así que atrapa un helper cuya ruta ejecutable lleva el nombre del proveedor aunque su nombre de proceso no lo lleve. lsof +D reporta cada proceso que mantiene abierto un archivo dentro del bundle.

Forzar la salida del padre no detiene de forma confiable a un helper. Un helper es su propio proceso con su propio PID, así que matar al padre lo deja huérfano a menos que el padre lo desmonte al salir. Y si launchd gestiona al helper, matar a cualquiera de los dos solo le dice a launchd que lo vuelva a arrancar. Eso es la siguiente sección.

Una vista previa de Quick Look o la indexación de Spotlight también pueden mantener abiertos archivos del bundle, y un reinicio limpia ambas cosas. Si el mensaje vuelve, la guía de eliminación de apps de Apple sugiere el modo seguro.

2. launchd reinicia un proceso auxiliar que sigue en disco

Si reaparece un icono o proceso auxiliar, comprueba si su ejecutable sigue fuera del paquete eliminado. launchd puede reiniciar ese programa, pero no restaurar por sí solo una app borrada. No verlo en una consulta del Monitor de Actividad no descarta un trabajo bajo demanda.

launchd supervisa los trabajos en segundo plano. Un trabajo es una property list con un Label, un programa, y condiciones para correrlo. RunAtLoad lo arranca cuando el trabajo carga, KeepAlive lo reinicia cuando termina. Un trabajo sin ninguno de los dos igual vuelve: MachServices, Sockets, WatchPaths, QueueDirectories, y StartInterval hacen que launchd arranque el proceso en el momento en que algo lo pide, así que un helper que queda en reposo después de diez segundos y se reinicia con su servicio Mach se ve ausente cada vez que revisas.

Las definiciones viven en tres sitios. ~/Library/LaunchAgents es solo tu usuario, dentro de tu sesión de inicio; /Library/LaunchAgents corre para cada usuario al iniciar sesión; /Library/LaunchDaemons contiene trabajos del sistema que no requieren una sesión abierta. Se ejecutan como root por defecto, pero pueden indicar otro usuario. Tanto agentes como daemons pueden quedar fuera del paquete tras una desinstalación manual. /System/Library/Launch* es de Apple y está protegido.

launchctl list | grep -i foo
launchctl print-disabled gui/$(id -u) | grep -i foo
grep -l -i foo ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist \
  /Library/LaunchDaemons/*.plist 2>/dev/null

En launchctl list, una etiqueta con un PID está corriendo ahora y una con un guion está cargada y esperando un disparador; print-disabled lee la base de datos persistente de estado deshabilitado, un hecho separado de si existe un plist. Lee el candidato con plutil -p <path> y comprueba que Program o ProgramArguments apunte a la app que estás quitando: los proveedores no siempre nombran el archivo según la etiqueta que lleva dentro.

El orden importa

Detén y deshabilita primero el trabajo, luego quita el plist, luego quita la app.

launchctl bootout gui/$(id -u)/com.vendor.foo.helper
sudo launchctl bootout system/com.vendor.foo.daemon
launchctl disable gui/$(id -u)/com.vendor.foo.helper

Borra el plist mientras el trabajo está cargado y launchd mantiene un servicio cuya definición ya no existe en disco; corre hasta el siguiente reinicio y puede dejar una entrada obsoleta en la base de datos de estado deshabilitado. Quitar la app primero es peor: el trabajo vuelve a arrancar contra un ejecutable que ya no está y falla en bucle, de ahí viene "ya no está pero sigue apareciendo en Ítems de inicio".

En macOS 13 y posterior, las apps pueden registrarse mediante SMAppService y guardar el ejecutable auxiliar y los archivos del servicio dentro del paquete de la app. Por eso puede no haber un plist separado en las carpetas anteriores. macOS gestiona el registro mediante Background Task Management, que se consulta en Ajustes del Sistema > General > Ítems de inicio y extensiones (guía de ítems de inicio).

3. Es una app del sistema protegida por SIP

System Integrity Protection es una política a nivel de kernel, no un bit de permiso. Apple la describe como el uso de permisos de kernel para limitar la capacidad de escritura de archivos críticos del sistema, aplicada "a cada proceso que corre en el sistema, sin importar si ese proceso corre en sandbox o con privilegios administrativos" (Apple Platform Security). Desde Big Sur el contenido del sistema también vive en un volumen separado y sellado criptográficamente. csrutil status imprime si la protección está activada, y Apple es explícita en que "no puedes quitar apps que tu Mac necesita", un conjunto que incluye Mail, Music, Books, Notes, Podcasts, Maps, News y Stocks.

Desactivar SIP para borrar un solo bundle es un mal cambio. Significa arrancar en Recuperación y cambiar una política de seguridad de toda la máquina; en Macs Intel, Apple señala que desactivarlo quita la protección de cada partición del dispositivo de almacenamiento físico, y en Apple silicon el Mac sale de Full Security. Y la ganancia tampoco dura: el volumen del sistema se reemplaza por completo en la siguiente actualización de macOS, y no se recupera espacio utilizable.

Mejor: arrastra el ícono fuera del Dock, quítalo de Ajustes del Sistema > General > Ítems de inicio y extensiones, y si sigue abriendo tus archivos, cambia el manejador con Obtener información > Abrir con > Cambiar todo.

4. La instaló MDM o un perfil de configuración

En un Mac gestionado, una app se puede volver a empujar según el horario del servidor de gestión, y un perfil se puede marcar como no removible. Los síntomas son una eliminación que se deshace horas después, un control atenuado, o una búsqueda en launchd que no encuentra nada porque la reinstalación se dirige de forma remota. Revisa Ajustes del Sistema > General > Gestión de dispositivos. La ausencia de esa sección no basta para descartar la gestión: comprueba la inscripción y consulta a TI si el Mac es de la organización.

profiles status -type enrollment
sudo profiles list

El primero reporta la inscripción a través de Automated Device Enrollment y si está aprobada por el usuario; el segundo lista los perfiles instalados y necesita root. Luego pregúntale a TI. La guía de Apple es preguntarle a quien te dio un perfil que no puedes quitar, y advierte que quitar un perfil borra todo lo que ese perfil configuró, así que uno que lleve tu cuenta de correo se la lleva consigo.

5. Propiedad, y el permiso que falla en silencio

Finder pide una contraseña de administrador. Normal. Un instalador .pkg corre como root y deja el bundle propiedad de root, así que moverlo necesita autenticación. Confírmalo con ls -ld /Applications/Foo.app. Vale la pena conocer los recibos ya que estás aquí: pkgutil --files <id> lista las rutas que puso un paquete, y sudo pkgutil --forget <id> quita el recibo de /private/var/db/receipts sin borrar ni un solo archivo.

No pasa nada en absoluto. Sin aviso, sin error, la app sigue en /Applications, y la herramienta que usaste reporta un fallo vago o recurre a otra cosa. En macOS 14 y posterior, Gestión de apps es una posible causa: controla qué apps pueden actualizar o eliminar otras. Esta comprobación de solo lectura indica si la ruta del paquete permite escritura:

test -w /Applications/Foo.app && echo "posix says yes"

Un resultado positivo no descarta un problema de permisos. El borrado también depende del acceso de escritura y búsqueda al directorio padre, las ACL y otras protecciones. Si Gestión de apps está denegado, abre Ajustes del Sistema > Privacidad y seguridad > Gestión de apps, autoriza la app de confianza que realiza el borrado y vuelve a abrirla para probar de nuevo.

Por debajo: tres negativas que se ven iguales

Los permisos de archivos son una barrera: influyen el propietario, el acceso al directorio padre y las ACL. La autorización de administrador resuelve algunas restricciones, no todas. TCC, la capa de privacidad de Ajustes del Sistema, hace una comprobación independiente. Gestión de apps es una barrera de TCC para modificar o borrar el bundle de otra app. Ser administrador no la satisface y sudo tampoco, porque está atada al programa que hace la solicitud y no al usuario, por eso su negativa puede aparecer como un error genérico sin ningún aviso.

SIP puede rechazar incluso a root, pero el texto del error no identifica por sí solo la protección. EACCES (Permission denied) puede indicar falta de acceso de escritura o búsqueda al directorio padre. EPERM (Operation not permitted) tiene causas además de SIP. Comprueba la ruta, el propietario, los permisos del directorio padre y la app que hace la solicitud. Ninguno de los mensajes justifica desactivar la protección del sistema.

6. Una extensión del sistema o un filtro de red sigue activo

El software de seguridad, los clientes VPN y los productos de virtualización instalan extensiones del sistema. Borrar archivos sueltos no es un procedimiento fiable para desactivarlas. macOS puede quitar una extensión del sistema al trasladar correctamente su app contenedora a la Papelera, pero el producto puede haber instalado otros componentes. Sigue el procedimiento del proveedor y comprueba el estado final.

systemextensionsctl list

La salida muestra el identificador de equipo, el identificador de bundle, y un estado como [activated enabled]. La desactivación pertenece a la app contenedora y a menudo necesita un reinicio, así que corre primero el desinstalador del proveedor. Desinstalar antivirus en Mac cubre el orden de desmontaje para esta categoría.

7. Vino de la App Store, o de Homebrew

Apps de la Mac App Store. Borrar el bundle no quita la compra. El caso que atrapa a la gente es el ajuste que Apple describe como "Descargar automáticamente las apps que compraste en la App Store en otras Mac y dispositivos": una compra nueva en otro dispositivo puede descargarse aquí. Que la app siga instalada en un segundo Mac no demuestra por sí solo la causa de una reinstalación. Comprueba la opción en App Store > Ajustes.

Casks de Homebrew. Si instalaste con brew install --cask foo, mandar la app a la Papelera deja a Homebrew creyendo que sigue instalada. brew list --cask todavía muestra el token, y el siguiente brew upgrade puede reinstalar la app que acabas de borrar, una causa real de "volvió" sin ningún trabajo de launchd de por medio. Corre brew uninstall --cask foo en su lugar. El manual de Homebrew describe --zap como quitar "todos los archivos asociados a un cask" y advierte que "puede quitar archivos que se comparten entre aplicaciones", así que recurre a esa opción de forma deliberada.

Después de un borrado exitoso: qué se queda atrás

Ítems de inicio y extensiones todavía la lista. O una entrada de "Abrir al iniciar sesión" que apunta a una ruta que ya no existe, o un registro de Background Task Management de un servicio cuyo programa ya no está. Quítala con el botón menos en Ajustes del Sistema > General > Ítems de inicio y extensiones; macOS suele limpiar esto solo después de un reinicio.

Aparece un ícono en la barra de menús al arrancar. Algo todavía carga un binario: normalmente un launch agent que nunca quitaste, o un helper que el instalador copió a ~/Library/Application Support/<vendor>.

Sobrevive un helper con privilegios. El software que necesitaba root se instala en /Library/PrivilegedHelperTools/<label> con un /Library/LaunchDaemons/<label>.plist a juego. Ambos son propiedad de root y están fuera del bundle, así que mandar la app a la Papelera no toca ninguno de los dos.

ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons \
  /Library/PrivilegedHelperTools 2>/dev/null

Para el lado de los datos, revisa archivos sobrantes tras desinstalar.

Hacer este diagnóstico en Mole

La versión manual de este artículo cuesta cinco pantallas: Monitor de Actividad, tres carpetas de launchd, Ítems de inicio y extensiones, Privacidad y seguridad, y Finder. Mole pone las partes que pertenecen a una app en una sola pestaña, y escanear siempre es gratis, así que funciona como diagnóstico de solo lectura la compres o no.

Una pantalla de revisión de desinstalación con una app expandida mostrando su bundle más elementos sobrantes en ~/Library/Application Support y ~/Library/HTTPStorages, cada uno con un tamaño y una casilla, y un botón Remove abajo.
Cada elemento que la eliminación tocaría, con su ruta exacta y tamaño, antes de que se mueva nada.

Abre la pestaña Software de Mole. Tiene tres segmentos: el inventario de apps instaladas, las actualizaciones disponibles, y los ítems de inicio. Ese último es el inventario de launchd e ítems de inicio que este artículo te dijo que armaras a mano, así que la causa de "vuelve" es visible antes de borrar y no después.

Selecciona una app y Mole resuelve su identificador de bundle, y luego encuentra qué posee esa identidad: Application Support, Caches, Preferences, Containers, HTTPStorages, y launch agents o daemons cuyo plist de verdad hace referencia a la app en vez de solo compartir una palabra con su nombre. Cada candidato lleva su ruta, tamaño, y la evidencia que lo asoció, y todo lo de baja confianza llega desmarcado.

Confirmar corre el orden que recomienda este artículo, aplicado en vez de recordado. Mole cierra la app y los helpers anidados dentro de su bundle, da de baja sus helpers de ítem de inicio, descarga cualquier ítem de arranque aprobado a través de launchctl antes de quitar su plist, y vuelve a validar cada ruta al momento de borrar. Los borrados ordinarios van a la Papelera. Mientras sigan allí, los archivos suelen poder restaurarse, pero eso no deshace toda la desinstalación.

Luego Mole reporta los elementos omitidos y fallidos con sus rutas en vez de un total de éxito, así que una fila rechazada porque Gestión de apps está denegado, o porque una ruta es propiedad de root y la salvaguarda la rechazó, te dice cuál de las causas de arriba acabas de encontrar. Una herramienta que imprime una marca de verificación sobre una escritura rechazada es la razón por la que la gente se pasa una tarde preguntándose por un ícono en la barra de menús. Todo lo que hace Mole corre localmente, y las operaciones de archivo se añaden a ~/Library/Logs/mole/operations.log. En una terminal, el Mole CLI es gratis y de código abierto, y mo uninstall acepta --dry-run así que puedes leer la lista de rutas primero.

Mole no pelea las tres causas que no puede ganar: no va a desactivar SIP ni a quitar una app de fábrica de Apple del volumen sellado, no puede anular un perfil de configuración que reinstala software en un Mac gestionado, y para agentes de seguridad, clientes VPN y productos de virtualización no es un sustituto del desinstalador del proveedor que conoce el orden de desmontaje. Cuando Gestión de apps está denegado, Mole reporta el fallo en vez de escalar privilegios para saltárselo.

Preguntas frecuentes

¿Por qué vuelve una app después de que la borro?

Distingue primero una app reinstalada de un proceso auxiliar reiniciado. launchd puede ejecutar un archivo que aún existe, no reconstruir un paquete borrado. Puede quedar un registro de Homebrew si usaste la Papelera en vez de brew uninstall --cask, MDM puede reinstalar la app en un Mac gestionado, o la App Store puede descargar una compra nueva de otro dispositivo si esa opción está activada.

¿Puedo borrar las apps integradas de Apple si desactivo SIP?

Desactivar SIP por sí solo no permite escribir en el volumen del sistema sellado. Intentar borrar apps necesarias puede exigir debilitar otras protecciones y no es un método de limpieza compatible. Quita el icono del Dock o de Ítems de inicio en su lugar.

Finder pide mi contraseña para borrar una app. ¿Algo está mal?

No. Un instalador .pkg puso el bundle ahí como root, así que moverlo necesita autenticación. El fallo que vale la pena preocuparse es el opuesto: sin aviso, sin error, no pasa nada. Una posible causa es Gestión de apps denegado bajo Ajustes del Sistema > Privacidad y seguridad, y sudo no lo arregla, porque la compuerta está atada al programa que pregunta y no al usuario.

Lecturas relacionadas