Wenn sich eine Mac-App nicht deinstallieren lässt: sieben Ursachen, je ein Symptom

Ein gescheitertes Deinstallieren unter macOS ist nicht ein einziges Problem. Der Finder kann sich weigern, das Bundle zu verschieben. Das Verschieben kann klappen, und die App ist beim nächsten Login trotzdem wieder da. Das Bundle kann verschwinden, während der Helper, der Sie gestört hat, weiterläuft. Jeder Fall hat einen eigenen Mechanismus und eine eigene Lösung, deshalb starten Sie bei dem, was Ihr Mac tatsächlich getan hat. Für den normalen Ablauf siehe Apps vollständig deinstallieren; was hier folgt, setzt voraus, dass das bereits fehlgeschlagen ist.

Beim Symptom anfangen

• „Element kann nicht in den Papierkorb gelegt werden, weil es geöffnet ist." Irgendetwas läuft noch, oft nicht die App, die Sie beendet haben.
• Sie haben sie gelöscht, und sie ist wieder da. Ein launchd-Job, ein Profil oder ein Paketmanager hat sie zurückgeholt.
• Der Finder fragt nach einem Administratorkennwort. Ein .pkg hat das Bundle im Besitz von Root hinterlassen. Normal.
• Nichts passiert. Kein Dialog, kein Fehler. Die App-Management-Berechtigung ist verweigert.
• rm sagt als Root „Operation not permitted". System Integrity Protection.
• Ausgegraut, oder sie taucht auf einem Arbeits-Mac wieder auf. Ein Konfigurationsprofil oder MDM verwaltet sie.

1. Die App oder einer ihrer Helfer läuft noch

Der Finder weigert sich, ein Bundle zu verschieben, dessen Dateien geöffnet sind, und wenn Sie den sichtbaren Prozess beenden, stoppt das nicht alles, was die App gestartet hat. Die Aktivitätsanzeige listet jeden Prozess, nicht nur die mit einem Fenster. Suchen Sie nach dem Herstellernamen und lesen Sie sich das ganze Ergebnis durch: Eine App namens Foo bringt oft Foo Helper, einen FooUpdater und ein Anmeldeobjekt mit einem völlig anderen Anzeigenamen mit. Das Fenster unter Apple-Menü > Sofort beenden ist kein Ersatz dafür, weil es nur Anwendungen mit einer sichtbaren Oberfläche auflistet.

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

pgrep -fl prüft die komplette Befehlszeile und erwischt damit auch einen Helper, dessen ausführbarer Pfad den Herstellernamen trägt, selbst wenn der Prozessname es nicht tut. lsof +D zeigt jeden Prozess, der eine Datei innerhalb des Bundles offen hält.

Den Hauptprozess erzwungen zu beenden stoppt einen Helper nicht zuverlässig. Ein Helper ist ein eigenständiger Prozess mit eigener PID, das Beenden des Hauptprozesses macht ihn also zur Waise, sofern der Hauptprozess ihn beim Beenden nicht selbst mit abräumt. Und wenn launchd den Helper verwaltet, sagt das Beenden von beiden launchd nur, ihn erneut zu starten. Darum geht es im nächsten Abschnitt.

Auch eine Schnellansicht-Vorschau oder die Spotlight-Indizierung kann Dateien im Bundle offen halten, ein Neustart räumt beides auf. Kommt die Meldung danach wieder, empfiehlt Apples Anleitung zum Entfernen von Apps den abgesicherten Modus.

2. Ein launchd-Agent oder -Daemon holt sie zurück

Das ist der Fall „ich habe sie gelöscht und sie ist zurückgekommen", und er wird am häufigsten falsch diagnostiziert: Leute schauen in die Aktivitätsanzeige, sehen nichts und schließen daraus, dass die App nicht lief. Bedarfsgesteuertes Starten bedeutet, dass das kein Beweis ist.

launchd überwacht Hintergrundjobs. Ein Job ist eine Property-List mit einem Label, einem Programm und Bedingungen dafür, wann er läuft. RunAtLoad startet ihn, sobald der Job geladen wird, KeepAlive startet ihn nach jedem Beenden neu. Ein Job ohne beides kommt trotzdem zurück: MachServices, Sockets, WatchPaths, QueueDirectories und StartInterval lassen launchd den Prozess in dem Moment starten, in dem irgendetwas danach fragt, sodass ein Helper, der nach zehn Sekunden Leerlauf beendet wird und über seinen Mach-Dienst wieder anspringt, bei jeder Prüfung abwesend wirkt.

