An installer is often the first contact a user has with a new piece
of software. It is extremely important that developers provide
installers that are not only easy to use, but also make the fewest
assumptions about an individual user's administrative skills. This
article addresses installer policy, the "why" behind
the "how." Since the latter is already discussed in several documents
(which are referenced at the end of this article), here we consider
questions such as: Should the installer require a password? Are certain
parts of the system inappropriate for your software? What is the "best"
installation mechanism? How can tools such as PackageMaker support your
installer policy? Why should you care about remote installations or mass deployments? In
addition, we investigate BBEdit as an example of good installer policy.
If you are a software developer, you should read this article. Developers write software in order to release it. Releasing requires that you consider who will install your software, and how those people will accomplish this seemingly simple task. Remember that most or all of your target audience has not had the luxury of working with your product everyday for a long time, like you have, so they need some care and feeding to keep them happy.
Bundles, Packages, and Disk Images
This section discusses terminology specific to software packaging and installation on Mac OS X.
A bundle is a directory containing executable code and resources, such as readme files and images, that an application needs at runtime. Bundles appear as single, non-folder icons. Tools such as PackageMaker can easily create bundles from the build products of development environments like Xcode.
Bundles hide complexity, and reinforce the easy-to-use advantage of Mac OS X. This hiding means that less-savvy users will not understand that there is more to your software than just one icon. Often, this is a good thing because it reduces the likelihood of tampering with your file and folder contents.
A package is a bundle created using PackageMaker, which installs as part of the Xcode Tools suite at /Developer/Applications/Utilities/PackageMaker. PackageMaker constructs a single bundle (with a .pkg extension) containing files selected by the developer. The package metadata contains preferences set by the developer. For example, you can specify one of several authorization actions: none, admin, and root. See Figure 1.
Figure 1: Authorization Options in PackageMaker
The Mac OS X v10.4 Tiger release of PackageMaker includes multiple project types, as shown in Figure 2.
Figure 2: PackageMaker Project Options in Tiger
The references listed at the end of this article provide additional information about how to use PackageMaker.
A disk image is a virtual disk created from a folder on a physical drive. You create a disk image using /Applications/Utilities/Disk Utility. Files that were in the original folder appear and act the same as they do on any other disk. Disk images provide a virtual installation medium, whether the image includes one draggable bundle or an installer package.
Which Should You Use?
The simplest solution is often the best. If possible, let the user simply drag a bundle from a mounted disk image or CD to the appropriate location on a drive. Apple recommends this type of installation whenever possible. It is easily understood by the user, and requires very little work by the developer.
If you use a drag install, you can designate the initial application launch as an appropriate time to place files in specific locations. For example, the first time a user launches your app, necessary support files can be written to ~/Library/Application Support. You could also make this check each time the application is run. That way, if a user removes an important file, you can prompt the user to locate the file or have the application recreate it. For example, if a serial number file is missing, your application can enter Demo mode or refuse to run. This can protect against mass copying of your application's files, folders, and bundles without an appropriate product key.
Sometimes software has more complex installation requirements than can be handled with a drag install. For example, suppose your program has files that reside in multiple and/or restricted locations, such as both ~/Applications and /Library/Internet Plug-Ins. In this case you can create an installation package with PackageMaker. Double-clicking the package launches /Applications/Utilities/Installer.app, the native installer for Mac OS X.
Depending on the authorization action selected in PackageMaker, Installer.app may prompt the user for a password. This is not a trivial decision for the software author: selecting the wrong option may result in an install that dies part way through the process. This will manifest itself in the installer progress window as a failure message. Worse, Installer.app cannot back out gracefully or recover, so any installed files will remain in place.
For our plug-in example, a password should be required because /Library and its subdirectories are restricted. Admin Authorization is therefore the appropriate choice in PackageMaker. The choices are discussed further in the next section.
Passwords
Password requirements during software installation range from moot to root. Where no password is required, the user may install into any available folder, typically his or her home folder. A more restrictive requirement is that the user provide an administrator account password. (The first account created during system installation is granted administrator privileges.) The root account has the broadest range of privileges. The root account is disabled by default on Mac OS X, so it is more likely that the user performing the install will have administrator privileges.
Both the admin and root authorization options in PackageMaker allow Installer.app to run with root privileges, so admin authorization is just as good as root authorization. The difference is that if the user is logged in to an administrator account, and admin authorization is selected for the package, the user will not be prompted for a password.
The User's Perspective
Requiring a password during installation may appear to be a good security measure. But what does it imply to the user? That the installer wants permission to touch critical or restricted parts of the system. File systems and device drivers can justify a greater level of system access. But if that level of access is not needed, a password requirement just gets in the way and even undermines security. How? Because over time, if asked for the password regularly, a user may get lax about password security. If every time a user installs software he or she must provide a password, after a while it becomes second nature to just type the password in. If a malicious application then requests the password, the user doesn't think twice before entering it.
If an application only asks for the password when absolutely necessary, whether during installation or first launch, or when it needs to perform a task that requires raised permission, the user is more likely to question the need to enter the password. By making password requests a rare event, your software helps ensure that the user does not get complacent about providing the password.
Here's another thing to consider: How sophisticated is your installer audience? If something goes wrong during the installation, will someone have to intervene to remove files? You don't want the average user deleting files in unfamiliar areas. This decision depends in part on the folders that your software needs to install into, as discussed in the next section.
Appropriate Folders
In Mac OS X there are several important folders where you should not tread, and passwords are required. But there are also plenty of other locations to install software.
Off Limits
The folder /System is for Apple use only. It holds important operating system files, and everyone using the machine relies on this folder. Apple-provided system libraries and file systems live here. If you do not know if your software belongs in here, chances are that it does not. Mucking around in /System can lead to machine instability.
Use Only in Extreme Cases
The folder /Library contains files that extend the capabilities of the operating system. Files located here are shared among all users of the machine. If you write your own extension, such as a file system or Open Directory plug-in, and it absolutely must be available to everyone, it can go here. Or, if the user specified global availability during installation, then use it. Notice the emphasis on letting the user decide: do not assume that this is a good location.
The folder /Applications can be acceptable, but remember that it too is global, and requires a password.
If your software is multi-platform, try to accomodate your Mac OS X users by not using /etc, /usr/local, and so on, unless your software is only accessible via the command-line.
Better
The user's home folder and its subfolders are acceptable default locations because they do not require passwords. And they are easy to find using the Finder's navigation pane. ~/Library is the individual user's equivalent of the shared /Library, and is also appropriate for Open Directory plug-ins, widgets, and so on. (The tilde character ~ means "the home folder of the current user".) Various subfolders in ~/Library correspond to those in /Library. Files installed here are not shared among all users and, as mentioned above, this folder does not require a password.
By the way, "It's a big file and I don't want to waste user space" is not an excuse to use /Library instead of ~/Library: let the user decide that. This is especially true for advanced users who keep their home directory on a separate partition from the /System or /Library directories, or who live in a corporate network home directory environment (made more likely with Portable Home Directories in Tiger). The partition holding /System and /Library may be large enough to hold just the system, and wouldn't stand the bulk of 10s or 100s of megabytes of additional data that could just as easily live in ~/Library.
The folder ~/Applications is another good alternative. As with ~/Library, this folder is user-specific and password-free.
Best
It is best to allow the user to choose the destination folder. However, your installer might suggest one of the destinations mentioned above. Remember that even though your software may run fine anywhere on the system, these and other folders provide structure and consistency for the user, so it makes sense to use them appropriately.
Large Scale Deployments
In some environments software gets installed on more than one machine
at a time, possibly using specialized tools. Apple Remote
Desktop provides such a solution: it allows a system
administrator to install software from a central location to multiple
Macintosh computers on a network. In such large scale deployments, user
interaction should be minimized. The problems start when an installer
makes assumptions about where and how the software is being installed.
For example, not everyone who installs software watches the process from
start to finish. Lab administrators often must update hundreds of
machines. It is convenient for an administrator to be able to start the
installation from a single computer, let it run, and check back later
for a status update. You should take this into account if there is any
possibility that your software will be used in a school or
business campus setting. An installation process that requires physical access
to each machine, or continual intervention during the installation
(perhaps to provide a serial number), is not a good idea in such a
setting.
Try not to require serial numbers as part of the installation process. Instead, move serial number entry to the first application launch. Or make it a separate process that the administrator can perform in parallel with the installation.
One important test that you can perform, which will determine if your software package is mass-deployable, is to try and install it using installer from a command-line. If your software installs properly in this scenario, chances are that it will work with products such as Apple Remote Desktop. Type man installer at the command-line for more details.
Installer Plug-ins
Xcode 2.0 includes an Installer.app plug-in project
template, as shown in Figure 3. With it you can create the user
interface for an interactive installation process. However, relying on
this type of plug-in will cause problems if the user decides to install
from the command-line, because the command-line installer tool does not invoke
plug-ins (it has no graphical user interface). Plus, an interactive
process goes against the principle that a simple installation procedure
is best.
Figure 3: Xcode 2.0 Installer Project Template
BBEdit's Installer Policy
For a real world perspective on the best installation procedure, we asked long-time Mac-only developer Bare Bones Software, publisher of BBEdit, a
few questions about the company's installer experiences and policies.
ADC: I downloaded the BBEdit 8.x installer. It looks like a simple drag
install from a disk image. Was it always this easy? How did you decide
on this approach?
BB: Well, we've always tried to stay on the leading edge when it comes to
supporting Mac OS technologies and current best practices, and so our
installation process has evolved over time. The very first commercial
release of BBEdit (version 2.5, back in May 1993) was a simple
drag-and-drop installation from floppy disk.
In the intervening years, we experimented with self-extracting
compressed archives, and as BBEdit's feature set developed and grew, and
it became dependent on OS features that weren't guaranteed to be
present, we needed to develop a double-click installer (using Installer
VISE) which would make sure that all of the right components ended up in
the right place with minimal user intervention.
More recent versions of BBEdit have taken advantage of the packaged
application format, which is more complicated for the developer to
assemble, but easier for the customer—as in the early days, it's a
simple drag-and-drop installation, only this time there is really only
one item to drag to the right place.
Even with this simple process, some customers (particularly those coming
over from OS platforms with much more complicated installation protocols
that all but mandate the use of an installer) are confused by the
simplicity of the installation process.
ADC: Does the BBEdit installer require access to system folders? Did you make some software design
decisions in BBEdit that assisted with the installation process?
BB: As a user-space application, BBEdit doesn't require access to anything
in /System/. If you elect to install the 'bbedit' and 'bbdiff' command
line tools (which is an option the application offers the first time you
use it), then you will need to provide an administrator password
(because the tools live in the standard Unix /usr/bin/ directory).
Otherwise, it's not required.
Within BBEdit itself, we've made the application as self-configuring as
possible, and all of the important components needed by the application
live in the application package itself, so that they travel with it and
no secondary installation process is necessary.
ADC: Does BBEdit pre-position everything at installation time, or does
it set up some private folders or files (such as preferences) the
first time it runs?
BB: Since installation consists of simply dragging a file from one place to
another, there's no installation phase during which we pre-position
anything. Preferences and other supporting files and folders are set up
in the locations specified by current best-practices guidelines the
first time you run the application (and with modifications provided for
by a "first run" dialog box). However, there's no significant overhead
incurred by this process, since the absolute number and size of the
installed items is quite small.
ADC: Has the drag install reduced support costs, or provided other
tangible benefits to your company?
BB: Absolutely—we don't have to invest engineering and testing resources
in verifying an installer application, nor do we have to invest support
resources in dealing with unforeseen compatibility problems with same.
So there have definitely been tangible benefits in having the simplest
possible installation process.
ADC: Do your other products install the same way?
BB: All of our products—BBEdit, TextWrangler, Mailsmith, and Super Get
Info—install the same way.
ADC: Since so much software can be downloaded before purchasing, how do
you view the relationship between the installation and registration
processes? If I have a serial number
already, should the installer ask for that number before it proceeds
with the installation? Do customers respond more favorably to either
approach?
BB: Well, since we are ourselves customers of other software companies,
we're quite sensitive to what creates a positive impression, and so many
of our decisions are driven by the passionate desire to treat our
customers with the same respect and consideration that we ourselves
would want.
Toward that goal, we don't impose anything in the way of the evaluation,
registration, and update processes. Since our products are typically
purchased directly from us (or through our direct agent), registration
information is already in hand, and so no separate registration process
is necessary. Serialization of the software takes place the first time
you launch it, and even then is optional—if you decline to enter a
serial number, the software runs as a fully functional demonstration
version for 30 days after the initial launch. And I would have to say
that customers respond very well to this.
Also, since the software is activated with a serial number, we simply
distribute maintenance updates as full application installations that
simply require you to drag the application file to install it—no
patcher, no separate installation or verification, it Just Works. And
customers respond very well to that, as well.
ADC: What about upgrades? Do
you offer a separate upgrade installation, and how does it differ
from an original install?
BB: Well, our structure of supporting files isn't too complicated, and tends
to be pretty stable from one version to the next. When there are
changes, the application takes care of them the first time you start it
up, when it detects the old layout of supporting items. Major (paid)
version numbers require a new serial number, and won't accidentally
accept an old one, so the integrity of the demonstration and update
process is maintained.
ADC: An installer program often makes
assumptions about who is performing the installation, which can be
bad in a lab setting, or when multiple users share a machine at
home, and so on. We want to emphasize a "best" behavior for
the majority of cases. For example, when should an installer require
access to /System/Library/ and so on?
BB: I have to say that we have some
pretty strong feelings about how an installer should behave. We
understand that some low-level pieces of software must of necessity
install system-level software (usually device drivers). However, I know
of no reason why any third-party software should add, remove, or modify
files in any subdirectory of /System—aftermarket stuff should always
go in /Library.
Aside from that, I think that the simpler the installation process is,
with as much self-configuration done by the application as possible, the
better it'll be for both developers and users.
For More Information
Using the techniques discussed in this article, you can enhance your software's installation process. The ADC Reference Library documents below will help you find more specific information.
In addition to the reference documents, visit the Apple Remote Desktop home page.
Updated: 2005-07-07
|
