Amen.
Windows has had centralised uninstall functionality for ages. OS X would definitely benefit from apps that don't leave rubbish around when we get rid of them.

I agree.
This would be a good idea. When you drop an app in the trash, a window should pop up asking, "Do you also want to delete supplemental files associated with this application? [Details] [Delete] [Cancel]" Details should list the files on the chopping block.

I'm with you...
I agree that Apple's installer should have uninstallation abilities, and I do like the idea of connecting it with the trashing of applications.

But then again, there are a lot of resources that are stored in /Library and the like, which could easily be included inside the application bundle today, and thus be trashed along with the application. If developers aren't even motivated enough to make simple changes to their applications, how can we expect them to provide proper deinstallation information?

Baby bathwater ratio violation!
OS X's drag-to-install technique is a great feature which we would all regret losing, I think. It would be nice to be able to uninstall these more cleanly, but not worth going to the Windows extreme to get it.

OTOH having a real package management system (ie for .pkg and .mpkg packages) that properly supported dependencies and advanced things (!) like uninstalling would be great. It just shouldn't be required for everything.

An Easy Win
You have hit on something that many seasoned Mac users have thought aloud. Perhaps it could be done at system level. It would not take much for the OS to track a file created by an application in the Preferences folder, I would have thought.
Then when the application is deleted, you could be offered the choice to delete assocated files. Now extend this to other folders.

But what about multiple accounts?
The suggestions so far are fine, but what about Macs with multiple accounts?

This would have to be an administrator (or more likely, super user) level function that can search ~/Library, etc. for all the accounts.

Which is why the preferences are in ~/Library in the first place. That way my preferences don't interfere with the significat other's, the kid's, etc. If the were stored in the App bundle, then there would be only one set of preferences for all users. (Correct me if I'm wrong.)

I agree.
[Details][Delete][Cancel] is pretty good, but some tweaking is needed.

Two scenarios:

1) The user wants to keep the miscelanous files ('cause he's manually upgrading!), which does he click? it can't be cancel, cause he still wants to delete the app, just not the prefs etc.

2) Multifiles, or a folder of apps is deleted, does clicking 'cancel' cancel the whole delete, or just doesn't delete the one application.

Better button names are needed!

My first thought
was that this is a great idea, I've had the same problem myself.

My second thought is that there has definitely been times when I re-installed an app and was gratified that my old settings were still there.

My third thought was about multi-users, which someone else has mentioned.

My last thought is that maybe what we need is something that works in the other direction - a program that scans caches and preferences and detects which ones belong to apps that have been trashed?

Hrm. That would be a major pain to design, though.

But what about multiple accounts?
Just to make sure you understood what I'm saying, and that I understand you -- app preferences would still reside in users' local home directories such as ~/Library (or whatever) -- its only the paths of the app's particular caches or preferences that would be in a plist inside the app bundle. i.e. in the app bundle an entry might say "~/Library/Preferences/foo.bar.baz.plist" to signify that the app foo.bar.baz keeps it's preferences in a plist inside the ~/Library/Preferences directory so that when the app is uninstalled, the preferences file could be located and disposed of.

We probably already understood each other, but just to make sure and clarify for other folks who may run across this...

My first thought
I think that on #2 we're covered by allowing the user to optionally retain caches/preferences and on #3 we're covered if we spec this out so that apps keep their caches/preferences in locations relative to the user's home directory.

Although I haven't checked it out, the app I mentioned in the post, I think, does what you described in your last thought.

There is the possibility...
But one must make a .pkg file for install. During the install process, a bill of materials (bom) is left in the Receipts folder of the system. This has what files are installed where. There must be a way to tie into that for removal.

tried Desinstaller?
Have a look at this:

http://krugazor.free.fr/software/desinstaller/DesInstaller.php

The limit to app zapper
is that you have to use it to remove the app - I was thinking of something more like a cross between spotlight and macjanitor.

