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. Attribuieren Sie Reste über die Bundle-Identifier, nie über Größe oder Namen, 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 (Delete or uninstall apps).

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 ist präzise und schlägt fast nie Daten einer Schwester-App vor. Es verpasst Ordner, die die App nach sich selbst benannt hat.

Name-Matching findet genau diese Ordner – und 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

Mole vereint Datenträgeranalyse, App-Pflege und Cleanup mit vorheriger Prüfung in einer nativen Mac-App. macOS und die jeweiligen Apps verwalten weiterhin Systemdaten.

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“, nachdem die App schon weg ist, ist eine veraltete Zuordnung, 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.

Weiterführende Lektüre

• Apple: Delete or uninstall apps on Mac
• 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?

Rebuildfähigen Zustand ja: Caches, Receipts und Standard-Preferences kommen beim ersten Start zurück. Dokumente, Chatverlauf und Lizenzen nicht – deshalb wählt ein sorgfältiges Werkzeug vorab nur aus, was eine Neuinstallation neu anlegen würde.