Today’s Daringfireball article on the shortcomings of the Mac application-install procedure is worth a skim. Gruber’s suggestion that Mac OS X automatically move 3rd-party applications into the /Applications/ folder on first-run, (a la the dashboard widget install process) is a good one1. Since Mac OS X already prompts you on first run (“Are you sure you want to run a program Apple didn’t write?”) it’s hard to see any downsides to this idea.
But that’s not the behavior we have today1.
Don’t Use a Damn .dmg!
As it stands today, I don’t see a good reason to ship your apps as a .dmg. I’ve been suspicious of disk images for a few years now; and usability tests show that people get confused by them.
Distribute your application as a single .app in a .zip archive. What possible use are other files besides the application? If a “Readme” file should be read before using the application, then show it when the application is first launched.
Installers are opaque and un-Mac like. There’s always a risk that they’ll install something that breaks the computer. As a developer I am even more suspicious of installers on the Mac, because I know how broken Apple’s installer tools are.
Of course, as a developer, I know that applications do sometimes need to install components. And here the best solution is for the application to check it’s environment and ask to install missing components as needed (in essence be it’s own installer). It’s more robust, since it detects-and-corrects missing or damaged components. It always preserves the user-facing abstraction that the icon is the application.
Applications shouldn’t install hacks dangerous enough to require a bundled user-facing unisntaller. To make IMLocation work, I had to install a background process — but I made it intelligent enough that it would uninstall itself if the main application had been deleted. Yes, this is more work, but it’s worth it.
1Another idea is to make Safari and Firefox smart enough to download applications directly into the right /Applications/ folder, bypassing the usual downloads folder. This elegantly solves the instillation problem, although it creates some new problems.
2Although it would be a cool hack to write.
With our Last.fm desktop software we had to install an iTunes plugin, Apple made it easy, we just copied the plugin bundle to the ~/Library/iTunes/iTunes Plugins directory when our app first loaded and iTunes would automatically load it.
We also did as you did and made the plugin uninstall itself if the application is uninstalled.
Seamless for the user, certainly more work for us, (it’s a lot easier with an installer as you know everything is set up before the application runs), but it felt great as an overall solution.
Comment by Max Howell — September 22, 2009 @ 7:43 pm
DMGs have one advantage, in that they checksum their contents on opening. So you can be sure your customer hasn’t received an app bundle that is corrupted and exhibits strange behaviour. Like once someone downloaded our windows installer and it was slightly corrupted in transit and none of the image files loaded, so the app looked plain and unusable. Very strange bug.
With a zip this can happen still. Though honestly it’s much more likely the whole program won’t run. And secondly download corruption is pretty rare.
Still, it’s nice to have that reassurance. But overall I agree with the zip method of distribution and use it for all my own stuff.
Comment by Max Howell — September 22, 2009 @ 7:48 pm
Max,
I’m really glad to hear about the self-uninstall in the last.fm plugin! It’s good to know that other applications are able to do this. I talk tough, but the more I think about it, the more I suspect that many cases where you need an installer, a self-uninstall might not work.
Good point that DMGs include a consistency check. I’m hoping that code signing might be able to provide this functionality someday, but there are other issues with signing, like complexity, and possibly ceding control to Apple.
Comment by Vincent Gable — September 28, 2009 @ 4:50 am