One of the many great things about OS X is the simple installation process most applications use. To summarise the process – “Simply Drag and Drop to Install”.
OS X has the concept of an application “bundle” (there are other types of bundles too, but I want to just talk about applications for now). An application has many files that work together – for example, there is the code that runs the software, there are images that are displayed, there are icons that are used, there are sound files that are played. The bundle concept puts all these files together in what appears to the end user as a single application “file”.
When you install the application, you drag it (the bundle) to where ever you want to install it. Often this is the Applications folder.
Now when it comes to delete, all you need to do is drag the file to the Trash, and empty it.
The whole idea is so simple and elegant. For most software there is no need to run special installers, or special programs to uninstall the application. Compare the whole process to that of Windows with install and uninstall applications.
Am I really clean of the software
There is one slight hiccup to the process. An application may create files that are not in its bundle. When you delete the application these files are still hanging around in your filesystem.
This isn’t a big deal generally. Most support files are very small – for example, almost every application will have a preference file. This file lives in your home area, under Library/Preferences. If you ever have a look there you’ll see lots of preferences for applications you deleted long ago – in some case applications you don’t recall every running because you tried them once and deleted them almost immediately.
Some applications install files elsewhere when you run them. For example, in your home area, under Library/Application Support, or perhaps even in your system library.
Further, when you use the application, it may store user files in certain locations. For example, it may store cache files in the Application Support area, or your profile information.
For example, OmniWeb stores the following files in Application Support (Firefox similarly stores profile information).
There are third party applications that support cleaning up on deletion, for example AppZapper, and clearly there is a market here as these applications are quite popular. However, it would be nice if OS X actually had the ability to clean up after itself without the need for third party tools.
Enter Trash Triggers
The idea here is simple. When you “trash” an application, the process of deletion should be able to “trigger” cleanup of the application (either automated or with user intervention).
For example, imagine I have been trialling Delicious Monster’s very cool software Delicious Library. Unfortunately I can’t afford it, or I don’t believe it is something I really need, so I place the application in my Trash, and empty the trash.
Delicious Library would actually leave behind the following files:
If I’m not planning to use Delicious Library, do I really want these files in my system?
Now, suppose emptying the trash could do the following. On finding an application to be deleted the operating system displays the following dialog (bear with me here – this is a mockup, and the dialog probably needs more thought on wording and button labels etc):
At this point, the user can choose to delete all the support files, removing all trace of the application from their system.
Now clearly not everyone wants to delete all traces. For example, I might be deleting Delicious Library for now as I don’t have room – but next month I intend to buy it and download it again. So I want my preferences retained. Therefore I can choose to just delete the application.
The result is an easy way to really clean up an application that was deleted through drag and drop.
How would this work
Below is a proposal on how this could work. These details are more technical, so only read on if you are interested in the internals of the application bundle and the way OS X operates on applications.
In my mind there are 3 types of support files:
- Application Preferences – a single file that stores the application’s preferences.
- Installation Support Files – files created after installation that support running of the software, for example kernel extensions, plugins, scripts to be run at certain times etc.
- User Support Files – file created by user interaction, such as cache files and user files that are auto saved.
An application, on deletion, could potentially delete any or all of these support files. Therefore, the solution should allow the developer to decide what is to be deleted.
The proposal is to add some new keys to the info.plist in the application bundle. These key-value pairs indicate how deletion should be handled.
I’ve used keys with an LS prefix (meaning Launch Services) given that many keys used by applications that relate to the running of the application use this prefix. It is quite possible that another prefix would be more appropriate.
In order to indicate you want to display a dialog asking if the user wants to delete all support files, the developer simply includes:
<key>LSDeleteSupport</key>
<string>ask</string>
Where the value could be ask – meaning to show the dialog, or auto – meaning to delete as instructed without asking the user. The latter would be used for certain applications that don’t store user data but should clean up support files.
Preferences
Preferences are easy. They are always in the same location, and based on the CFBundleIdentifier key in info.plist. You just need to use a key like LSDeletePreferences with a YES or NO to indicate if you want the preferences deleted (if the user says to).
Installation and User Support Files
The Installation and User Support Files are more tricky. Basically, the developer may have stored files in Application Support, or in another folder completely. They may have many different folders with support files too. In some cases they may need to do some processing first.
Here we could give the developer some choices:
- Delete all files in a supplied array of folders
- Run certain scripts in the application’s Resources folder (in the bundle) that clean up after some processing
- Make use of spotlight and metadata, and delete all files that match a given attribute
The first two are fairly standard strings in arrays in the info.plist. OS X just needs to delete as required, or run the scripts in the order presented. In a similar fashion to the application preferences, a further key such as LSDeleteInstallSupport would be used to allow the developer to say whether they will delete the Install Support Files (if the user says to).
The third choice is more interesting as it makes use of OS X’s Spotlight.
Using Metadata
If the support files created by the application are tagged appropriately, OS X could delete all files with those tags. For example, suppose the following metadata attributes exist for files – kMDInstallSupport and kMDUserSupport. OS X can search for all files with one of these metadata attribute and the value CFBundleIdentifier, and silently delete those files. This isn’t dependant on file location at all, instead it makes use of the powerful metadata searching abilities of OS X.
The Future
So far Apple has said very little about Leopard (the next OS X release). We don’t know if there will be a new Finder, and we don’t know if Apple has thought more about uninstalling applications. I have proposed a solution that I believe maintains the elegance of drag and drop deletion, while still allowing applications to clean up after themselves. Even without the dialog, the ability to trigger deletion of support files when deleting an application would be useful. Once again, I’d love to talk more to Apple engineers about these ideas.
Set up different versions of the order form web page for different languages, then change OpenName for each language.