Definitionen liegen an drei Orten. ~/Library/LaunchAgents gehört nur Ihrem Benutzer, innerhalb Ihrer Anmeldesitzung; /Library/LaunchAgents läuft für jeden Benutzer beim Login; und /Library/LaunchDaemons läuft systemweit als Root, noch bevor sich irgendjemand anmeldet, weshalb ein Daemon eine manuelle Deinstallation oft übersteht und ein Agent oft nicht. /System/Library/Launch* gehört Apple und ist geschützt.

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

In launchctl list läuft ein Label mit PID gerade jetzt, eines mit einem Strich ist geladen und wartet auf einen Auslöser; print-disabled liest die dauerhafte Datenbank der deaktivierten Zustände, eine eigene Tatsache, unabhängig davon, ob eine Plist existiert. Lesen Sie den Kandidaten mit plutil -p <path> und prüfen Sie, ob Program oder ProgramArguments auf die App zeigt, die Sie entfernen: Hersteller benennen die Datei nicht immer nach dem Label darin.

Auf die Reihenfolge kommt es an

Stoppen und deaktivieren Sie den Job zuerst, entfernen Sie dann die Plist, entfernen Sie erst danach die 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

Löschen Sie die Plist, während der Job noch geladen ist, behält launchd einen Dienst, dessen Definition auf der Platte gar nicht mehr existiert; er läuft bis zum nächsten Neustart weiter und kann einen veralteten Eintrag in der Datenbank der deaktivierten Zustände hinterlassen. Die App zuerst zu entfernen ist schlimmer: Der Job startet immer wieder gegen eine fehlende ausführbare Datei neu und scheitert in einer Schleife, und genau daher kommt das Phänomen „sie ist weg, taucht aber noch bei den Anmeldeobjekten auf".

Ab macOS 13 registrieren sich Apps über SMAppService, und diese Registrierungen liegen im App-Bundle selbst, sodass es unter Umständen gar keine Plist zu finden gibt. Sie gehören zur Hintergrundaktivitätsverwaltung, die Sie in Systemeinstellungen > Allgemein > Anmeldeobjekte & Erweiterungen steuern (Leitfaden zu Anmeldeobjekten).

3. Es ist eine durch SIP geschützte Systemanwendung

System Integrity Protection ist eine Richtlinie auf Kernel-Ebene, kein Berechtigungs-Bit. Apple beschreibt es so, dass Kernel-Berechtigungen die Schreibbarkeit kritischer Systemdateien einschränken, angewendet „auf jeden auf dem System laufenden Prozess, unabhängig davon, ob dieser Prozess in einer Sandbox oder mit Administratorrechten läuft" (Apple Platform Security). Seit Big Sur liegt der Systeminhalt zusätzlich auf einem eigenen, kryptografisch versiegelten Volume. csrutil status zeigt an, ob der Schutz aktiv ist, und Apple sagt ausdrücklich, dass man „Apps, die für den Mac erforderlich sind" nicht entfernen kann, eine Gruppe, zu der Mail, Musik, Bücher, Notizen, Podcasts, Karten, Nachrichten und Aktien gehören.

SIP abzuschalten, nur um ein einziges Bundle zu löschen, ist ein schlechter Tausch. Das bedeutet, im Wiederherstellungsmodus zu starten und eine maschinenweite Sicherheitsrichtlinie zu ändern; auf Intel-Macs entfernt das laut Apple den Schutz für jede Partition des physischen Speichergeräts, und auf Apple-Silicon-Macs verlässt der Mac dabei die vollständige Sicherheit. Der Gewinn hält auch nicht an: Das Systemvolume wird beim nächsten macOS-Update komplett ersetzt, und es wird kein nutzbarer Speicherplatz frei.

Besser: Ziehen Sie das Symbol aus dem Dock, entfernen Sie den Eintrag unter Systemeinstellungen > Allgemein > Anmeldeobjekte & Erweiterungen, und wenn die App weiterhin Ihre Dateien öffnet, ändern Sie den Standard-Handler über Informationen > Öffnen mit > Alle ändern.

4. Sie wurde durch MDM oder ein Konfigurationsprofil installiert

