The Problem With Custom Installers is a brilliant piece by Mike Zornek. (I have a lot of respect for Mike Zornek. Not only has he managed to make it on his own as an independent developer, he also wrote the initial implementation of the MegaManEffect blockbuster hit.)
In the article, Mike points out that custom installers are a hassle and that many people who use them would be better off using Apple’s own Installer. Here’s the problem, though: most of the custom installers - and many of the installers Mike is complaining about - are crappy re-implementations of Apple’s Installer. They are doing exactly the same thing, coded from the bottom and up, but in a worse way. I’ve had one of the VISE installers shut down every single app on my system without asking. They still look like they were dragged, kicking and screaming, out of Mac OS 9. Running one of these installers is like getting a visit from the mob.
In contrast, what I want is something that copies a damn file to a folder that does not exist by default and is careful doing it - half of my stuff are plugins and can’t be dragged and dropped unless you already have like plugins. Following the instructions I currently provide in the readme, while annoying, requires you to Deal With less stuff than following Apple’s Installer. An improvement to this situation is not just one that automates the process, it’s one that makes it shorter and doesn’t do so at the expense of being correct.
Writing an installer is something you should have to think very hard about. Most apps don’t need installers and can be dragged and dropped to where they need to be. The rest of the apps either need Special Stuff to happen or they need admin privileges, and they should use the default Installer. I do not need Special Stuff to happen, I just need drag and drop to a folder that does not yet exist.
This is a common problem and it’s something that, out of four products, I have to deal with in two. It may appear to be ridiculous overkill to some, but I have a good opportunity to solve it now - to create an installer that’s well-mannered (shows a list of its files, acts accordingly on “no free disk space” errors, provides some sort of receipt log and handles up- and downgrades) and is tailored to the situation.
I didn’t decide to do this because I wanted to create a new Xcode project - I did so because I reviewed the alternatives and rejected them, knowing that if possible, I shouldn’t need to provide an installer, knowing how a good general installer should behave (and talking to people who know more to see what they consider essential) and how my installer in particular would ideally behave.