Volume Number: 20 (2004)
Issue Number: 2
Column Tag: Programming

Mac OS X Programming Secrets

by Scott Knaster

Ship It! Distributing Your Software, Part 2

In our last thrilling installment (or was it a thrilling installation?), we discussed the simplest method of distribution for your Mac OS X software: disk images. We talked about using Disk Copy or Disk Utility to make a disk image, and we described the relatively recent technology of Internet-enabling a disk image so that it cleans up after itself when users download it in Safari.

When you distribute software on a disk image, there is no actual installing taking place. Users simply drag and drop files onto their hard disks. That's the great strength and weakness of disk images: they're easy for you to make and easy for users to figure out, but you can quickly run into their limitations. For example, what if you need to make sure files end up in specific places on the disk? What about checking the progress of the installation and taking some action based on what's happening? Most commercial applications need to do things like this when they're installed. For more control of the installation process, Apple provides the PackageMaker and Installer tools.

PackageMaker is an application that comes with Mac OS X. You use PackageMaker to create packages, which are documents with extension .pkg that contain files to be installed and related files used during the installation. An Apple application called Installer reads the information from a package and performs the installation.

The two biggest tricks PackageMaker installations can do that disk images can't are installing files anywhere in the system, and running scripts while the installation is happening. To install files where you want them, you'll create a directory structure in your package that shows how you want files installed in the system, and includes a few extra items used by the installation itself. In order to run scripts, Installer defines certain events in the installation process and looks for scripts with names corresponding to those events. If the scripts exist, Installer runs them.

Let's take a deeper look at setting up your files and scripts for installation. Please gaze directly into the magazine.

You'll make a set of directories and files that indicates where you want everything to end up after the installation. The basic pieces of the directory structure are as follows:

• You'll create a directory that contains all the other directories and files in the package. This directory can have any name, such as "PackageContents" or "Fred". When you run PackageMaker, you locate this folder.

• Within the all-enclosing directory, you'll have a directory that holds various files used for installation, such as install-time scripts, the license and readme docs, and so on. Again, this directory can have any name - you specify it in PackageMaker.

• A second directory inside the outermost directory holds the files to be installed. They're arranged in directories according to the way you want them to be installed. When you run PackageMaker, you specify whether you the files can be installed anywhere or must be placed in absolute locations in the system.

Here's an example. Let's say we're going to install a package that consists of a music application, 3 system sounds, and a screen saver module. Our package directory structure would look like this:

PackageContents
   PackageRoot
      Applications
         Music2MyEars
      System
         Library
            Sounds
               sound1.aiff
               sound2.aiff
               sound3.aiff
            Screen Savers
               ears.saver
   PackageResources
      License.rtf
      ReadMe.rtf
      preflight
      preinstall
      postinstall 
      postflight

The files in the PackageRoot directory are the software itself. We want the files installed in specific locations. When we run PackageMaker to create the package, we can make sure that will happen.

The PackageResources directory is filled with files that will be used during the installation. These include the ReadMe and license documents, along with several scripts (preflight, preinstall, etc.) that Installer will run. In this example, our text files are RTF, but you can also use .txt or .html files.

When the user runs Installer, usually by double-clicking a .pkg file, these are the steps that take place:

• Installer looks in the package for an InstallationCheck script and runs it, if it's there. This script provides an opportunity to cancel the installation by returning a nonzero value.

• If there's a Welcome file (such as Welcome.rtf or Welcome.html), Installer displays it. Otherwise, a default Welcome screen appears. If there's a background image (a file named "background" with extension .tiff, .jpg, .gif, .pdf, or .eps), it's displayed behind the Welcome.

• If there's a ReadMe file (such as ReadMe.rtf or ReadMe.html), it's displayed next.

• Next, the License file is displayed.

• When the user gets to the Select a Destination screen, Installer runs the VolumeCheck script (if it exists) for each mounted volume. VolumeCheck can return a nonzero value to prevent a volume from being eligible for installation.

• After the user clicks Install, the preflight script is run. Like the other scripts, preflight can cancel the installation by returning a nonzero value.

• If the user is upgrading the package from a previous version, Installer runs the preupgrade script. Otherwise, preinstall is run.

• The package contents are copied to the destination. Actual installing, wow!

• If this was an upgrade, the postupgrade script is run. Otherwise, postinstall is run. There's still time to cancel the installation, which happens if these scripts return nonzero.