Auf einem verwalteten Mac kann eine App nach dem Zeitplan des Verwaltungsservers erneut ausgerollt werden, und ein Profil kann als nicht entfernbar markiert sein. Die Symptome sind eine Entfernung, die sich Stunden später von selbst rückgängig macht, ein ausgegrautes Bedienelement, oder eine launchd-Suche, die nichts findet, weil die Neuinstallation von außen gesteuert wird. Prüfen Sie Systemeinstellungen > Allgemein > Geräteverwaltung; fehlt dieser Abschnitt, ist der Mac nicht verwaltet, und das ist nicht Ihre Ursache.

profiles status -type enrollment
sudo profiles list

Der erste Befehl zeigt die Registrierung über Automated Device Enrollment und ob sie vom Benutzer bestätigt wurde; der zweite listet installierte Profile auf und braucht Root-Rechte. Fragen Sie danach die IT-Abteilung. Apples Empfehlung lautet, bei demjenigen nachzufragen, der ein Profil bereitgestellt hat, das Sie nicht entfernen können, und Apple warnt ausdrücklich davor, dass das Entfernen eines Profils alles löscht, was dieses Profil konfiguriert hat, ein Profil mit Ihrem Mail-Konto nimmt dieses also gleich mit.

5. Besitzverhältnisse und die Berechtigung, die stumm scheitert

Der Finder fragt nach einem Administratorkennwort. Ganz normal. Ein .pkg-Installer läuft als Root und hinterlässt das Bundle im Besitz von Root, das Verschieben braucht deshalb eine Authentifizierung. Bestätigen können Sie das mit ls -ld /Applications/Foo.app. Wo wir schon dabei sind, lohnt sich ein Blick auf die Installationsquittungen: pkgutil --files <id> listet die Pfade auf, die ein Paket angelegt hat, und sudo pkgutil --forget <id> entfernt die Quittung aus /private/var/db/receipts, ohne auch nur eine einzige Datei zu löschen.

Es passiert überhaupt nichts. Keine Abfrage, kein Fehler, die App liegt noch immer in /Applications, und das Werkzeug, das Sie benutzt haben, meldet einen vagen Fehler oder weicht auf etwas anderes aus. Auf macOS 14 und neuer ist das meist die App-Verwaltung, die Apple als „Apps erlauben, andere Apps auf dem Mac zu aktualisieren oder zu löschen" beschreibt. Der Verräter: Der Pfad ist POSIX-technisch beschreibbar, und der Schreibvorgang scheitert trotzdem:

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

Erscheint diese Ausgabe und das Entfernen klappt trotzdem nicht, sind es nicht die Dateiberechtigungen. Gehen Sie zu Systemeinstellungen > Datenschutz & Sicherheit > App-Verwaltung, aktivieren Sie dort die App, die die Entfernung durchführt, und starten Sie sie danach neu, denn viele Apps prüfen die Berechtigung nur beim Start.

Im Detail: drei Verweigerungen, die gleich aussehen

POSIX-Berechtigungen sind das erste Tor: Das Bundle gehört Root, Sie nicht, und sudo löst das, weil die Prüfung sich nur dafür interessiert, welcher Benutzer Sie sind. TCC, die Datenschutz-Ebene hinter den Systemeinstellungen, entscheidet erst, nachdem POSIX das durchgelassen hat. Die App-Verwaltung ist ein TCC-Tor für genau eine Operation, das Ändern oder Löschen des Bundles einer anderen App. Administrator zu sein reicht dafür nicht, sudo genauso wenig, weil das Tor am anfragenden Programm hängt und nicht am Benutzer, weshalb die Verweigerung als generischer Fehler ohne jede Abfrage auftauchen kann.

SIP liegt unter beiden und verweigert selbst Root rundheraus. Eine POSIX-Verweigerung setzt EACCES und meldet Permission denied; eine SIP-Verweigerung setzt EPERM und meldet Operation not permitted. Das eine heißt: Versuch es mit mehr Rechten noch mal, das andere heißt: Es gibt keine Rechte, mit denen es noch mal ginge.

6. Eine Systemerweiterung oder ein Netzwerkfilter ist noch aktiv

Sicherheitssoftware, VPN-Clients und Virtualisierungsprodukte installieren Systemerweiterungen. Das App-Bundle registriert die Erweiterung, es ist aber nicht die Erweiterung selbst. Löschen Sie den Container, während die Erweiterung noch aktiv ist, bleibt die Registrierung ohne Besitzer zurück, und genau so filtert ein Mac weiter Netzwerkverkehr durch Software, die Sie eigentlich für entfernt halten.

