Reste nach dem Deinstallieren von Mac-Apps entfernen

Richten Sie zwei Restscanner auf dieselbe deinstallierte App, und Sie erhalten zwei Listen. Das ist kein Fehler. Jedes Werkzeug wählt seine eigene Regel für die Zugehörigkeit, seine eigene Ablehnungsliste und seine eigene Grenze für Administratorarbeit. Diese drei Entscheidungen bestimmen alles auf dem Bildschirm. Sobald Sie Attribution verstehen, hört die Restbereinigung auf, „wer findet mehr Müll“ zu sein, und wird zu „wessen Fehler weniger schaden“.

Dieser Leitfaden behandelt den Zustand danach: Die App ist bereits weg, oder sie liegt gerade im Papierkorb, und Sie möchten Reste mit derselben Sorgfalt prüfen, die ein Deinstaller hätte aufbringen sollen. Für den vollständigen Ablauf, während die App noch läuft, siehe vollständige Deinstallation. Für Produktentscheidungen siehe jenseits von AppCleaner.

Kurzantwort: Wenn Sie eine App in den Papierkorb ziehen, wird nur das Bundle entfernt; die Daten bleiben unter ~/Library in Application Support, Caches, Preferences und Containers. Ordnen Sie Reste anhand der Bundle-ID zu, nicht allein anhand der Größe oder des Namens, und prüfen Sie jeden Kandidaten vor dem Löschen, oder nutzen Sie einen Deinstaller, der genau das durchsetzt.

Was „Deinstallieren“ auf macOS wirklich bedeutet

macOS behandelt eine Anwendung nicht als ein Objekt mit einer Löschtaste. Es gibt mindestens drei Ebenen:

In den Papierkorb ziehen garantiert nur die erste Ebene. Die mittlere Ebene ist der Bereich, in dem generische Werkzeuge helfen. Die dritte Ebene ist der Bereich, in dem sie oft so tun und scheitern: Treiber, Netzwerkerweiterungen, privilegierte Helpers, Lizenzierungs-Daemons. Apple empfiehlt aus diesem Grund weiterhin, eine Vendor-Uninstall-App zu bevorzugen (Apple-Anleitung zum Deinstallieren).

Wo Benutzerreste tatsächlich liegen

Die meisten Drittanbieter-Reste sammeln sich unter der Home-Library:

Systempfade unter /Library (LaunchDaemons, PrivilegedHelperTools, Receipts unter /private/var/db/receipts) gehören zu einer höheren Risikostufe. Bevorzugen Sie den Vendor-Remover; behandeln Sie generische Scanner dort nur als Prüfliste.

Eine sandboxed App wirkt oft aufgeräumt: primärer Container unter ~/Library/Containers/<bundle id>. Sie kann trotzdem App Groups, Application Scripts, geteilte Caches, CloudKit oder Keychain-Einträge nutzen. Sandboxing schränkt den direkten Dateizugriff ein; es garantiert keinen Ein-Verzeichnis-Fußabdruck. Eine nicht sandboxed App kann sich über Application Support, Caches, Preferences, Logs, Saved Application State, WebKit und Cookies verteilen. Je breiter die Streuung, desto mehr Raum für Uneinigkeit zwischen zwei Werkzeugen.

Attribution ist die eigentliche Fähigkeit

Sichere Resterkennung basiert auf Identität, nicht auf Marketingnamen.

Bundle-Identifier gegenüber Anzeigename

com.example.widget bleibt stabil über Umbenennungen und Lokalisierungen hinweg. Anzeigenamen nicht. Zwei Produkte können denselben Firmenordner teilen (…/Application Support/Google), während nur eines deinstalliert ist. „Google“ als Zeichenkette zu matchen ist der Weg, auf dem Scanner mehrgigabyte große Fehltreffer erfinden.

Identifier-Matching grenzt die Suche ein. Geteilte Daten müssen trotzdem geprüft werden. Ordner, die nur den App-Namen tragen, können dabei übersehen werden.

Name-Matching findet genau diese Ordner, aber auch Dinge, die nur ein Wort teilen. Es findet mehr und liegt häufiger falsch.

Praktische Prüfungen vor jedem Löschen:

mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null

