Eine Mac-App vollständig deinstallieren

Die drei Wege, eine Mac-App zu deinstallieren, und was jeder zurücklässt

In den Papierkorb ziehen. Eingebaut, kostenlos, und es entfernt das Bundle. Es entfernt nichts von dem, was die App außerhalb ihrer selbst geschrieben hat: Einstellungen, Caches, Container, gesicherte Fensterzustände, Launch Agents, Installationsquittungen und die Einträge unter Datenschutz & Sicherheit in den Systemeinstellungen. Für die letzten gibt es in macOS keinen Knopf. tccutil, das Werkzeug, das sie löscht, löst eine App über LaunchServices auf - sobald das Bundle im Papierkorb liegt, antwortet es "No such bundle identifier", und die erteilten Berechtigungen bleiben für immer in der Berechtigungsdatenbank stehen. Deshalb stehen Apps, die du letztes Jahr gelöscht hast, immer noch unter Bedienungshilfen.

Der Deinstaller des Herstellers. Wo es einen gibt - Adobe, Microsoft, die meisten VPN-Clients - ist er die richtige Antwort, denn der Hersteller weiß, wo er etwas abgelegt hat. Die meisten Apps liefern keinen mit.

Ein eigener Deinstaller. AppCleaner macht das seit Jahren kostenlos und reicht, wenn es dir um das Bundle plus die offensichtlichen Ordner in ~/Library geht; Pearcleaner ist die quelloffene Lesart derselben Aufgabe. Unroot ist um eine engere Frage herum gebaut: nicht, was wir finden können, sondern was wir beweisen und was wir zurücklegen können. Alles Folgende steckt in der ausgelieferten Version.

Wo es sucht, und warum jede Zeile ihren Grund nennt

Ein Scan liest 58 Orte. Die, die du erwarten würdest (Application Support, Preferences, Caches, Containers, Group Containers, Saved Application State), und die, die du nicht erwarten würdest: HTTPStorages, WebKit, Cookies, die benutzereigenen Bäume unter /var/folders, die Wurzeln der Audio-Plug-ins, QuickLook-Generatoren. Außerhalb deines Benutzerordners liest es /Library/LaunchDaemons, /Library/PrivilegedHelperTools, /var/db/receipts und /Users/Shared. Ein paar werden besonders gelesen: Application Support eine Ebene tiefer, weil Hersteller dort verschachteln und der verschachtelte Ordner vorgeschlagen gehört - niemals der Herstellerordner, der jedes Schwesterprodukt mitnehmen würde; Launch-Item-Plists wiederum über ihr Label und ihre ProgramArguments statt über den Dateinamen, weil Hersteller die Datei nach dem Daemon benennen.

Dann das Abgleichen, und hier gewinnt ein Deinstaller Vertrauen oder zerstört Daten. Eine exakte Bundle-ID ist sicher. Ebenso dieselbe ID als vollständiger punktgetrennter Abschnitt, womit com.vendor.app.helper erfasst wird; ebenso eine App-Gruppe, die die App in ihrer eigenen Codesignatur deklariert hat; und ebenso ein Pfad aus einer Installationsquittung, von der pkgutil beweisen kann, dass sie genau dieses Bundle installiert hat. Ein Namenstreffer ist bloß möglich und wird auch so eingestuft.

Was auf dieser Liste fehlt, ist der eigentliche Punkt. Regeln für das zweiteilige Herstellerpräfix und für das Signaturteam gab es beide, und beide wurden gelöscht: zusammen trafen sie in zwei echten Scans 45-mal zu, jedes Mal auf die Daten einer anderen App und kein einziges Mal auf einen echten Rest. Derselbe Entwickler ist nicht dieselbe App. Und die stärkste Regel greift zuletzt: Liegt eine Datei unter der Kennung einer anderen installierten App, gehört sie dieser App, Punkt. Jede Zeile zeigt außerdem den Grund ihres Treffers, und das ist der Unterschied zwischen einer Liste, der man vertraut, und einer, die man glauben muss.

Drei Stufen, und was von Anfang an angehakt ist

