I’ve been using AppCleaner (https://freemacsoft.net/appcleaner/) for years now and it’s a real neat (and free) app that’ll do a pretty decent job of cleaning up crud.
This is just unbelievable. The billion $$ company cant just automate the uninstall procedure for their users? How hard would it be to auto delete the contents of ~/Library? Or have some periodic auto clean? one can always dream, no?
I wonder how many users that have uninstalled VMware still have 30 gigs of unused VMs lying around on their disk.
No. The user data, preferences etc under ~/Library/ belong to you - whether it's 3 kB of preference toggles or 3 decades of email.
It would be "unbelievable" if a multibillion company decided to be helpful and erase your data just because you deleted the binary that created them (actually, it wouldn't, but let's not digress into how those companies are stripping away our agency by mobile-ossifying everything).
The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.
Turns out your UNIX with a human face ate its children afterall. With relish.
Consider that sometimes people do actually want to clean up all artifacts of an installation, and don't want to go digging around in a bunch of machine-generated directories trying to guess what to delete.
I think I agree that the default behavior should be to leave all that data on the user's system. But I also think that apps should have some kind of associated file manifest, which you can use to automatically clean up after the app, or at minimum get a definitive list that you can go through manually or with a script.
It turns out that Apple installer packages do include a manifest (cutely called a BOM) of package contents, but users don't typically keep package installers around after completing installation successfully, and it says nothing about files that may be written by the app itself while in use.
I don't see how you could possibly claim that the user library "ruined" anything. Most apps need to save some kind of settings and/or transient data files. Where else would they go?
There are two scenarios I want the cleanup to happen: 1) app is buggy and I'm trying to fix it by reinstalling from scratch, 2) I need to free disk space. Both are pretty rare, and in the second case I am already using a specialized utility like DaisyDisk to see where my space has gone.
> transient data files
/tmp? That gets actually auto cleaned up!
> settings
Maybe. Do we want macOS to introduce the concept of uninstall to shave a few of those kilobytes? Hoping programmers do not screw up with rm -rf /? I already hate it when I have to use an installer so that's a no from me.
> 1) app is buggy and I'm trying to fix it by reinstalling from scratch
You don't specify and it's highly dependent but in most cases when an app is misbehaving it's an issue with preferences. You can reset most apps with `defaults` without blowing away all its data. There are some intricacies with how macOS handles preferences, so you should avoid manually editing related .plist.
> Note that if I am trying to fix an app that I want to keep using I sure as hell may want to keep the preferences.
Of course, `man defaults`. You can modify the preferences and potentially fix it, backup preferences, etc. Again I must stress that you use `defaults`, the .plist on disk isn't always accurate even if you terminate the app and reboot the machine.
> The case where I want it to auto clean up is where it is repeatedly broken and I never really got to using and configuring it yet. It's pretty rare.
There isn't really a one size fits all perfect automatic solution. Not all apps are good macOS citizens.
Thanks for demonstrating your lack of credibility.
Uninstallers by and large only do the reverse of what an installer did by going through the install log and undoing what it did.
This means any additional files made after the the installation that weren't properly appended to the log, any additional information added to the Registry that weren't properly appended to the log, and any user files created after installation (eg: save files) will not be touched by the uninstaller.
Should everything be properly logged for clean uninstalling? Yes; Linux package managers are a decent example. But reality is not ideal, so we have to deal with practicality. This presumably is the case whether it's Windows, Mac, or Linux.
The user-specific parts of the registry are powered by files in the user‘s profile and ACLs do not normally allow other users to have access, so the same issue applies there too
lots of them leave crud in HKLM/System and HKLM/Software, as well as I think HKey_Curent_Config
I dont mind the per user settings crud, I do mind the system wide crud, because it can make reinstating the app to resolve an issue fraught, and I have to go manually find whatever opaque keys were set and remove them.
> The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.
The Windows registry is a simple key-value store, just like the macOS defaults system. Windows installers/uninstallers may create/remove some registry entries, but those are typically entries for file associations and the installed program list, and perhaps some global settings. But then the app is free to write its configuration data to any registry key it likes (usually ones named after the app), or to files in ~\AppData, or perhaps C:\ProgramData. It’s not much different to macOS in that regard. The uninstaller may offer to remove the stuff in AppData, or it might keep it as-is.
(~\AppData is a bit less messy than ~/Library, because there are only three folders in AppData where application folders could go, but Library has all these folders with various meanings.)
I think on macOS programs are able to store data "inside" themselves, because .app files are just folders. They usually shouldn't put stuff in Library.
That's wrong, of course they should put stuff in the ~/Library if necessary. That's why if you update an app it just replaces the whole .app directory, and also if you uninstall something and then install it again all your settings will still be there.
> Also, "uninstallable" means "cannot be installed"
Nope. In writing, it's technically ambiguous -- it could mean both "can't be installed" or "can't be uninstalled" but to me it means "can't be uninstalled". In spoken language, it depends how you stress the first syllable and both could be used, I guess.
That's why if you want to denote the installability of something, you should use the nonambiguous installable-noninstallable pair and leave the word "uninstallable" for the "can't be uninstalled" meaning. AFAICT, whether you should spell it as "non-installable" or "noninstallable" (note the hyphen) is up to you.
Again, in my personal experience, uninstallable definitely means 2 in [1]: "uninstall-able". Pretty sure I never saw that word used as "un-installable".
> When I delete an app on an iPhone, all its data is also deleted. Gone. Why can't it be the same for the Mac?
Because on iPhone the app is completely sandboxed. Think Docker, with virtualised OS paths, but on OS level. When Apple tried to introduce a very light version of sandboxing, the world was ablaze in pitchforks and torches.
When I delete an app on an iPhone, all its data is also deleted. Gone.
Nope. Delete your Google apps. Reinstall one. It'll still pick up the accounts you used prior. Well, it used to anyways. It's not an iCloud keychain thing (or it wasn't).
There is an exception on iOS as well. Apps can register write access to a custom location on iCloud that will persist after the app has been deleted. You can see all the leftovers in Files.app
The helpful part would be for the huge company to give users visibility and an easy choice, not your simple "delete everything" strawman
The data doesn't "belong to me", that entirely depends on the specific app/type of data (and this concept of a few kbs of very important stuff I've carefully changed in the app's settings menu and would even like to track in vcs vs all the other junk is also largely missing, though that's also on the app devs)
In Ubuntu i can do apt remove to just uninstall the binary or i can apt purge to remove config files as well. Is there an native macOS equivalent for this?
The package manager will never attempt to clear stuff under user's home directories, just like macOS will not clear stuff under ~/Library. The package manager doesn't and cannot know what content an application has created while in use. Only the application itself knows that.
Flatpak applications under Linux get their little sandboxes under ~/.var/app/$application-id where they can create whatever they want and the user can remove it from there when needed. Except for that, any other path that the app can access is decleared in the permissions; or the user is very well aware, because he picked the file via filechooser (portal).
Soma macOS applications can use similar scheme, under ~/Library/Containers/$application-id, but for the user more difficult to know which one is supposed to and which isn't.
At least provide a user friendly way to manage it. For instance, offer the option to either delete, backup, or leave in place when uninstalling. For things left in place, have a GUI to view and manage them.
This isn’t something Windows or Linux does either. If you delete an application the user data is not touched.
For example on Windows if you grab a zip for an app and just put it in Program Files (or anywhere), run it then delete it there is nothing Windows does to clean up the files in AppData or entries in the registry.
Same on Linux if you grab a tar.gz, extract it to /opt and use it then delete it. All the data in ~/.config etc remains.
If the app developer providers an uninstaller it may clean up such data but that isn’t an OS feature.
There are many macOS apps that come with a pkg installer and uninstaller that cleans up in much the same way as an installer on Windows.
A little tip: if you use homebrew on macos you can use brew to force uninstall any application along with the zap argument and it will clean up most things. The app doesn’t have to have been installed via homebrew for this to work.
So if you wanted to remove Obsidian that you had manually installed using the dmg you could do `brew remove --cask --force --zap obsidian` and it will remove the Obsidian .app, plist, cache files in Application Support, etc.
You can also check the brew formula file which is just plain text to see exactly what it will remove during a zap which is quite handy.
You can also just run apps from anywhere - network drives, removable disks, disk images etc., so the system can’t just delete settings for apps it’s currently unaware of.
Yeah I think the real problem is that deleting an app isn't uninstalling (which is sometimes a feature not a bug), but Apple provides no paradigm for actually uninstalling that deletes preferences too.
Unfortunately, they don’t. There are many apps which after uninstalling, and reinstalling them weeks later, prompt you with: “Hello David, welcome back”, etc. I need to login again etc. (cache was cleared) but my settings are still there.
This happens even when deleting the app from ALL devices connected to my AppleID.
On iOS the Documents and Library folders exist per application in a sandbox, so those can be deleted with the app binary. Preferences like location permissions are reset too. But some things persist, like the app's related keychain data, which might contain a user session. Apps have the choice of where they store things and therefore what behavior to give users in a delete and reinstall scenario.
Of course any files saved in iCloud Drive or "On my iPhone" stay put, which users would expect.
I think the value of retaining the keychain is related to 1. automatically deleting least recently used apps and restoring them when a user goes to launch them, and 2. restoring from encrypted backups, in which the downloaded apps are not backed up themselves, slowly install after the restore completes, and find the keychain data waiting for them.
If I recall, not all methods of backup include the keychain, which I think was the difference between having to sign into every app again or just a few due to a new device's Secure Enclave. These days if you get a new device you'll have a much better time with the phone-to-phone migration assistant then a backup and restore.
> "But some things persist, like the app's related keychain data, which might contain a user session."
this is also functioning as a "super cookie". Once you've installed a Google app, Google will always know it's you. Even when reinstalling/using another account.
Apple should provide a mechanism to clear these items too, and prevent tracking users.
That's also Apple's fault isn't it? App data should fall into an predictable folder regardless of the location from where is ran, if for whatever reason the app needs to use a different folder it should be something developers have to go to multiple hurdles to implement (e.g. specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash)
> App data should fall into an predictable folder regardless of the location from where is ran
In fact, App Store apps are guaranteed to do that (by being in a closed sandbox); that's why Apple has an uninstallation procedure only for App Store apps.
> specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash
macOS tries to do that, and developers cry that macOS is becoming more and more closed. In fact, macOS already disallows all apps (including non-sandboxed apps) touching ~/Documents and ~/Downloads except for specific exceptions that the user grants.
Yeah the way they're doing this is a bit of a pain in the ass to be honest. Set up a new Mac and you have to do though tons of these popups. It causes popup fatigue and users start just clicking yes without even reading it. I've seen it many times. It defeats the purpose this way.
I don't know what a better solution would be but I don't think this is it. And the documents and downloads folders are pretty arbitrary on Mac. Any user created folders don't get this protection.
I do love the way that sandboxed apps only store stuff in one folder in the ~/Library/Containers folder though. Even non-MAS apps that are sandboxed have to do that.
In fact the trick in this article doesn't even mention this, if you use it with a non-sandboxed app you're not guaranteed to uninstall everything for sure using this method.
Nonsense, is obvious that an smart artificial throat will be the final solution to this problem, it will use AI and lasers to dispose atoms of pork and non-kosher food before it reaches your stomach, automating God's will just like he intended.
To be fair, the situation isn't much better on Windows or Linux. While at least they have a concept of uninstalling an application, you're still reliant on the developer actually getting it right and not missing some tempfile or something.
The filesystem doesn’t have rich enough metadata about temporary files. At least Windows has a file attribute for temporary files (FILE_ATTRIBUTE_TEMPORARY), although I’m uncertain how many apps actually set it on their temporary files; Linux/Unix/etc appears to have no real equivalent. I think ideally temporary files would have rich metadata - the ID of the process, session, and application/package which created them, and some kind of retention policy and expiry date. Of course, one could always use xattrs for that, but unless they are standardised few would use them. C library functions such as mkstemp/mkdtemp/etc could be enhanced to set metadata on temporary files. The OS package manager (apt/rpm/etc) could put an xattr on an executable with the UUID of the package, and then mkstemp could copy that to an xattr of all temporary files. Now if the FS also indexed xattrs, we could upon uninstall find all temp files owned by a given package and remove them.
Many mainframe/minicomputer file systems support file expiry dates, which is an interesting feature which Unix missed.
It's by design. The files are your preferences, not the application's preferences. A lot of people throw away the old app bundle when they download a new version of it for applications that don't update themselves. It would be an infuriating user experience and absolutely absurd design choice if dropping the bundle in the trash also erased the users' preferences.
~/Library contains stuff for lots of apps and they don't necessarily have to be in a folder with the name of the same bundle ID. Only sandboxed apps are much more strict about this.
The OS also doesn’t know when you uninstall an app whether the app is really gone. You could have copied it to a network drive first, or maybe you have a different version of the app in a folder somewhere. Who knows?
Apps that install persistent services typically check if the .app bundle exists in applications so in most cases just trashing the .app is enough to stop any errant left overs from executing.
No desktop OS has uninstall procedures. Both Windows and Linux software packages often will leave trash files scattered around as well.
The only sane way to use desktop OS that I've found is to reinstall everything every 6-12 months and having some backup procedures to speed up configuration process.
Well, if it's a really modern application it will leave everything in only one folder in ~/Library/Containers as part of the sandbox. Besides the obvious security advantages of the sandbox this makes cleanup a lot easier too.
What I normally do is use finder to search for system files and delete them also along with the .app . You have to add system files to the search manually though.
When you search there is a + next to save in finder, click that, have name and matcha, + another option, choose other and scroll down to System Files, then set to are included.
Homebrew Cask can remove application-generated files if you pass the --zap option to "brew rm". Cask definitions include a list of known paths to those.
I wholly disagree with rogueamoeba's assessment that these were "style over substance". They were dead-simple to use, and you could always disable the smoke if you hated fun. They may not have all the bells and whistles of the bloated 40MB disc burning suite, but if all you wanted to do was burn a linux iso or transfer some songs to stick in your car stereo, this was the go-to tool for the job.
The delicious era … it was nice to “be there”, but honestly, I always felt like it was too much glossy. And I usually missed some feature there and felt back to the “boring” apps.
And I mean, Delicious Library… it looks good, but… why would I scan everything I have, to look at it on my Mac? What’s the point. I never understood it even back then.
But yeah, GUIs from that era were amazing, and then moved to iOS in the first iterations, with all the skeuomorphism. It all died with the move to the new flat designs I guess.
Today Mac apps are just mostly Electron/swiftui and boring.
Haha that's almost exactly the reaction I had about two weeks ago. "What is everybody talking about?" But then I tried it and yep, I think it's a bit better overall, while there are a couple of little things I'd say I sometimes miss.
The good thing is they're not mutually exclisive, so I've been running both and seeing which one I reach for.
This is complete bullshit. Alfred 5.0 was released in July last year and the last update 5.0.6 was in December. Packal is online and a couple of packages were updated 1 week 6 days ago. And not only that, but to replicate most of Alfred's functionality in Raycast, you have to rely on plugins and hope they are both secure and maintained by somebody whereas Alfred's functionality is maintained by the Alfred team. Stop spreading misinformation.
Different user, but I too “remember” first quicksilver and then Alfred shutter. Did I hallucinate that, or did it happen and later have a revival, or what?
I’ve been using AppCleaner (https://freemacsoft.net/appcleaner/) for years now and it’s a real neat (and free) app that’ll do a pretty decent job of cleaning up crud.