Wenn noch etwas mit dieser ID existiert, behandeln Sie geteilte Support-Pfade als live.

Helpers und eingebettete Identitäten

Moderne Apps liefern Helpers mit verwandten IDs: com.example.widget.helper, Namen aus SMPrivilegedExecutables, Login-Items unter Contents/Library/LoginItems. Ein gründlicher Scanner sammelt diese IDs aus dem Bundle bevor die App verschwindet. Ist das Bundle weg, haben Sie nur noch das, was aufgezeichnet wurde, oder was noch unter exakten Namen auf dem Datenträger liegt.

Group Containers

~/Library/Group Containers/ hält absichtlich geteilte Suite-Daten:

• group.<bundle id>
• teambezogene Namen wie <TeamID>.<bundle id>
• geteilte group.*-Räume, die mehrere Apps nutzen

Nur exakt eigentümerbezogene Pfade sind Kandidaten für automatische Zuordnung. Geteilte Gruppenbäume sollten prüfpflichtig bleiben oder unberührt, solange noch eine Schwester-App vorhanden ist. Hier verursachen Werkzeuge mit dem Anspruch „mehr gefunden“ echten Schaden.

Namensvarianten und Channel-Builds

Foo Beta kann Foo Beta, FooBeta und manchmal einen stabilen Foo-Ordner hinterlassen, der zum noch installierten Release-Channel gehört. Channel-bereinigte Basisnamen sind hohes Fehltreffer-Risiko: behalten Sie sie prüfpflichtig, bis Sie belegen, dass die stabile App weg ist.

Drei sichere Einstiegspunkte

1. Zuerst Vendor-Deinstaller

Sicherheitsagenten, VPN-Clients, Audio-Treiber und Endpoint-Tools kennen ihre eigenen Receipts und die Reihenfolge beim Abbau von Extensions. Führen Sie diese aus, bevor Sie die Library durchsuchen. Dateilöschung ist kein zuverlässiger Deaktivierungsablauf für System- oder Netzwerkerweiterungen; macOS registriert sie.

2. Prüfen, wenn die App bereits weg ist

Wenn die .app weg ist, suchen Sie nach Pfaden, die noch mit dieser Bundle-ID oder exakten Namensvarianten markiert sind. Konservative Defaults:

• Oft in Ordnung, wenn zugeordnet: Caches, Logs, Saved State, Crash-Reports
• Sorgfältig prüfen: Application Support, Containers, Preferences (Lizenzen, Offline-Mail, Projekt-DBs)
• Meist liegen lassen: Group Containers ohne exakte Eigentümerschaft, Documents außerhalb der Library, alles, was eine andere ID noch braucht

Kandidaten messen:

du -sh ~/Library/Application\ Support/<Name> \
  ~/Library/Caches/<bundle.id> \
  ~/Library/Containers/<bundle.id> 2>/dev/null

Berechtigungsfehler bedeuten in der Regel, dass Terminal keinen Full Disk Access hat, nicht dass der Ordner leer ist.

3. Der Moment, in dem die App im Papierkorb landet

Viele legen zuerst ab und denken später. Ein Watcher, der eine neue .app in ~/.Trash bemerkt, die Identität aus Info.plist liest, verwandte Support-Dateien scannt und ein Prüffenster öffnet, fängt Reste ein, ohne dass Sie lange suchen müssen. Design-Grenzen, die Hilfreiches von Schädlichem trennen:

• Nie das abgelegte App-Bundle automatisch löschen (Zurücklegen muss funktionieren)
• Nie für geschützte / AV- / MDM-Klassen poppen
• Einmalige Unterdrückung verbrauchen, wenn der Cleaner selbst die App während der Deinstallation abgelegt hat, sonst rennen Panel und Deinstallationsablauf um die Wette
• An Full Disk Access koppeln; ohne Zugriff still scheitern statt aus dem Hintergrund nachzufragen

Der Restscan von Mole zieht zuerst Pfade ab, die installierte Apps, Bundle-IDs oder Receipts weiterhin beanspruchen, und lässt unklare Kandidaten abgewählt. Er zeigt Identität und Größe und verschiebt wiederherstellbare Löschungen in den Papierkorb; groß in der Library ist nie Begründung genug.

Orphans sind nicht „alles Große in der Library“