Funde werden als sicher zu entfernen, einen Blick wert oder heikel eingestuft, und diese Einstufung beantwortet genau eine Frage: Wie vorsichtig muss ich bei dieser Zeile sein. Sicher heißt umkehrbar, innerhalb deines Benutzerordners und zweifelsfrei der App gehörend. Einen Blick wert heißt nur über den Namen getroffen oder mit einer App geteilt, die du noch hast. Heikel sind Schlüsselbund-Einträge, privilegierte Hilfsprogramme, Systemerweiterungen und alles außerhalb deines Benutzerordners - die einzige Stufe, die den Fehler erzeugen kann, vor dem sich alle fürchten.

Der widersprüchliche Teil ist, was angehakt ankommt, denn es ist nicht die sichere Stufe. Eine Zeile ist angehakt, wenn der Treffer sicher ist, nicht wenn er umkehrbar ist. Beides zu vermengen machte das Produkt unehrlich: Die Lizenz einer App liegt im Schlüsselbund, diese Zeilen unangehakt zu lassen hieß also, dass die Standardentfernung die App stillschweigend aktiviert zurückließ. Eine heikle Schlüsselbund-Zeile ist angehakt; ein reiner Namenstreffer nicht.

Derselbe Bildschirm trägt den zweiten Modus. Zurücksetzen behält die App und entfernt alles, was sie gespeichert hat - alles außer den Installationsquittungen, denn wenn pkgutil ein noch installiertes Paket vergisst, geht dessen eigener Updater kaputt. Schlüsselbund-Einträge bleiben bewusst im Umfang: Eine App im Auslieferungszustand ist abgemeldet.

Nichts wird gelöscht

Entfernte Elemente wandern in einen einzigen datierten Ordner in deinem Papierkorb - Unroot - Spectacle - 2026-08-21 11-01-33 - jedes in seinem eigenen nummerierten Fach, damit com.vendor.app.plist aus ~/Library/Preferences die gleichnamige Datei aus /Library/Preferences nicht stillschweigend überschreibt.

Ein Ordner statt vierhundert loser Elemente ist halb Lesbarkeit und halb Machbarkeit: Finders "Zurücklegen" stellt von einem Stapel nur das erste Element wieder her, und es gibt keine öffentliche API, um programmatisch zurückzulegen - ein darauf gebauter Widerruf wäre ein Versprechen, das das System nicht halten kann. Neben den Dateien liegt unroot-manifest.json, eine schlichte Liste, woher jedes Element stammt. Genau die liest der Widerruf, und sie bleibt lesbar, selbst wenn Unroot weg ist.

Ein Teil einer Entfernung ist wirklich endgültig, und die Fußzeile zählt ihn in Rot. Ein Schlüsselbund-Eintrag ist keine Datei und lässt sich deshalb nicht in einen Ordner verschieben; ihn zu löschen meldet die App ab und nimmt eine dort gespeicherte Lizenz mit. Das Bestätigungsblatt zählt diese Einträge nicht, sondern benennt jeden einzeln, denn eine Zahl ist keine Zustimmung.

Ein Widerruf, der einen Absturz überlebt

Das Manifest kann nur festhalten, was nachweislich geklappt hat, also lässt es sich erst nach dem Lauf schreiben - und ein Absturz dazwischen würde verschobene Dateien ohne jede Notiz zurücklassen, woher sie kamen, also genau das Versprechen brechen, für das es existiert. Deshalb wird, bevor irgendetwas verschoben wird, ein Journal aller geplanten Einträge in denselben Ordner geschrieben, und ein abgeschlossener Lauf löscht es wieder. Ein Journal ohne Manifest ist damit die Signatur einer abgebrochenen Entfernung, und der nächste Start baut das Manifest daraus neu auf - er behält nur die Einträge, deren Dateien nachweislich in ihren Fächern liegen.

Der Widerruf ist dann ein rückwärts abgespieltes Protokoll. Sitzt am ursprünglichen Pfad inzwischen etwas anderes - du hast die App neu installiert - weicht die Wiederherstellung auf ein nummeriertes Geschwister aus, statt zu überschreiben, denn ein Widerruf darf nichts zerstören, um zu gelingen. Launch-Jobs werden nicht nur zurückgelegt, sondern neu gestartet: Die Plist zurückzulegen und den Daemon ausgehängt zu lassen, würde die Dateien wiederherstellen und das Verhalten stillschweigend nicht. Beide Richtungen laufen durch eine Regel, die annimmt, dass alles davor falsch entschieden hat: /System, die Schlüsselbund-Ordner, iCloud Drive und deine Ordner Dokumente, Schreibtisch, Downloads, Bilder, Filme und Musik können nie ein Endpunkt sein, egal was getroffen hat.