Installer runs the postflight script, if it's present.

As you can see from these steps, you have a chance to check the installation with many different scripts: InstallationCheck and VolumeCheck, preflight, preinstall or preupgrade, postinstall or postupgrade, and postflight. You should specify a shell in the first line of your script, using the !#/bin/sh convention. Installer provides a bunch of arguments and environment variables you can use in the scripts. For example, the first argument ($1) is the full path to the installation package, $2 is the path to the destination, and $3 is the mountpoint of the destination volume.

Once you have written the scripts you want, created the ReadMe and related files, and assembled everything in the right directories with your installation files, it's time to make the package itself. You do this by running PackageMaker, which is located in Developer/Applications/Utilities/. When you run PackageMaker, you see the lovely screen that appears in Figure 1. It's safe to say Jonathan Ive hasn't gotten hold of this one yet.

To start assembling your package, fill out the fields on the Description tab. The Title and Description fields provide a place for information that's visible to users when the Installer is running. Click the Files tab to specify the source location of the files to be installed. In our example above, this is the PackageRoot directory. Just to be macho, note that the field for the directory is editable text, so if you're really geeky and you hate clicking through a file dialog, you can actually type the directory path yourself.

Next, use the Resources tab to specify where the scripts, ReadMe, and similar files are located. In our earlier example, this was the PackageResources directory.

The Info tab provides a few interesting options. For example, you can choose whether to recommend or require a restart here. Restarting is mean and should be avoided whenever possible. (In Panther, you can also specify that logout is required, but you can't do it here: you have to modify the Info.plist to do so. To make this happen, add an "IFPkgFlagRestartAction" key with a value of "RequiredLogout" to the package's Info.plist.) If your software doesn't have to be installed in a particular location, check the Relocatable box and users will get to pick where your software should go. The last tab, Version, lets you specify info that appears in the Finder.

When you have your package just the way you want, you should save in PackageMaker, then choose File * Create Package to make the package. When you double-click the package, Installer will launch and you'll get the exciting display you see in Figure 2.

There are a few more Installer features that aren't available in PackageMaker. Instead, you have to edit the package's Info.plist file to get them. For example, when you include a background image in your package, Installer stretches it out to fill the entire window, which is ugly if the image has the wrong proportions. You can gain more control over how the image is used by editing the Info.plist file with Property List Editor.

In the package shown in Figure 2, the Info.plist file has two new keys added to it: IFPkgFlagBackgroundScaling and IFPkgFlagBackgroundAlignment, to make sure that that bee and that guy don't take over the screen. The first key, which controls how the image is scaled, is set to "none". You can also use "tofit" (the default) and "proportional". The second key, for alignment, is set to "bottomleft". Other valid alignments are "left", "right", "top", "bottom", "center" (the default), "topleft", "topright", and "bottomright".

PackageMaker has a few more tricks, such as the ability to create metapackages, which are packages that contain and install other packages. Metapackages can present and sort through complex sets of dependencies for installing software. Another cool feature is the ability to install packages across a network, which you can do if you have Apple Remote Desktop.

PackageMaker isn't the last word in installers. Lots of commercial software requires more control than you can get from PackageMaker and Installer. The best-known non-Apple installer packages are made by MindVision Software (InstallerVise, ViseX, and FileStorm), and Aladdin (StuffIt InstallerMaker). These applications let you do things that are beyond PackageMaker, such as creating installs that work on OS 9 or Windows, displaying multiple "tips" screens during install, and automatically adding items to the OS X dock. These products compete with free software from Apple, so they have to be feature-packed.

You can find out more, or even download whole manuals and applications, by visiting the web sites at www.mindvision.com and www.stuffit.com/mac/installermaker/. MindVision downloads are fully functional, with limits on the installers you build until you buy a registration key. The InstallerMaker download is fully functional, but produces installers that say you're using an unregistered copy.

Speaking of free stuff, Apple provides a pile of fine documentation on packages, PackageMaker, and related topics. For much more detail on the stuff we talked about in this article, check out the following URL:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution.

Have fun getting your installer together. Remember, no matter how hard you work on your application, nobody will be able to use it unless you produce an installer, disk image, or other trick to get it out into the world.

Scott Knaster has been playing with Apple computers, and occasionally working with them, since 1977. Wow, that's a long time! Scott has written books and articles for normal human beings as well as programmers. Photo of Scott and his friend Jollibee courtesy of John Vink Photography.