Cómo desinstalar apps de Mac instaladas con un paquete .pkg

Una app que llegó con un instalador .pkg no es lo mismo que una app que arrastraste desde una imagen de disco. El instalador se ejecutó como root, pudo escribir donde el paquete le indicara y dejó un registro de lo que instaló en la base de datos de recibos del Instalador. Arrastrar la app a la Papelera quita una carpeta de ese registro y deja el resto, incluido el propio registro. Este artículo trata ese caso: cómo saber que un paquete instaló la app, cómo leer lo que puso en el disco, qué quitar y qué dejar. Si Finder se niega sin más, o la app vuelve después de borrarla, empieza mejor por cuando una app del Mac no se deja desinstalar, y para una app que arrastraste tú mismo, la guía de desinstalación completa cubre el camino habitual.

Por qué no basta con la Papelera

Un paquete puede poner archivos junto a la app, no solo dentro. Cuando volví a desinstalar apps con sus instaladores oficiales, el paquete oficial de Zoom dejó tres trabajos de launchd y un helper privilegiado, us.zoom.ZoomDaemon, fuera de zoom.us.app. El instalador de Logi Options+ también instaló un segundo producto, LogiRightSight, con su propio recibo y su propio agente de inicio. DisplayLink Manager añadió un agente de inicio en /Library/LaunchAgents. Microsoft Office instala un paquete de frameworks compartidos que cargan Word, Excel y PowerPoint, y con él llegan Microsoft AutoUpdate y un helper de licencias. Nada de eso se mueve cuando se mueve el bundle de la app.

El recibo tampoco se mueve. Vive en la base de datos propia del Instalador, separada de los archivos que describe, así que quitar la app deja a pkgutil diciendo que el paquete sigue instalado. Después de una pasada limpia del desinstalador oficial de DisplayLink, sus dos recibos seguían ahí.

Una petición de contraseña en Finder es la otra señal de que se trata de un paquete. El instalador se ejecutó como root, así que el bundle que dejó pertenece a root, y moverlo exige autenticarse. Es normal y se explica en la guía de problemas al desinstalar.

Comprobar si la instaló un paquete

Empieza por la lista de recibos y la ruta de la propia app:

pkgutil --pkgs | grep -i zoom
pkgutil --file-info /Applications/zoom.us.app

pkgutil --pkgs lista todos los identificadores de paquete que el Instalador ha registrado en el volumen de arranque. Busca el fabricante y el nombre del producto, no solo el identificador de bundle de la app, porque a menudo no tienen nada que ver. La app de Zoom es us.zoom.xos y su recibo es us.zoom.pkg.videomeeting. El recibo que instala Cookie.app es app.fantasticthing.Bookkeeping. Hasta las mayúsculas pueden variar: el identificador de bundle de 爱思助手 es cn.i4Tools.mac y su recibo es cn.i4tools.mac, y pkgutil compara los identificadores de forma exacta, así que la versión con mayúsculas responde «No receipt» mientras el recibo está ahí mismo. Copia el identificador de la salida de --pkgs en lugar de escribirlo.

Se supone que pkgutil --file-info nombra el paquete que instaló una ruta, en líneas pkgid: debajo de la ruta. No interpretes una respuesta vacía como «no viene de un paquete». En macOS 27 comprobé que solo muestra volume y path para la mayoría de las rutas, borradas o presentes; la app de DisplayLink Manager recibió esa respuesta vacía mientras sus dos recibos seguían en el Mac. Un recibo tampoco demuestra que ejecutaras un .pkg tú mismo: la Mac App Store deja uno para algunas apps, como com.apple.pkg.TestFlight.

Lo que registra un recibo

Dos comandos muestran qué instaló un paquete y dónde:

pkgutil --pkg-info us.zoom.pkg.videomeeting
pkgutil --files us.zoom.pkg.videomeeting

--pkg-info muestra el identificador del paquete, la versión, volume, location y la fecha de instalación. --files muestra rutas relativas a ese volumen y esa ubicación, así que la ruta real es la unión de las tres. Un recibo con ubicación Applications lista Foo.app/Contents/...; uno con la ubicación vacía lista Applications/Foo.app/... en su lugar. Lee la ubicación antes de leer la lista, o todas las rutas que busques estarán mal.