Der eine Schritt, den der Widerruf nicht zurückholt, ist das Zurücksetzen der Berechtigungen, und die App sagt das in der Zeile selbst statt in einer Fußnote: Berechtigungen werden zurückgesetzt, nicht wiederhergestellt. Jede App fragt beim nächsten Mal erneut.

Nichts davon verfällt. Jede Entfernung, die Unroot je gemacht hat, bleibt auf einem Bildschirm, zusammen mit dem Platz, den ihr Ordner belegt - eine Entfernung von vor zwei Monaten widerruft sich genauso wie die von vor zwei Minuten. Ob sie das noch kann, entscheidet ein Blick auf die Platte und keine Markierung, die damals gesetzt wurde.

Alles zu behalten heißt allerdings: ein Papierkorb voller Quarantäneordner. Ihn zu leeren ist die normale Antwort; wer wählerisch sein will, lässt Unroot einen einzelnen Ordner auf Anfrage löschen. Das ist die einzige Stelle in der App, die überhaupt etwas löscht, also ist sie eingezäunt: drei Prüfungen, dass der Pfad wirklich einer ihrer eigenen Ordner ist, und ein automatischer Durchlauf, der aus bleibt, bis du ihn einschaltest.

Die Berechtigungseinträge, die niemand von Hand löschen kann

Bevor du irgendetwas entfernst, liest Unroot die Berechtigungsdatenbank - nur lesend, mit demselben Festplattenvollzugriff, den es ohnehin für ~/Library braucht - und zeigt, was die App gehalten hat. Bedienungshilfen, Festplattenvollzugriff, Bildschirmaufnahme, Eingabeüberwachung, Automation und rund fünfundzwanzig weitere werden namentlich aufgelöst, insgesamt etwa dreißig Berechtigungsarten. Fast nichts sonst zeigt dir das, und es ist das überzeugendste Argument dafür, warum die Reihenfolge einer Entfernung zählt.

Denn sie zählt. Das Zurücksetzen muss laufen, solange das Bundle noch auf der Platte liegt, also wandert das Bundle zuletzt - nachdem die Launch-Jobs ausgehängt und die Schlüsselbund-Einträge gelöscht sind. Es zuerst zu entfernen ist der Fehler ohne Rückweg, und genau deshalb spuken so viele deinstallierte Apps noch in den Systemeinstellungen herum.

Danach liest der Bericht die Datenbank erneut, statt anzunehmen, die Werkzeuge hätten funktioniert. Es ist bekannt, dass macOS manche Zurücksetzungen des Festplattenvollzugriffs verweigert; also sagt der Bericht entweder, dass die Berechtigungen geprüft und leer sind, oder er benennt die überlebende und bittet dich, sie von Hand zu entfernen.

Laufende Apps kommen vor all dem an die Reihe. Jede wird zum Beenden aufgefordert, und weigert sie sich, bekommst du eine Entscheidung statt eines stillen Sofortbeendens: erzwingen, oder diese App überspringen und jede ihrer Dateien unberührt lassen.

Apps, die du vor Jahren gelöscht hast, und was von ihnen weiterläuft

Die andere Hälfte eines engen Abgleichs ist, dass Überreste längst verschwundener Apps nirgends mehr auftauchen können. Also bekommen sie ihren eigenen Suchlauf, und der ist bewusst vorsichtig. Er listet nur Dinge in Kennungsform - ein Name mit mindestens drei punktgetrennten Abschnitten und ohne Leerzeichen - denn ein Ordner, der nach einer Firma heißt, kann zu allem gehören, und Raten ist die Art, wie ein Deinstaller etwas löscht, das er nicht hätte anfassen dürfen.

Nur Caches und Logs kommen angehakt an. App-Daten und Einstellungen nicht, und der Bildschirm sagt auch warum: Ein Teil des Gelisteten ist Cache, den ein Framework innerhalb einer App geschrieben hat, die du noch benutzt, und von außen sieht das identisch aus. Diese Liste ist ein Ausgangspunkt, kein Urteil.