re: Amen.
Um, you have to be kidding me. Have you ever actually looked at the detritus left over in the user's portion of the registry, not to mention the stuff buried in the user's Documents and Settings directory? Uninstallation my behind. The .plist hangovers pale in comparison.

I'd settle for...
Just uninstallation capability in Installer.app, or an application distributed with the OS to back out .pkg's (e.g. read /Library/Receipts).

I think an automated process on delete of the application bundle from /Applications is asking for serious trouble.

I'd settle for...
OS X apps are so great because they are so darn usable, and in my mind, uninstall should necessarily be much easier than install for the general case in order to meet my standard of useability. As you already know, I would prefer one step uninstalls -- which are by definition just as easy or easier than any install.

If installation isn't true drag and drop like many OS X apps are, then no big deal -- you specify a few options in the installer and keep rolling. But explicity uninstalling...there just seems something unnatural about that to me. In practice, again, I'm sure it would have plenty of kinks that need to be worked out over some time period, but at a basic fundamental level, I really do think that the user should have the option to have a one step uninstall without seeing some barnyard act take place where it takes 5-7 clicks to get the job done.

And I think that based on some of the posts we've seen so far, it's defintely doable, whether it be with the way I suggested, with a package/receipts approach, with the OS "spying" on apps to see which files in ~/Library are "owned" by what apps, or whatever.

But as you and some others point out, there's bound to be problems or at least the fear of problems, and so there should definitely be the option to defer all such decisions to the user.

Here's an easy way to implement it!
Remember that an application is really a folder containing a bunch of separate files. MacOS X treats it as a single file in most respects, but it is still a folder.

How about simply storing all of the configurations inside the "App Bundle" and forget about the ~/Library folder? Including any cache. You can even have separate folders for each user inside the "App Bundle". Tossing the "App Bundle" would delete all of the files.

Still, Windows does have us on the Install/Uninstall procedure. Let's take Perforce. I've just installed it on my Mac and on my PC. Perforce installs two client programs (p4 and p4v) and a server program (p4d). The server also needs to be configured and started.

On Windows, this is all handled by the installation. On a Mac, I have to manually copy these files to various places (I put "p4" in /usr/local/bin because it is executed by the command line while "p4v" was placed in /Applications, and "p4d" the server program to another location).

On my Windows system, the server automatically starts at bootup, and starting and stopping it is easy. On the Mac, I have to figure out how to add it, so it will start up on boot. I think I have to do something with /etc/rc, but not 100% sure.

And, let's not forget the entire Perforce depot that gets built when you run Perforce. To uninstall Perforce on my Mac involves me chasing down all of these files, and remembering to remove them. On Windows, you run the Remove Application control panel and everything gets cleaned up.

The Mac definitely needs work in this department!

Return of the son of creator codes
Adding a plist to the bundle sounds like an idea, but it would very likely be unreliable as developers tend to forget to keep things like that in sync. Look into the bundles of many apps and you are likely to encounter unused junk. What makes anyone think another plist in there would help?

Nothing would need to be added to the bundle if the files that applications leave lying around have the creator code set to the application creator code or to a special code. Nowadays the applications all have reverse url style codes (like com.apple.mail) to uniquely identify them. If the system enforced this on file creation by applications it would be guaranteed to be in sync, even if the creator code of the application bundle were edited or changed.

Another old technique would be to place files in certain special places, like a "temp" folder or a "cache" folder so that they could be cleaned out automatically.

Once all of the detritus left by an application was marked correctly it would be a simple enough thing to find it all.

But several problems still need to be addressed. Assuming that the user who is trashing the application has the privileges to do so, there is still the fact that other users on the machine may have ben using it and have these same kinds of files. An admin password could allow deletion of all the files unless a user is running file vault, in which case there is no viable solution that doesn't require some sort of clean up the next time the user logs in.

As noted earlier, there are times when you want to keep preferences around for that occasional upgrade or reinstall. And some applications depend upon hidden stuff to keep track of demo expiration dates, serial numbers and the like.