Reste von Apps, die Sie vergessen haben, erfordern Claim-Subtraktion: Kandidaten- Supportordner auflisten, dann alles abziehen, was noch von installierter Software beansprucht wird (Bundle-IDs, laufende Apps, Launch-Services-Registrierung, Vendor- Roots). Ist der Claim-Scan unvollständig (Timeout, unlesbare Verzeichnisse), ist das sichere Ergebnis null Orphans, keine ratende Liste. Werkzeuge, die auf einem sauberen Mac immer Dutzende „Müll“-Apps finden, optimieren eine Verkaufszahl.

Quiet-Period-Gates zählen ebenfalls: Eine letzte Woche umgeschriebene Config kann zu einem CLI-Tool gehören, das der Claim-Walk nicht sieht. Frische mtimes sollten Kandidaten unterdrücken.

Praxisbeispiel: zwei Werkzeuge, eine Vendor-Suite

Sie deinstallieren Produkt A einer Firma, die auch Produkt B liefert, das noch installiert ist.

• Werkzeug 1 (identifier-lastig): kleine Liste, vor allem com.vendor.productA.*-Pfade.
• Werkzeug 2 (name-lastig): fügt ~/Library/Application Support/Vendor (4 GB) und einen Group Container hinzu, den beide Produkte nutzen.

Werkzeug 2 wirkt gründlicher. Es schlägt die Löschung vor, die Produkt B kaputtmachen kann. Die Summe am unteren Bildschirmrand ist kein Qualitätswert. Die Kategorien darüber sind es.

Homebrew: verwaiste Receipt

Kam die App aus Homebrew Cask, kann das Entfernen nur der .app einen Caskroom-Eintrag hinterlassen, der die Neuinstallation blockiert. Nach Dateiresten:

brew list --cask

Bleibt der Token, räumt brew uninstall --cask <token> die Zuordnung ab (--zap nur akzeptieren, wenn Sie die breitere brew-eigene Bereinigung wollen). „Cask is not installed“ bedeutet, dass dieser Cask in der abgefragten Homebrew-Installation nicht registriert ist, und ist kein Grund für rm -rf auf beliebige Caskroom-Pfade.

Was Sie ablehnen sollten, auch wenn der Name passt

• Noch installierte Schwester-Apps und Channel-Zwillinge
• Geteilte Group Containers und Vendor-Elternordner
• Receipts und privilegierte Helpers ohne validierten Remover
• Benutzerdokumente außerhalb der Library
• AI-Chat-Speicher und Modellverzeichnisse, die neben Cache-Pfaden sitzen (AI-Bereinigung)

Häufige Fehler

Die Trefferliste maximieren. Mehr Kandidaten bedeuten oft schlechtere Attribution.

Group Containers standardmäßig löschen. Absichtlich geteilt.

Den Vendor-Deinstaller überspringen bei VPN, AV, Audio, Virtualisierung.

Ohne Full Disk Access messen und dann schließen „nichts übrig“.

Den Papierkorb sofort leeren nach einer Massenlöschung von Resten. Lassen Sie einen Tag normalen Gebrauch zu, falls etwas Wichtiges falsch attribuiert wurde.

Prüfen

1. Entfernte Pfade erneut messen.
2. Bestätigen, dass kein Login-Item und kein Launch Agent für diese ID bleibt (Startobjekte).
3. Schwester-Apps desselben Vendors starten.
4. Papierkorb erst leeren, wenn Sie die Entfernungen akzeptieren.

Reihenfolge der Schritte

1. Suchen Sie einen Vendor-Deinstaller, wenn die App Treiber, Extensions oder Helpers hatte.
2. Exportieren oder deautorisieren, solange die App noch läuft, falls das relevant ist.
3. App und sichtbare Helpers beenden.
4. Bundle entfernen (oder bestätigen, dass es bereits im Papierkorb liegt).
5. Reste nach Identität prüfen; geteilte Container unberührt lassen.
6. Homebrew-Cask-Receipts handhaben, falls zutreffend.
7. Einträge im Papierkorb behalten, während Sie den Mac normal nutzen, dann leeren.

Der erste Tag nach einer Deinstallation

