Uninstalling Apps on Mac OS X Is Flawed; Is There Any Solutions?

You have probably experienced this already: there is an app that seems like it might be useful to you, and you want to test it.

Happily enough, it is ridiculously easy to install apps on a Mac: download either a dmg or a zip, open it, then drag & drop the app into /Applications/.

If the app is not useful to you after all, it is as ridiculously easy to uninstall apps: open /Applications/, then drag & drop the app into the Trash. Boom, it is gone.

Or is it? You bet it is not!

Each app on Mac OS X has the ability to create support files, much like Windows apps create registry entries¹. They resides either:

1. in /Library/Application Support/,
2. in ~/Library/Application Support/,
3. in /Library/Preferences/
4. or in ~/Library/Preferences/.

Or any other folder I am not aware of. Point is, that is a lot of places to look for.

The problem we run into then is that we have to either deal with these files and go and track them down, or to leave them to be and clutter the system.

In most cases, Mac users do not even know or care about it, and end up having tons of unwanted files. They take place, they clutter the drives, and worst of all: they slow the system.

Fortunately, there are some apps that take care of it for us. You probably know some: AppCleaner, TrashMe, AppDelete, AppZapper and AppTrap among others I am sure². Although they do relatively well their job, I believe they do not fix the problem.

What they do basically is monitor the Trash for apps dropped into it, then scan the various folders in which these support files usually are — listed above — and if they find matches they will ask you if you want to delete them as well.

They have their flaws however:

1. apps could potentially store their support files elsewhere³
2. developers could use different bundle names⁴
3. apps could store tons and tons of support files that would make scanning for them an epic hassle⁵.

One solution would be for these apps to constantly monitor the files an app creates and uses, and maintain some sort of database⁶. It would quickly grow out of control though, and many of these are files that matter to the users (i.e. Word documents). Uninstaller apps would have to filter the database to only delete support files, and leave user files intact. Tricky.

I have been thinking about this for months, and am proposing three solutions. I do not pretend to hold the absolute truth here, nor do I think these solutions are without drawbacks — they have some indeed — but I do believe they are improvements nonetheless.

Spotlight-powered support files monitoring

My first proposal relies heavily on existing foundations.

Whenever an app creates a support file, a special metadata is embedded into it and contains the bundle identifier of its creator. As Spotlight crawls routinely over the system, it would catch this metadata.

Now, if a user deletes an app, Spotlight would automatically trigger, and look for every files with their metadata equal to the specified bundle identifier, and delete them as well.

In fact, it would work in the exact same way the aforementioned apps do. Its strength though, is that Spotlight is already running, and is very powerful at finding files and associated metadata.

Think of it as the way Apple would have implemented AppZapper directly into Mac OS X.

System snapshots

My second proposal is a bit clunky and would probably not be understood by much of the user base.

It would probably never see the lights of day as is, and even though I would use from time to time I find it to be useful only in edge cases.

Anyway, this would basically take snapshots of the system as the user installs and deletes apps. A new UI — much like Time Machine, or Versions on Lion — would then allow the user to go back in time and restore a snapshot before she installed the app.

For instance: she browses the App Store, sees Byword, is interested and installs it. She tries it but sadly it does not not suit her needs, and wants to uninstall it.⁷

Now, instead of trashing the app, she clicks on that little icon up there in the menubar and is brought to this new UI. She then browses to that point in time right before she installed it, and restore the corresponding snapshot.

That is basically how it would work.

However, what if she tried another app before uninstalling the first? What will the system have to restore then? The state preceding the installation of the first app? But what do the support files of the second app become? This is particularly flawed.

One solution might be for the snapshots to be somewhat atomic⁸. But, all in all, as I have said, it would only be used in edge cases and probably be ignored by most Mac users…

Sandboxed apps

My third and last proposal is so groundbreaking that it would be best implemented in a major version of Mac OS X.

Mac apps would work like iOS apps. The latter are confined into their own sandbox⁹.

Now, apps on the Mac need not be confined in any other way that there already are¹⁰. The only restriction would be that the support files are now stored into the app, into its actual package.

This would solve all our problems related to support files because they would be physically tied to their app.

The only drawback I can think of — other than having to rewrite basically all apps, that is — is updating. Frameworks like Sparkle would need to be rewritten too, but this would not be much of an issue.

However, it would be very inconvenient for the end user that actually updates her apps manually. This would not work anymore, as existing support files would be crushed over by the new, preferences-free app.

Therefore it would also require the user to rely solely on the Mac App Store to update her apps, or on apps that include an update framework.

Final note

I may be wrong, or plain blind, on some things. It is very likely, actually.

There may be tons of drawbacks I have not considered for instance, and I highly encourage you to send me an email if you know or find any.

Once again, I remind you that your comments will be taken into account and will find their place here.