And one more issue: The user documents created by the application in question may still have value as well. Would you want to see them removed?

There also exists the possibility that one application may want to peek at another's preferences for some reason or even add something there, as is the case with some plug-ins.

Uninstall and clean up is always going to be a messy problem until people demand better behavior from developers. Apple could add some system support for it, but there will always be developers who will not use it. And I think an attempt to make it completely automatic might actually do some harm.

Here's an easy way to implement it!
This will not work well in many environments where /Applications is not writable by the logged in user (networks etc) or where ~ is a network mount.

Return of the son of creator codes
You raise many very valid concerns, and I agree. It's simple for us to kick back and dish out directions for how things should be done, but not everyone will care to/want to/know how to follow the standards. As you point out with creator codes, most folks don't even bother with that anymore.

As much as I hate bureaucracy, I do think, however, that developers should make it a point to follow standards and that the folks who maintain the OS should make all reasonable attempts to define simple, easy to follow standards.

Here's an easy way to implement it!
How about simply storing all of the configurations inside the "App Bundle" and forget about the ~/Library folder? Including any cache. You can even have separate folders for each user inside the "App Bundle". Tossing the "App Bundle" would delete all of the files.

Hmm. Now there's an interesting thought. Intuitively, an app should be the only thing messing around inside its own bundle (although 3rd party plugins may blur this concept slightly), and so it does seem pretty reasonable to have an app store a lot more info inside of its own bundle.

I'm sure we could nit-pick a half down issues or so with this approach, but it sounds pretty darn reasonable if you ask me.

Look what just popped up on del.icio.us
Haven't tried it yet, but:

http://appzapper.com/

Nit-Picking? What about Mobile Home Directories

I'm not sure it's a nit-picking issue. Lots of people like the idea of a mobile home directory. Either something you network-mount, or have on a hard drive or iPod -- you log into the hard drive and have all of your preferences in ~/Library/

