# Reste nach dem Deinstallieren von Mac-Apps entfernen > Library-Reste über Bundle-Identität zuordnen, geteilte Herstellerdaten schützen und Überreste nach dem Papierkorb oder einer längst entfernten Installation prüfen. Published: 2026-07-29 | Updated: 2026-09-25 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](https://mole.fit/de/blog/how-to-completely-uninstall-apps-on-mac). Für Produktentscheidungen siehe [jenseits von AppCleaner](https://mole.fit/de/blog/appcleaner-alternative). **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: | Ebene | Typischer Ort | Wer sollte sie entfernen | |---|---|---| | App-Bundle | `/Applications`, `~/Applications`, Setapp usw. | Sie, Papierkorb oder Paketmanager | | Benutzerunterstützung | `~/Library/…` | Restscanner oder sorgfältige manuelle Prüfung | | System / privilegiert | `/Library`, Helpers, Receipts, Extensions | **Zuerst den Vendor-Deinstaller** | 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](https://support.apple.com/102610)).
App-Bundle, Support-Dateien in der Benutzer-Library und systemweite Helfer als drei Schichten
Das App-Bundle zu entfernen ist nur die oberste Ebene. Reste in der Benutzer-Library und System-Helpers sind getrennte Entscheidungen mit unterschiedlichem Risiko.
## Wo Benutzerreste tatsächlich liegen Die meisten Drittanbieter-Reste sammeln sich unter der Home-Library: | Bereich | Was es in der Regel ist | |---|---| | `Application Support/` | Datenbanken, Offline-Pakete, Projektzustand | | `Caches/` | Regenerierbarer Cache | | `Containers/` und `Group Containers/` | Sandbox-Homes und geteilte Gruppen | | `Preferences/` (+ ByHost) | Einstellungs-plists | | `Logs/`, DiagnosticReports | Diagnosedaten | | `Saved Application State/` | Fensterwiederherstellung | | `HTTPStorages/`, WebKit, Cookies | Netzwerkzustand für diese Identität | | `LaunchAgents/` | Benutzer-Login-Helpers mit plist | | `Application Scripts/` | Sandbox-Skriptpakete | 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/`. 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.
Bundle-Identifier-Abgleich findet exakt besessene Pfade; Anzeigename-Abgleich findet mehr Kandidaten und mehr Fehltreffer
Identitäts-Matching ist enger und sicherer. Name-Matching findet mehr Reste und liegt häufiger falsch, wenn zwei Produkte einen Vendor-Ordner teilen.
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.` - teambezogene Namen wie `.` - 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.
Bundle-Identität fließt in Restkandidaten, während geteilte Herstellerordner geschützt bleiben
Attribution sollte der Bundle-Identität in eigene Pfade folgen, nicht vendorweiten Ordnern, die andere Apps noch brauchen.
## 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/ \ ~/Library/Caches/ \ ~/Library/Containers/ 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](https://mole.fit/de/mac-app-uninstaller) 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 ` 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](https://mole.fit/de/blog/how-to-remove-ai-tool-leftovers-mac)) ## 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](https://mole.fit/de/blog/how-to-disable-startup-programs-on-mac)). 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](https://mole.fit/de/blog/how-to-completely-uninstall-apps-on-mac) 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](https://support.apple.com/102610) - Verwandt: [vollständige Deinstallation](https://mole.fit/de/blog/how-to-completely-uninstall-apps-on-mac), [AppCleaner-Alternativen](https://mole.fit/de/blog/appcleaner-alternative), [was Cleaner nie löschen sollten](https://mole.fit/de/blog/what-mac-cleaners-should-never-delete) 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. --- Canonical HTML page: https://mole.fit/de/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps Blog index for agents: https://mole.fit/de/blog/llms.txt Site index for agents: https://mole.fit/llms.txt