systemextensionsctl list

Die Ausgabe zeigt Team-ID, Bundle-ID und einen Status wie [activated enabled]. Die Deaktivierung gehört zur enthaltenden App und braucht oft einen Neustart, führen Sie deshalb zuerst den Deinstaller des Herstellers aus. Antivirus unter macOS deinstallieren beschreibt die richtige Reihenfolge für diese Softwareklasse.

7. Sie stammt aus dem App Store oder von Homebrew

Apps aus dem Mac App Store. Das Bundle zu löschen entfernt nicht den Kauf. Was Leuten dabei zum Verhängnis wird, ist die Einstellung, die Apple als „Vom App Store gekaufte Apps automatisch auf anderen Mac-Computern und -Geräten laden" beschreibt: Hat ein zweiter Mac mit demselben Account die App noch installiert, kann diese Einstellung sie zurückholen. Schalten Sie sie in App Store > Einstellungen aus.

Homebrew Casks. Haben Sie mit brew install --cask foo installiert, glaubt Homebrew nach dem Verschieben der App in den Papierkorb weiterhin, sie sei installiert. brew list --cask zeigt den Token weiter an, und das nächste brew upgrade kann die gerade gelöschte App neu installieren, eine echte „sie ist zurück"-Ursache ganz ohne launchd-Job. Führen Sie stattdessen brew uninstall --cask foo aus. Homebrews Manpage beschreibt --zap als das Entfernen „aller mit einem Cask verbundenen Dateien" und warnt, dass es „Dateien entfernen kann, die zwischen Anwendungen geteilt werden", greifen Sie also nur bewusst dazu.

Nach dem erfolgreichen Löschen: was übrig bleibt

Anmeldeobjekte & Erweiterungen listet sie noch. Entweder ein Eintrag „Bei der Anmeldung öffnen", der auf einen fehlenden Pfad zeigt, oder ein Datensatz der Hintergrundaktivitätsverwaltung für einen Dienst, dessen Programm nicht mehr existiert. Entfernen Sie ihn mit dem Minus-Knopf unter Systemeinstellungen > Allgemein > Anmeldeobjekte & Erweiterungen; macOS räumt das nach einem Neustart oft von selbst auf.

Beim Start erscheint ein Menüleistensymbol. Irgendetwas lädt noch eine ausführbare Datei: meist ein Launch-Agent, den Sie nie entfernt haben, oder ein Helper, den der Installer nach ~/Library/Application Support/<vendor> kopiert hat.

Ein privilegierter Helper überlebt. Software, die Root-Rechte brauchte, installiert nach /Library/PrivilegedHelperTools/<label> mit einer passenden /Library/LaunchDaemons/<label>.plist. Beide gehören Root und liegen außerhalb des Bundles, das Verschieben der App in den Papierkorb rührt also keins von beiden an.

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

Für die Datenseite siehe zurückgebliebene Dateien nach dem Deinstallieren.

Diese Diagnose in Mole erledigen

Die manuelle Version dieses Artikels kostet fünf Bildschirme: Aktivitätsanzeige, drei launchd-Ordner, Anmeldeobjekte & Erweiterungen, Datenschutz & Sicherheit und den Finder. Mole bringt alles, was zu einer App gehört, auf eine Registerkarte, und das Scannen ist immer kostenlos, es funktioniert also als reine Lesediagnose, ob Sie es kaufen oder nicht.

Öffnen Sie Moles Software-Registerkarte. Sie enthält drei Abschnitte: das Verzeichnis installierter Apps, verfügbare Updates und Anmeldeobjekte. Der letzte ist genau das launchd- und Anmeldeobjekt-Inventar, das dieser Artikel Sie von Hand zusammenstellen ließ, die „sie kommt zurück"-Ursache wird also schon vor dem Löschen sichtbar, nicht erst danach.

Wählen Sie eine App aus, löst Mole ihre Bundle-ID auf und findet dann alles, was zu dieser Identität gehört: Application Support, Caches, Preferences, Containers, HTTPStorages sowie Launch-Agents oder -Daemons, deren Plist tatsächlich auf die App verweist und nicht nur zufällig ein Wort mit ihrem Namen teilt. Jeder Kandidat trägt seinen Pfad, seine Größe und den Beleg, der ihn dazugerechnet hat, und alles mit geringer Sicherheit kommt unangehakt an.