Include backups too -- I can currently back up my data and preferences by copying ~/ and can fit that on 1-2 DVDs (well, that's excluding music).

But in this scheme, I can't easily rig a mobile home directory with preferences OR backup my data and preferences.

Worse, if I update an App by copying a new version to /Applications, I end up killing my preferences.

No, the .app bundle is *NOT* the place to put user preferences.

Nit-Picking? What about Mobile Home Directories
Good point. I complain at work all of the time because they don't have roaming profiles at work, but I'd neglected to think about that point of view when commenting above. Guess the app bundle could be quite a mess in the situation you've described.

And on a side note, that's what's so great about these threaded discussions -- lots of clever insights surface that I would have never been able to or had the time to think of.

Metadata! Woo!
I don’t think the paths idea is a robust enough approach. For one, it would break when the user renames their hard disk. Secondly, some support files’ paths (e.g. Photoshop’s swap files) could be configurable, and then the SupportFiles.plist-info would need to be modified. And it’d be even messier if several users could provide different places to keep these files.

Putting support files in the bundle has similar problems, especially if the software is on a server and shared between hundreds of users. It’d circumvent users’ disk quota and make permissions for an app bundle unnecessarily complex.

My suggestion would be to simply add some sort of metadata to such support files and then use the Spotlight index to get rid of such files. Whether it’s done using access control lists, an xattr that simply says: KIsSupportFileOwnedBy = com.oreilly.uninstallableapp, or they define a OS9-style creator code in your Info.plist that says that all files with this creator are deletable support files, I don’t really care.

If all apps were required to give their support files such attributes, one could even have hard disk clean-up apps that can quickly find any orphaned files, like it was possible on Classic MacOS with creator codes (e.g. FileBuddy checked for files with unknown creators and offered to delete them). It should also be supported by NSDocument without too much work ... NSDocument's bad support for creator and typecodes is the main reason for bad creator support, along with an ambiguous policy on Apple's part and the discontinuation of the type/creator registry ages ago.

Maybe it should even be a *list* of owning apps’ bundle IDs in an xattr. That would allow extending this to other kinds of files. E.g. a shared Framework could be auto-deleted when all apps that own it have gone.

I agree that Finder should generally ask whether the admin wants to delete all support files for all users who’ve used this app. After all, they may want to remove the global copy of the app and give two users who still need it local copies when an app is phased out. In that case, they’d want to be able to keep those users’ files.

Why not embed Installers and Uninstallers?
A thought to the folks who don't like having to run an installer/uninstaller: Why not just add install and uninstall executables (which could be any of applications, shell scripts or .pkg files) to an application's bundle in a standardised location?

You simply copy over the app, and when you first launch it, the Finder runs the installer in it, deploying all needed files. When you delete it, Finder finds the uninstaller and offers to run that.

Would use up more disk space, obviously...

Why not embed Installers and Uninstallers?
Erm ... just to clarify: That's not currently an option. It'd be a feature that Apple would have to add in Leopard. But it would be fairly easy to add a new folder like "MacOS" or "Resources" to a bundle called "Installation" that contains a uninstall and install executables that Finder would then be made to run as needed on first launch/delete.

no no no
I love you guys, but this whole discussion is retarded. The last couple of posts are bringing it back on track. The idea of the application being a tangible chunk is priceless. Don't destroy that!

Furthermore, your uninstallers are as likely to cause harm as good, as shown by all modern implementations of such registry-like systems. And finally, you don't know what kind of benefit may come from those seemingly unwanted but typically harmless files. Occasionally I get a new app, like a raytracer, that sees that it has never been there before, and imports or asks to import prefs from a previous raytracer. Why it turns out that's really useful! E-mail, web-browsers, word processors, they are all useful. Hell, if I toss out the app and then decide later that I want it back and don't need the disk space anymore, I still have my prefs.

The system to handle this is the filesystem, and HFS+ in its current incarnation affords this. There is a last-accessed attribute. If you want to get rid of stuff you REALLY don't use, run a search for all the stuff you haven't accessed for 2 years. Then you'll know how to get rid of stuff based on actual usage instead of some synthetic version of how computers will use people. Predictions of the future are always partially wrong, and usually mostly wrong.

Sorry if I got all wordy, but you really got me on this article. It is all of the movement toward Windows-Think that I hate about the current Mac OS X development and design. Let me know when you've written an app that will look in my home folder for items I haven't accessed in 500+ days.

no no no
this whole discussion is retarded

LOL! But fun and thought provoking, isn't it?

The idea of the application being a tangible chunk is priceless. Don't destroy that!

Agreed 100%

It is all of the movement toward Windows-Think that I hate about the current Mac OS X development and design.

What, in your opinion (other than a few comments on this post) is Windows-Think in OS X design? I can't think off too many right off the top of my head, but would be interested in hearing more about your thoughts on this.

Let me know when you've written an app that will look in my home folder for items I haven't accessed in 500+ days.

Not a problem. I could whip you up a script in about 10 mintues if you want. Actually, I couldn't do that this second, because I'm swamped and my attention is in a thousand places right now, but if you or anyone else would benefit from it, I'll post one when I get a second -- unless someone else beats me to it. Want to see who can do it in the fewest lines of script/code?

10 minutes?
How about two seconds?

% find ~ -atime +500

Assuming you trust the accuracy of a file's atime.

10 minutes?
Wow. Now that's a true gem. I'd never even bothered to look at the man page of "find" until you said that. Way more useful than I'd ever thought.

My inclination after reading that which I wrongly thought would be equally as good or better was to try the mdfind -- but the results were so startling that I almost decided to post about them in a rant. I was really bummed to see that Spotlight and mdfind didn't exactly come through for me as expected.

First I tried

mdfind -onlyin ~/Library/Preferences 'kMDItemLastUsedDate

10 minutes?
Sorry that looks so jacked up (at least in Firefox). If you click on "View" though to see this single comment, the code tag breaks off appropriately.