Mac un-installs

Monday 7 November 2016This is over six years old. Be careful.

The Mac is a nice machine and operating system, but there’s one part of the experience I don’t understand: software installation and uninstallation. I’m sure the App Store is meant to solve some of this, but the current situation is oddly manual.

Usually when I install applications on the Mac, I get a .dmg file, I open it, and there’s something to copy to the Applications folder. Often, the .dmg window that opens has a cute graphic as a background, to encourage me to drag the application to the folder.

Proponents of this say, “it’s so simple! The whole app is just a folder, so you can just drag it to Applications, and you’re done. When you don’t want the application any more, you just drag the application to the Trash.”

This is not true. Applications may start self-contained in a folder, but they write data to other places on the disk. Those places are orphaned when you discard the application. Why is there no uninstaller to clean up those things?

As an example, I was cleaning up my disk this morning. Grand Perspective helped me find some big stuff I didn’t need. One thing it pointed out to me was in a Caches folder. I wondered how much stuff was in folders called Caches:

$ sudo find / -type d -name '*Cache*' -exec du -sk {} \; -prune 2>&-

(Find every directory with ‘Cache’ in its name, show its disk usage in Kb, and don’t show any errors along the way.) This found all sorts of interesting things, including folders from applications I had long ago uninstalled.

Now I could search for other directories belonging to these long-gone applications. For example:

$ sudo find / -type d -name '*TweetDeck*' -exec du -sh {} \; -prune 2>&-

 12K    /Users/ned/Library/Application Support/Fluid/FluidApps/TweetDeck
 84K    /Users/ned/Library/Caches/com.fluidapp.FluidApp.TweetDeck
 26M    /Users/ned/Library/Containers/com.twitter.TweetDeck
1.7M    /Users/ned/Library/Saved Application State/com.fluidapp.FluidApp.TweetDeck.savedState
$ sudo find / -type d -name '*twitter-mac*' -exec du -sh {} \; -prune 2>&-
288K    /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp/C/com.twitter.twitter-mac
 99M    /Users/ned/Library/Containers/com.twitter.twitter-mac
4.0K    /Users/ned/Library/Group Containers/

That’s about 128Mb of junk left behind by two applications I no longer have. In the scheme of things, 128Mb isn’t that much, but it’s a lot more disk space than I want to devote to applications I’ve discarded. And what about other apps I tried and removed? Why leave this? Am I missing something that should have handled this for me?

» 9 reactions


I've used AppZapper and have found it quite useful:
As a Linux user spoiled by apt-get and dnf (previously yum), the lack of proper package management on OS X drives me nuts. But Linux distro package management doesn't actually solve the problem you mention either. I don't think I've ever seen a package uninstaller that cleans up runtime-generated cache from user homes.

Some files you don't want to clean up, for example configuration. What if you were just uninstalling on the way to installing a new version, and poof there goes your vimrc? Not what you want. But caches are a different story.

I looked around the filesystem hierarchy standard to see if there's anything where packages get a designated area in (for example) /var to put per-user files. The only one that jumps out is /var/mail. A program might put a shared cache in /var/cache but per-user caches aren't mentioned, and using homedirs is a lot safer from a security standpoint.

By the way, you might rather use 2>/dev/null than 2>&-. There are a couple problems with closing stderr:

(1) the program might terminate early because it can't output stderr (but you don't know because it can't give you an error message)
$ cat
import sys
content = open('/usr/share/dict/words').read()

$ python3 2>/dev/null

$ echo $?

$ python3 2>&-

$ echo $?
(2) the program might open a file, get FD 2, and then try to write to stderr and accidentally write to the file. This doesn't demonstrate with Python because Python's open() skips FD 2 even if it's available. But not everything is Python. ;-)
I HOPE the program engineering teams chose to keep that data outside the .app folder to ensure it was there through an uninstall and reinstall.

What you should delete or keep after an uninstall is one of those unsolvable problems since we don't have "why are you uninstalling" the result is a compromise of things we want to delete since they are no longer needed and things that would be nice to not have to reconfigure if you install again.

It's almost like what car settings do you lose when the battery is flat? What's okay and what is annoying.
I think this is typically addressed by some programs by including an uninstaller. However, I erase disk and reinstall way too often to care:
It was just decided that 128Mb is a small price to pay for the opportunity that if some day in the future you reinstall the application, your data will be waiting for you.
Yes, uninstalls are hard. Ask me! I'll tell you whether I am coming back or whether I am throwing you out for good.

@Aron: thanks, i never really understood what 2>&- did!
When I am forced to use a Mac without any helpers like Default Folder, Hazel, PathFinder, Alfred, Cocktail, EasyFind, AppCleaner, etc., I realize how the default OSX experience was perhaps not targeting the power user. But over time as the average user gradually expects more capabilities, the helper app functions eventually make it into the core set of OS features. Even the apps that come with uninstallers often hide them in an out of the way corner and you have to go looking to find them. I think there should be more of a standard approach in this area, and given Apple's focus on saving disk space by moving files to the cloud for you, there might be good motivation to improve this facet of the system.
AppCleaner does a good job at finding all the dependencies.
CleanMyMac does a great job of finding junk files to remove. Also has an uninstaller that will also get rid of dependent files.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.