La lista incluye directorios además de archivos. --only-files y --only-dirs separan unos de otros, algo útil en cuanto ves que un recibo puede listar Library y Library/LaunchAgents en sí. Los registros en bruto están en /private/var/db/receipts, un .bom y un .plist por paquete, pero el manual de pkgutil dice que la ubicación de los archivos de recibo puede cambiar y que hay que consultarlos siempre a través de pkgutil.

Un recibo es un mapa, no una lista de borrado

Tienta pasar pkgutil --files a un bucle y borrarlo todo. Así es como la desinstalación de un paquete rompe otra cosa. La lista dice lo que escribió este paquete, no lo que solo usa este paquete:

A la lista también se le escapan cosas. Registra lo que la carga útil del paquete puso en el disco. Los scripts del instalador pueden hacer más, y los paquetes los llevan: el de Foxit, por ejemplo, tiene un script postinstall y un servicio de actualización. La app escribe sus propios datos en la Biblioteca de tu carpeta de inicio en cuanto se ejecuta, y nada de eso está en ningún recibo. Para esa parte, usa encontrar restos después de desinstalar.

Ejecuta primero el desinstalador del fabricante

Las indicaciones de Apple para eliminar apps son claras en esto: si una app incluye un desinstalador, «es la mejor forma de eliminar la app y cualquier ítem de inicio, extensión u otros datos que la app haya podido guardar en otras ubicaciones». El software instalado con paquetes suele traer uno, porque el fabricante conoce sus propios scripts, helpers y componentes compartidos. Busca en la imagen de disco de la que salió el paquete, en la carpeta de la app dentro de Aplicaciones, en /Applications/Utilities, en los menús de la propia app y en la web de soporte del fabricante. Splashtop Personal, por ejemplo, pone su desinstalador en la misma imagen de disco que el paquete.

Si ya arrastraste la app a la Papelera, devuélvela con Archivo › Devolver (File › Put Back), ábrela y ejecuta su desinstalador desde ahí. Para software de seguridad, clientes VPN y controladores, la herramienta del fabricante no es opcional: las extensiones y los filtros de red solo se retiran a través de la app a la que pertenecen, como explica desinstalar un antivirus en Mac.

Quitarlo a mano

Cuando no hay desinstalador, el recibo te dice dónde mirar. Trabaja a partir de él en este orden:

1. Cierra la app y todo lo que ejecute en segundo plano.
2. Lee --pkg-info para ver la ubicación, después --files para la lista, y apunta las rutas que están fuera del bundle de la app.
3. Para cada agente o daemon de inicio de la lista, descarga el trabajo con launchctl bootout antes de mover su plist. La sección de launchd de la guía de problemas explica por qué importa el orden.
4. Mueve a la Papelera solo lo que claramente pertenece a este producto: el bundle de la app, las carpetas y plists con el nombre de su identificador de bundle o de su producto, su helper en /Library/PrivilegedHelperTools. Deja las carpetas contenedoras compartidas y todo lo que las demás apps del fabricante sigan usando. pkgutil --pkgs | grep -i vendorname muestra si siguen instalados otros paquetes del mismo fabricante; si es así, sus frameworks compartidos se quedan.
5. Olvida el recibo al final, cuando ya no quede nada de lo que lista:

sudo pkgutil --forget com.vendor.pkg

--forget descarta el recibo y, en palabras del manual, «no toca los archivos instalados». Ejecutarlo primero deja todos los archivos en su sitio sin ningún registro que apunte a ellos, lo que complica el resto del trabajo. Necesita sudo porque /private/var/db/receipts pertenece a root, y necesita el identificador exactamente como lo escribe --pkgs. Un recibo obsoleto no guarda datos de usuario, así que si no estás seguro de si algo de lo que lista sigue en uso, dejar el recibo no cuesta nada.

Comprobar el resultado