Eine übrig gebliebene Datei liegt still. Ein übrig gebliebener Launch-Agent nicht, und genau deshalb kann eine App, die du vor Jahren entfernt hast, immer noch ein Hintergrundobjekt in den Systemeinstellungen haben, das die Systemeinstellungen selbst nicht entfernen können. Also wird derselbe Gedanke auf launchd gerichtet: Ein Bildschirm listet alles, was ungefragt startet - Launch-Agents, Daemons und die Anmeldejobs, die Apps über SMAppService registrieren - und nennt zu jedem den Eigentümer.

Nur die, deren Programm fehlt, lassen sich in Menge auswählen, und diese Zurückhaltung ist der Entwurf. Ein Job wie com.docker.vmnetd teilt sich das Herstellerpräfix mit einer App, die du noch hast; ihn als verwandt statt als verwaist einzustufen existiert genau dafür, etwas Lebendiges von einer Liste fernzuhalten, über der "sicher zu entfernen" steht. Ein Job, der noch ein Programm zum Ausführen hat, ist nie verwaist, so verlassen sein Name auch aussieht.

Was sie bewusst nicht tut

Es braucht Festplattenvollzugriff, von Hand erteilt, denn macOS lässt einer App keinen Weg, ihn zu erfragen; ohne ihn läuft ein Scan trotzdem, deckt aber nur die Orte außerhalb deines Benutzerordners ab - und sagt das, statt eine kurze Liste als saubere durchgehen zu lassen. Etwas außerhalb des Benutzerordners zu entfernen fragt einmal nach deinem Administratorkennwort.

Manche Aufgaben lehnt es rundheraus ab: Apples eigene Software, sich selbst und Systemerweiterungen, für die es einen Abschnitt mit der Überschrift "Unroot kann diese nicht entfernen" gibt, samt der genauen Stelle, an der du es selbst tust.

Es sitzt nicht in deiner Menüleiste, und nichts wartet darauf, dass du eine App in den Papierkorb ziehst - Unroot scannt, wenn du es öffnest, und tut die übrige Zeit gar nichts. Das einzige ansässige Stück ist eine Finder-Erweiterung, und die bleibt aus, bis du sie in Systemeinstellungen -> Erweiterungen -> Finder einschaltest. Danach bietet ein Rechtsklick auf eine App an, sie zu deinstallieren. Wo das landet, ist wissenswert, denn macOS ist darin nicht konsequent: in ~/Applications ist es ein Eintrag oberster Ebene, der die App benennt, überall sonst - auch in /Applications, wo die meisten Apps liegen - sitzt es im Dienste-Untermenü, unter dem schlichteren "Uninstall with Unroot". Es entfernt von sich aus nichts. Es übergibt der App deine Auswahl, und dieselbe Prüfansicht öffnet sich.

Es ist auch kein Festplattenreiniger. Es sucht die Spuren einer App, die du benennst, und nicht nach Dingen, die du freiräumen könntest - und es kommt dem Konto eines anderen Benutzers nie nahe.

Eine Version im Mac App Store gibt es nicht, denn ~/Library zu lesen, Berechtigungseinträge zurückzusetzen und Dateien im Root-Besitz zu verschieben ist aus einer Sandbox heraus unmöglich.

Was sie kostet, und was sonst infrage kommt

Unroot braucht macOS 14 oder neuer, läuft auf Apple Silicon und Intel und belegt etwa 10 MB. Es ist zahle, was du willst mit einem Vorschlag von 4,99 Dollar - ein Betrag, der die Null ausdrücklich einschließt - und die Lizenz gilt so oder so dauerhaft. Die vollständigen Angaben stehen auf der Unroot-Seite.

Wenn es dir um Speicherplatz geht statt um eine bestimmte App, ist Sweep der Nachbar - es sortiert den Downloads-Ordner nach Regeln, die du schreibst, und wirft Installationsdateien weg, die älter als einen Monat sind; Funktion für Funktion beschrieben in Dateien auf dem Mac automatisch sortieren. Einen Überblick über den Rest gibt Mac-Dienstprogramme.