Die meisten leeren den Papierkorb in dem Moment, in dem die App weg ist. Ein langsamerer Ablauf kostet nichts und lässt einen Weg zurück:

1. Legen Sie am ersten Tag nur das App-Bundle und die Caches in den Papierkorb, von denen Sie bestätigt haben, dass sie neu entstehen.
2. Lassen Sie Application Support und Containers liegen und nutzen Sie den Mac einen Tag lang normal.
3. Wenn Geschwister-Apps und die anderen Produkte des Herstellers weiterhin sauber starten, prüfen Sie die zweite Gruppe auf persönliche Daten und Sicherungen, bevor Sie sie entfernen.
4. Bei Pfaden, die Sie noch nicht einschätzen können, notieren Sie die Größe mit du -sh und entscheiden Sie eine Woche später.

Der Papierkorb liegt auf demselben Volume, es wird also nichts frei, bevor Sie ihn leeren. Was das Warten Ihnen bringt, ist ein Zeitfenster zum Wiederherstellen. Wenn die Platte wirklich voll ist, leeren Sie zuerst die neu erzeugbaren Caches für etwas Luft und heben Sie die strittigen Pfade auf.

Berechtigungen und Sichtbarkeit

Ohne Full Disk Access sehen Terminal und die meisten Scanner nicht in Containers und in Teile der Library hinein. du gibt Berechtigungsfehler aus, kommt trotzdem zu einer Summe, und dieser Summe fehlt alles, was der Befehl nicht öffnen konnte. Das liest sich nicht als „es ist nichts übrig“, sondern als „Sie dürfen nicht nachsehen“.

• Geben Sie Terminal oder dem Werkzeug, das den Scan ausführt, Full Disk Access und messen Sie erneut.
• Vergleichen Sie die Zahlen davor und danach. Aus dem halbblinden Durchlauf zu entscheiden ist der Weg, auf dem ein mehrere Gigabyte großer Container als leer gilt.
• Nehmen Sie Full Disk Access den Werkzeugen wieder weg, die Sie nicht mehr benutzen. Es ist die weiteste Leseberechtigung auf dem Mac, und einmal erteilt, überlebt sie ihren Anlass.

Wie sich dieser Leitfaden zur vollständigen Deinstallation verhält

Vollständige Deinstallation beschreibt die Reihenfolge, solange die App noch installiert ist: zuerst der Deinstaller des Herstellers, Export oder Deautorisierung, beenden, Bundle entfernen, dann prüfen, was übrig bleibt. Dieser Leitfaden setzt voraus, dass das Bundle bereits weg ist, womit die einfachen Belege fehlen, und verwendet seine Länge auf die verbleibende Hälfte: zu entscheiden, welche Dateien der App gehörten und welche sie nur mitbenutzt hat.

Weiterführende Lektüre

• Apple: Apps auf dem Mac löschen oder deinstallieren
• Verwandt: vollständige Deinstallation, AppCleaner-Alternativen, was Cleaner nie löschen sollten

Restbereinigung ist Identitäts-Pflege. Die Fähigkeit ist nicht, Gigabytes zu maximieren; sie besteht darin, Eigentümerschaft zu beweisen, geteilten Zustand zu schützen und Löschungen wiederherstellbar zu halten.

Häufige Fragen

Ist es sicher, Restdateien unter ~/Library selbst zu löschen?

Nur mit Attribution: Ordnen Sie den Ordner der Bundle-Identifier der App zu, nicht ihrer Größe oder einem ähnlich klingenden Namen, und prüfen Sie jeden Eintrag, bevor er weggeht. Eine falsche Vermutung kann Daten einer anderen App oder Ihre eigenen Dokumente mitnehmen.

Warum hinterlassen Apps überhaupt Dateien?

macOS hat keinen Deinstallationsvertrag: Die App in den Papierkorb zu ziehen ist der gesamte Mechanismus, und alles, was die App zur Laufzeit geschrieben hat, bleibt dort, wo es geschrieben wurde.

Stellt eine Neuinstallation wieder her, was ich gelöscht habe?

Die Installation oder die App kann Caches und Standardeinstellungen neu erzeugen. Das stellt persönliche Dokumente, Chatverläufe oder den früheren Lizenzzustand nicht wieder her. Eine Neuinstallation ersetzt keine Sicherung.