Das Bestätigen läuft in genau der Reihenfolge, die dieser Artikel empfiehlt, erzwungen statt bloß gemerkt. Mole beendet die App und die im Bundle verschachtelten Helfer, bootet ihre Anmeldeobjekt-Helfer aus, entlädt jedes genehmigte Launch-Item über launchctl, bevor dessen Plist entfernt wird, und prüft jeden Pfad zum Zeitpunkt des Löschens erneut. Entferntes wandert in den Papierkorb, ein Fehler lässt sich also einfach zurückziehen.

Anschließend meldet Mole übersprungene und fehlgeschlagene Einträge mit ihren Pfaden statt nur einer Erfolgszahl, eine Zeile, die abgelehnt wurde, weil die App-Verwaltung verweigert ist, oder weil ein Pfad Root gehört und die Schutzprüfung ihn zurückgewiesen hat, verrät Ihnen also genau, welche der oben beschriebenen Ursachen gerade zutrifft. Dass Leute einen ganzen Abend über ein Menüleistensymbol rätseln, liegt an Werkzeugen, die über einer verweigerten Schreiboperation einfach ein Häkchen anzeigen. Alles, was Mole tut, läuft lokal, und Dateioperationen werden an ~/Library/Logs/mole/operations.log angehängt. In einem Terminal ist Mole CLI kostenlos und quelloffen, und mo uninstall akzeptiert --dry-run, damit Sie die Pfadliste erst lesen können.

Gegen die drei Ursachen, die es nicht gewinnen kann, kämpft Mole gar nicht erst an: Es deaktiviert SIP nicht und entfernt keine mitgelieferte Apple-App vom versiegelten Volume, es kann kein Konfigurationsprofil überstimmen, das Software auf einem verwalteten Mac neu installiert, und bei Sicherheitsagenten, VPN-Clients und Virtualisierungsprodukten ersetzt es nicht den Deinstaller des Herstellers, der die richtige Abbaureihenfolge kennt. Wird die App-Verwaltung verweigert, meldet Mole den Fehler, statt sich mit erhöhten Rechten daran vorbeizumogeln.

Häufige Fragen

Warum kommt eine App zurück, nachdem ich sie gelöscht habe?

Vier Ursachen, ungefähr nach Häufigkeit sortiert. Ein launchd-Agent oder -Daemon hat noch eine Job-Definition, die auf sie zeigt, und startet sie über einen Auslöser neu, den Sie in der Aktivitätsanzeige nicht sehen. Ein Homebrew-Cask-Eintrag hat überlebt, weil Sie die App in den Papierkorb gezogen haben, statt brew uninstall --cask auszuführen. Auf einem verwalteten Mac hat MDM sie zurückgeschickt. Oder die App-Store-Einstellung zum automatischen Laden von Apps, die Sie auf Ihren anderen Geräten gekauft haben, hat sie von einem zweiten Mac geholt.

Kann ich Apples integrierte Apps löschen, wenn ich SIP ausschalte?

Technisch ja, und es ist ein schlechter Tausch: eine maschinenweite Sicherheitsherabstufung aus dem Wiederherstellungsmodus, im Austausch für ein Bundle, das beim nächsten macOS-Update zurückkehrt, sobald das versiegelte Systemvolume ersetzt wird. Entfernen Sie die App stattdessen aus dem Dock und den Anmeldeobjekten.

Der Finder fragt beim Löschen einer App nach meinem Kennwort. Stimmt etwas nicht?

Nein. Ein .pkg-Installer hat das Bundle als Root dorthin gelegt, das Verschieben braucht deshalb eine Authentifizierung. Sorgen machen sollten Sie sich eher beim Gegenteil: keine Abfrage, kein Fehler, nichts passiert. Das ist meist die verweigerte App-Verwaltung unter Systemeinstellungen > Datenschutz & Sicherheit, und sudo behebt das nicht, weil das Tor am anfragenden Programm hängt und nicht am Benutzer.

Weiterführende Artikel

• Apps unter macOS vollständig deinstallieren für den normalen Ablauf und die Library-Ebenen, die er durchgeht.
• Antivirus unter macOS deinstallieren für Software mit Systemerweiterungen, bei der die Abbaureihenfolge die ganze Aufgabe ist.
• Autostart-Programme unter macOS deaktivieren für die launchd- und Anmeldeobjekt-Seite, sobald Ihnen nichts mehr im Weg steht.