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 ImagesThis 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 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 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 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 Depending on the authorization action selected in PackageMaker, For our plug-in example, a password should be required because PasswordsPassword 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 The User's PerspectiveRequiring 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 FoldersIn 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 LimitsThe folder Use Only in Extreme CasesThe folder The folder If your software is multi-platform, try to accomodate your Mac OS X users by not using BetterThe 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. By the way, "It's a big file and I don't want to waste user space" is not an excuse to use The folder BestIt 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 DeploymentsIn 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 Plug-insXcode 2.0 includes an Figure 3: Xcode 2.0 Installer Project Template BBEdit's Installer PolicyFor 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 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 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 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 InformationUsing 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 |