Drag-and-drop installation is a great method of software distribution. For software that is self-contained and doesn’t require living in any specific directory to run, it allows the user to be as neat or as messy with their hard drive hierarchy as they see fit. But for certain types of software, certain things need to be in certain places. ClickToFlash, a Safari plug-in I’ve been working on, is one of those cases.

Really, the only two types of software distribution that are at all credible in my mind are 1) drag-and-drop installation, and 2) Apple’s installer technology. Any other method of installation is dead on arrival. There are numerous criteria — remote deployment, user familiarity, flexibility, scriptability — areas in which these two methods excel across the board. All other installer technology (VISE, FileStorm, I’m looking at you) falls flat in at least one of these areas, if not more.

Despite that, however, one of the worst parts about Mac OS X software distribution that you’ll ever run into is creating an installer package for Apple’s Installer. It will frustrate the heck out of you, cause you to curse out loud, and generally cause you stress for days at a time until you solve your problem, and then you’ll never want to touch it again for fear of breakage.

In addition, if you’re deploying for previous versions of Mac OS X, you have to live with all the bugs of the previous versions of the installers in order to be able to target them. And that’s where things get really, really icky. You’ll get reports from users about your installer not working, and you will struggle to figure out just what that problem is. This article serves as (what I hope will be) the definitive guide for knowing all the pitfalls and workarounds to the atrocious bugs that exist in Apple’s installer technology.

As Mac OS X 10.6 Snow Leopard is just around the corner, and I don’t have access to pre-release seeds, this article will currently only serve as a guide for 10.5 and 10.4. As for older versions, Panther and previous releases of Mac OS X are dead to me, as they are to the vast majority of Mac OS X users. While there are some users for which these releases are no doubt more than enough, I doubt it’s worth any effort anymore to target these users.

Problem: You want to install items into the current user’s home folder. Solution: Use the new “domain” feature for 10.5 installers to target the user’s home. Pitfall: FileVault users will be unable to use your installer.

Details: Before Leopard, there was no easy way to install items using Apple’s installer to the user’s home directory. Leopard introduced a “domain” feature that allowed you to target the user’s home directory. If you had a package that installed something to /Library/Internet Plug-ins/ , you could offer the user a choice: install for all users (which installed to /Library/Internet Plug-ins/ ), or install only for the current user (which installed to ~/Library/Internet Plug-ins/ ). This is a great feature, if it only it would work correctly and consistently in all cases.

Unfortunately, as you’ll see is typical of Apple’s installer technology, it doesn’t. When FileVault users try to install to the home directory, three things will happen:

1. The installer will hang for about 30 seconds when attempting to change to the “Select a Destination” screen.
2. You’ll see this error in the Console: Installer[23479]: -[PFReceiptDB initWithPkgID:andName:onVolumeOrHomeDir:] some arguments are required! pkgid: ‘com.packagemaker.simx.testapp.bugDemonstration.test.pkg’ domainPath: ‘(null)’
3. When the “Select a Destination” screen finally comes up, the user can opt to install to their home folder, but the “Continue” button will be grayed out if they do so. They will be unable to proceed with home folder installation.

* provide pic of installer *

Workaround: If your installer does not depend on you installing to their home folder, that’s good news. Just deselect the “home folder” checkbox in PackageMaker, and rebuild your installer.

* provide pic of PackageMaker *

In many cases, however, it’s better to allow the user to install to their home folder. With ClickToFlash, for example, we don’t want to force our software onto all users of a machine simply because one user installed it. We want one user to be able to use ClickToFlash and allow another to not have it installed at all.

The workaround in this case is to install the necessary files and folders to /tmp , which any user can read and write to. Then, in a postinstall, postupgrade, or postflight script, move the items from /tmp to the correct location in the user’s home folder.

* provide pic of PackageMaker *

* provide example shell script *