Estos comandos solo leen. Sustituye com.vendor.pkg y vendorname por lo que encontraste arriba:

id=com.vendor.pkg
loc=$(pkgutil --pkg-info "$id" | sed -n 's/^location: //p')
pkgutil --files "$id" --only-files | while IFS= read -r f; do
  p="/${loc:+$loc/}$f"
  [ -e "$p" ] && echo "$p"
done
pkgutil --pkgs | grep -i vendorname
ls /Library/LaunchAgents /Library/LaunchDaemons /Library/PrivilegedHelperTools | grep -i vendorname
launchctl list | grep -i vendorname
launchctl print system | grep -i vendorname

El bucle muestra cada archivo del recibo que sigue existiendo, con su ruta completa. Si no muestra nada, la carga útil ha desaparecido y se puede olvidar el recibo sin riesgo. Una salida dentro del bundle de la app significa que la app sigue instalada; una salida en otro sitio es lo que se le escapó a la eliminación, o lo que decidiste conservar porque otra app lo comparte. Si pkgutil responde «No receipt for ... found», el recibo ya se olvidó o el identificador se escribe de otra forma. Las líneas de ls y launchctl detectan helpers que el recibo nunca listó. launchctl list muestra tus propios agentes y launchctl print system muestra los daemons. Cualquier línea de uno u otro significa que el trabajo sigue cargado, y un número distinto de cero en su primera columna significa que está en ejecución ahora mismo.

Cómo gestiona Mole las apps instaladas con pkg

Cuando quitas una app en Mole, lee los recibos cuyo nombre coincide con el identificador de bundle o el nombre de producto de la app y lista las rutas de esos recibos que siguen existiendo, pero solo dentro de un conjunto reducido: el bundle de la app en Aplicaciones y, bajo /Library, solo las carpetas Application Support, Caches, Logs, PrivilegedHelperTools, WebKit y HTTPStorages, más los plists de Preferences, LaunchAgents y LaunchDaemons, con ese identificador de bundle exacto en el nombre. Esas filas llegan sin marcar, así que marcas cada una después de leerla. Las rutas bajo /Users, /opt, /usr y /private nunca se convierten en filas a partir de un recibo, y tampoco los propios archivos de recibo.

Cuando la app ya no está, Mole olvida el recibo con el nombre de su identificador de bundle, usando la grafía que pkgutil tiene en el disco, y un recibo del fabricante que encuentre mediante pkgutil --file-info, este último solo cuando ya no existe ninguno de los archivos que lista ese recibo. Solo lo hace cuando el helper de administrador ya estaba autorizado para esa eliminación, así que nunca provoca una petición de contraseña extra por un recibo. La búsqueda del fabricante se salta los recibos com.apple.* de Apple.

El límite es el que se describe arriba. Como pkgutil --file-info casi nunca responde en macOS 27, un recibo cuyo identificador no tiene nada que ver con la app puede quedarse después de que Mole la quite, como pasó con los dos de DisplayLink y con el de Zoom. Son solo registros, y sudo pkgutil --forget los borra. Para controladores, clientes VPN y software de seguridad, Mole no sustituye al desinstalador del fabricante.

Preguntas frecuentes

¿pkgutil --forget desinstala la app?

No. El manual dice que descarta todos los datos del recibo del paquete pero no toca los archivos instalados. Ejecútalo cuando los archivos ya no estén, nunca en lugar de quitarlos.

¿Puedo borrar todos los archivos que lista pkgutil --files?

No. La lista incluye directorios del sistema como Library y Applications, frameworks que cargan las demás apps del fabricante y plists de trabajos que pueden seguir en ejecución. Úsala para saber qué revisar y luego quita lo que pertenece solo a este producto.

La app ya no está, pero pkgutil --pkgs la sigue listando. ¿Sigue instalada?

No necesariamente. Borrar archivos nunca actualiza el recibo, así que se queda hasta que alguien lo olvide. Ejecuta el bucle de comprobación de arriba: si ya no existe nada de lo que lista el recibo, solo queda el registro, y sudo pkgutil --forget lo elimina.