Die Dateien, die zurückbleiben, wenn du eine Mac-App löschst
Wenn du eine Mac-App löschst, bleiben Caches, Container und Einstellungen zurück. So findest du die Reste und räumst sie sauber auf.
Weitere Guides dieser Art gibt es bisher nur auf Englisch. Alle Artikel ansehen
Windows hat eine Registry und eine Deinstallations-Konvention, die, wenn auch unvollkommen,
versucht, hinter sich aufzuräumen. macOS hat keins von beidem. Ziehst du eine App in den Papierkorb,
entfernst du genau eine Sache: das .app-Bundle. Alles andere, was sie je auf deine Festplatte
geschrieben hat — und eine typische App schreibt an fünf oder sechs verschiedene Orte — bleibt genau
dort, dauerhaft, es sei denn, du gehst es selbst suchen.
Wo eine App tatsächlich schreibt, jenseits ihres eigenen Bundles
Eine einzelne App kann Dateien an all diesen Orten hinterlassen, von denen keiner beim Löschen der App selbst angerührt wird:
~/Library/Application Support/<AppName> # Einstellungen, lokale Datenbanken, manchmal riesige Caches
~/Library/Caches/<bundle.id> # neu erstellbarer Cache — siehe den eigenen Guide unten
~/Library/Containers/<bundle.id> # sandboxed Apps bekommen hier ein vollständiges privates Dateisystem
~/Library/Preferences/<bundle.id>.plist # Einstellungen, winzig, summiert sich aber über Hunderte Apps
~/Library/Saved Application State/<bundle.id>.savedState # Fenster-/Tab-Wiederherstellungszustand
~/Library/Logs/<AppName> # Diagnoseprotokolle, manchmal Gigabyte bei geschwätzigen Apps
Nichts davon ist ein Bug oder Fehlverhalten einer App — das ist der dokumentierte, korrekte Ort für eine App, diese Daten abzulegen. Das Problem liegt komplett auf der Entfernungs-Seite: Nichts in macOS ist dafür zuständig, das aufzuräumen, wenn die App selbst verschwindet.
Herausfinden, was zu einer bereits gelöschten App gehört
Hast du die App bereits in den Papierkorb gezogen und fragst dich erst jetzt, was sie hinterlassen hat, ist ihre Bundle-Kennung der Schlüssel — alles oben ist darunter abgelegt, aber du hast die App nicht mehr, die dir sagen könnte, wie diese Kennung lautete.
# Spotlights Metadaten nach einer plausiblen Bundle-Kennung durchsuchen
mdfind "kMDItemCFBundleIdentifier == '*appname*'"
# Oder direkt nach dem App-Namen an den üblichen Überbleibsel-Orten suchen
find ~/Library/Application\ Support ~/Library/Caches ~/Library/Containers \
~/Library/Preferences ~/Library/Saved\ Application\ State ~/Library/Logs \
-iname "*appname*" -maxdepth 1 2>/dev/null
Bundle-Kennungen sind Reverse-DNS (com.company.AppName), daher fördert die Suche nach dem
Unternehmens- oder Produktnamen meist jeden relevanten Ordner zutage, selbst wenn die exakte Kennung
nicht offensichtlich ist.
Welche Überbleibsel es tatsächlich wert sind, gelöscht zu werden
Nicht jedes Überbleibsel lohnt die einzelne Jagd — eine .plist-Einstellungsdatei ist ein paar
Kilobyte, und für jede je entfernte App danach zu suchen, ist keine gute Nutzung eines Nachmittags.
Die wirklich beachtenswerten sind die großen:
~/Library/Containers/<bundle.id>— bei sandboxed Apps (die meisten modernen App-Store-Apps und viele weitere) ist das effektiv ein privates Dateisystem, über das die App volle Verfügung hatte. Videoeditoren, Design-Tools und alles, was große Mediendateien verarbeitet, hinterlassen regelmäßig mehrere Gigabyte große Container.~/Library/Application Support/<AppName>— hier liegt die tatsächliche lokale Datenbank einer App, falls vorhanden. Chat-Apps, Notiz-Apps und alles mit Offline-Cache legen hier häufig mehrere Gigabyte ab.~/Library/Logs/<AppName>— meist klein, aber eine kleine Zahl von Apps (Videokonferenz-Tools fallen hier wiederholt auf) protokolliert über die Zeit so ausführlich, dass ein Gigabyte oder mehr erreicht wird.
~/Library/Caches/<bundle.id> für eine gelöschte App ist unzweifelhaft sicher zu löschen — es ist
Cache für eine App, die nicht mehr existiert, um ihn zu nutzen, es gibt also überhaupt keine
Wiederaufbau-Kosten zu bedenken, anders als beim Leeren des Caches einer noch genutzten App.
# Sobald bestätigt ist, dass die App wirklich weg ist, und ihre Ordner identifiziert sind:
rm -rf ~/Library/Application\ Support/AppName
rm -rf ~/Library/Containers/com.company.AppName
rm -rf ~/Library/Caches/com.company.AppName
Das eine, was vor dem Löschen eines Containers zu prüfen lohnt
Der Container einer sandboxed App kann in seltenen Fällen die einzige Kopie von etwas enthalten, das du innerhalb dieser App erstellt und nie exportiert hast — manche Notiz-Apps und Zeichen-Apps speichern deine tatsächlichen Inhalte auf diese Weise statt in einem regulären Dokumente-Ordner. Bevor du bei einer App, bei der du unentschlossen bist, einen Container löschst, öffne die App noch einmal (falls du das noch kannst) und prüfe, ob etwas darin liegt, das du zuerst exportieren möchtest. Bist du sicher, ist das Löschen sofort und in dem Sinne unumkehrbar, dass es nichts zu regenerieren gibt — wie jede Dateilöschung, nur ohne eine App, die dich warnt.
Warum das im großen Maßstab schlimmer ist, als es klingt
Niemand deinstalliert eine App und macht sich Sorgen um 200 MB Überbleibsel. Die echten Kosten sind kumulativ: Ein Mac, auf dem über mehrere Jahre hundert Apps installiert und entfernt wurden — Testversionen, Einmal-Dienstprogramme, Apps, die du ausprobiert und nicht behalten hast — kann leicht 10–20 GB verwaister Daten von Software mit sich schleppen, die nicht einmal mehr auf der Maschine ist, unsichtbar, weil es kein Symbol im Finder gibt, das dich an ihre Existenz erinnert.
Die obigen Befehle sind kostenlos und funktionieren, nur langsamer bei hundert Apps als bei einer. DevCruft, eine kostenlose Mac-App für Entwickler, ist gerade in Entwicklung und soll genau diese Jagd automatisch übernehmen: jedes Überbleibsel einer nicht mehr installierten App finden und in einem Durchgang komplett zurückgewinnen. Auf der Warteliste erfährst du, wann es erscheint.
Für die Cache-Ordner, die noch genutzte Apps hinterlassen, siehe
den Guide zu ~/Library/Caches.