As a developer of Mac OS X software, how to deliver that software is an issue of constant battle.

Long long ago, everything was shipped as either an installer or just in a StuffIt archive. Typically applications came in installers and the only thing in StuffIt archives would be non-applications (documents, pictures, other data).

Mac OS X tries to change this by simplifying things using drag-installs. It’s actually a very simple process of download, drag the application icon to the Applications folder, and off you go. But, even something as simple as that can prove too confusing for the lay person, or at least it allows for a host of problems. Installers still exist as well, and there are many other modes of delivery and installation out there.

Various bloggers have been discussing the issue. It starts with FireFox distribution issues, where they ultimately conclude that you should just ship an installer and piggy back off other mechanisms (e.g. automounting of .dmg’s). John Gruber counters that we should just use .zip files, and makes rather compelling arguments for that approach. Chris Clark also agrees with using zip archives. Andy Kim takes it a bit further and actually starts to touch on what I’m going to hit at.

All of these solutions are nice, but they all seem to target one thing:

Very simple applications.

If all your application is is itself, then I guess that’s fine. But what if your application has more than just the application itself? What if it needs to install drivers or other kernel extensions? What if it had launch agents or daemons? How about other plugins that need to be installed? Maybe something that requires a restart of the machine? What if you need to run scripts to deal with housekeeping (e.g. to help upgrading past users to the new version of the software)? All of these simplistic approaches just do not cut it.

Some would argue this should be a part of the application itself. That is, self-healing applications. I see merit in that approach and it could be a solution that solves this and the initial download-and-install problem. But it is not a panacea.

The ultimate problem is there is no one-size-fits-all solution, which seems to be what people are proposing… or at least, they’re not considering the wider scope that some developers may need in the install process. Apple seems to have the tools in place, but isn’t quite there. What ought to come would be:

• A new installer format. It could be an archive holding all the parts to be deployed, but it should allow for logic to be applied during the install (e.g. use of shell scripts, etc.).
• This format is understood by the OS, so when applications such as Safari download them, they can start the install process. Of course, we have to be mindful that some people could use this for nefarious purposes, so being fully automatic is not ideal… asking the user would be helpful. Using code signing and other forms of trusted computing may help here.
• The notion of installing then isn’t just some file format, but is also considered an end-to-end process, from either downloading the software or inserting the removable media that has the software on it, to getting the software installed, configured, registered, and cleaned up after (optionally removing older versions of the software and its support files, removing any archives, trying to leave the machine in a cleaner state than before it started). Get the users going the whole way through. It should “just work”; Gruber’s mention of how the iPhone works is apt.
• To publish a set of tools AND guidelines on installer creation. Apple goes through a lot of trouble to establish human interface guidelines on how applications should work. Apple can and should do the same with installers so that the experience of getting software to users can be as simple and pain free as possible, but also as consistent as possible.

The big problem we have today is too many approaches to installing software. Everyone has different needs and different thoughts on how best to approach it. I’ve had debates at my office about how we should deliver our software, and it’s difficult to achieve consensus because all approaches have strengths and weaknesses. This only serves to hurt the user because there isn’t one way that “just works” for them to get to know and be comfortable with. Every install process is different and unique, and for the non-geeky types, just frustrating and confusing.

I hate to say it but the movement to improve this will ultimately have to come from Apple. It’s their platform, it’s their user experience that they wish to control and dictate. Ultimately Apple must be the one to improve this.

Can we 3rd party developers do something about it? Sure. We could work to tackle the problem, publish our own guidelines, create tools to help out. But I’m not sure how far it would get. Efforts like Growl, Sparkle, solve some great problems and didn’t come from Apple and have gained a tremendous amount of traction in the developer world. Still, some venture to do it themselves. Code solutions are good, but guidelines are better so if you have to do it yourself, at least some guiding principles can be followed with the hope of still making things good for the user.

Where to start?