Just when most software had settled on using Apple’s Installer, along came the App Store to add to complexity. And then there’s Adobe with its own downloaders and installers again. So how should we install and update software?

The job of a software installer or updater should be simple: take a payload, typically a special package file that is actually a folder bundle containing the components needed, and copy those to the correct locations on the designated volume.

That is just what Apple’s Installer does, and until the latter days of Snow Leopard, it was the main game in town. Of course Apple system software and applications could also be updated through the Software Update pane in System Preferences, and there are a few third party and proprietary installers, but they tend to be vendor-specific, particularly those for Adobe’s products including Flash, Air, CC products, and now Acrobat DC.

Installer

Once notorious for turning well-running Macs into unbootable nightmares, Installer has come a long way since the first beta-release of OS X. However it is still at heart a Unix installer, with quite fixed ideas about where different software components belong.

For instance, an application that includes custom fonts must install them in the /Library/Fonts folder, or they will be rendered inaccessible; document templates and similar supporting files normally need to be placed in a folder within /Library/Application Support if they are to be made available to all users of that Mac.

Payloads to be installed or applied as updates can be provided as straight package files (.pkg), such as those which used to be delivered by Software Update, or placed within disk images (.dmg), as can be downloaded from support.apple.com/downloads/ and elsewhere. The latter are the recommended container for Installer packages, but there is nothing to stop them from being put into compressed archives or whatever you like.

One distinct advantage of using disk images (or an alternative archive format that has integrity checks) is that a truncated, damaged or corrupt disk image cannot be mounted and used. In contrast, it is possible for damaged Installer packages to be run, and this may explain why some installations and updates go awry. This should no longer happen with Gatekeeper, of course.

Inside the Package

More complex, multi-application installations can be delivered as several packages, orchestrated in JavaScript from a metapackage file (.mpkg). An Installer Package is a ‘bundle’ like an application that is really a folder pretending to be a file. It contains product information, including any licence file and version data, and a list of installation properties. The latter include system, volume, and authentication requirements, and the action to be followed after installation, such as forcing a restart.

In addition to the files required for the installation itself, there are up to four scripts (which can include faceless shell tools) to cover preflight, pre-installation, post-installation, and postflight. The installable payload normally consists of other packages (packages can be nested recursively), or a .pax.gz compressed archive.

Installing

In essence, Installer runs the preflight then pre-installation scripts, puts all the enclosed files in the specified locations, replacing existing files as specified, following which it runs the post-installation and postflight scripts.

The first phase of an installation or update consists of checking that the Mac on which this is to take place meets the requirements specified in the package. If it falls short, then Installer tells the user why the installation cannot proceed and goes no further.

The developer who produces the package may unwittingly allow installation on an unsuitable system, though: this commonly occurs when they have specified a minimum version of Mac OS X that is required, but do not exclude future major releases. You can thus happily install products designed for Leopard on Yosemite, although they could there prove badly broken.

Once Installer has determined that the installation can proceed, it runs the preflight script – or, in the case of metapackages, all preflight scripts from the .mpkg and its associated packages. After those, pre-installation scripts are run. If an error occurs during preflight or pre-installation, Installer informs the user and cancels the installation, leaving the host system unchanged.

This normally works perfectly, but if preflight or pre-install scripts encounter an error but do not handle it correctly, Installer will continue with an installation that could be doomed to failure.

With all preparations complete, Installer gets on with the main course, copying each and every file from the package to its designated location on the Mac. Here there is ample scope for programmer error, inadvertently wiping out key files belonging to other applications or system components, or misplacing vital files. When this is complete, the package file less its payload of files that have been installed is copied to the /Library/Receipts folder of the volume on which installation has taken place.

Although package receipts like this appear identical to their original packages, they lack the files that were actually installed and so cannot replace the original install package if you want to re-install, and are folders disguised as single files.

If you open one you can see its binary ‘bill of materials’ (.bom), a .dist script, and various of the scripts and other components that make up a distribution package. Because the .bom files in receipts specify the intended permissions of all the files and folders that have been installed, they are used by Disk Utility when you run it to repair permissions.

Before quitting, Installer runs post-installation and finally postflight scripts, and the installation or update is deemed complete. Most application installations and updates have to place (and/or remove) files from folders to which administrator or root access is required. Consequently, Installer has to prompt you to enter an administrator user name and password.

One way of streamlining this process when performing multiple installations is to load all packages before Installer has completed and quit, by double-clicking remaining packages or dragging them to the application icon whilst it is still running. Metapackages automate this for more complex distributions.

The (Mac) App Store

Then along comes the App Store and changes this local model for something away in the Cloud: gone are Installer Packages, indeed Installer does not get a look in any more. Applications and their updates are just downloaded and appear in your Applications folder.

The App Store has some neat twists, and enhanced security. It not only uses the obligatory code signing system with Gatekeeper, but also confines App Store apps to their own ‘sandbox’ to protect everything else from them, and to protect them from everything else.

App Store updates can also readily be made significantly smaller than a fresh installation, making more efficient use of bandwidth.

One of the major frustrations with Installer has been that the easy way to update each application has been to put a complete copy of the new version in the package. Although there is no reason that individual components within the whole application bundle could not be updated separately, in practice as there is no convenient tool for working out which need to be replaced, the simple course has been to replace everything.

App Store updates can consist of just a portion of the whole application, although this is not as common as it could be: every little update to Xcode or Apple’s huge Pro apps seems to require full-size downloads, for example. Ironically this was a technique last used back in Classic Mac OS, when Internet bandwidth was at a greater premium.

The App Store is also not free of bugs. It is not uncommon for downloads (fresh purchases or updates) to appear broken, making them hard to fix. Some updates seem not to ‘take’ properly, and may have to be installed several times before the Store reluctantly admits that they have been properly installed.

Although Apple has attracted a huge number of apps to its App Store, there are still plenty of others which still rely on Disk Images and/or Installer Packages, so Installer is not going to be redundant for a while yet.

Technique: Make Your Own Packages

Constructing Installer packages is not just for software developers. Using Apple’s PackageMaker, an accessory app provided with older versions of Xcode, anyone can build packages and metapackages to maintain the Macs that they look after. Apple calls these ‘managed installs’, and with the cover of Apple Remote Desktop, you can perform remote installs on multiple clients, such as the many Macs on a lab network.

PackageMaker used to be installed in the separate XcodeTools folder alongside Xcode, and has a straightforward interface centred on a single project window. However more recent versions have bundled packaging into the central core of Xcode, and PackageMaker no longer works under Yosemite: if you cannot use PackageMaker, see below for an excellent freeware alternative.

Prepare all the files that you need to install, in the correct folder hierarchy and bundled up into an .app as necessary. PackageMaker prompts you to create a new Installer package when it starts up, and requires specification of the minimum version of Mac OS X that a user can install on, and your organisation’s identity, normally its Internet address in reverse, such as co.eclecticlight.

Add components to be included in the left hand pane, including documentation files, and any Library additions. Selecting each in turn, complete entries in the Configuration, Contents, Components, and Scripts tabs. Each has extensive options that will have significant effects on the installation process.

For instance, enabling the checkbox to ‘Allow custom location’ will make Installer add another button that enables the user to select a different destination folder. Components that should be offered as optional installs are added as choices, for which you can determine additional options such as whether they are selected initially.

Finally select the package and work through its Configuration, Requirements, and Actions settings. Among Requirements, you can not only set essential needs, without which Installer will refuse to proceed, but Optional specifications; if the target system falls short of those, Installer will display a warning message but will complete the installation if the user wishes.

If you cannot locate and use an old version of PackageMaker, Stéphane Sudre has generously made his functional equivalent Packages freeware: full details and the download are available from here.

Tools: Third Party Products

Installer Packages are a minority pursuit, and complex, so there are relatively few third-party tools that work with them. The exception to this is with utilities to remove or uninstall software that has been installed by Installer – something Installer itself is often unable to accomplish.

Pacifist ($20 shareware) is the established alternative to Installer that allows you to open packages and install individual files or elements within them. Installer will list the files to be installed from a package, through the Show Files in its Files menu, but it is constrained by the options chosen by the person who built the original package.

If you inadvertently trash your QuickTime Player application, you may not want to re-install the whole of the latest edition of QuickTime. Instead, you can use Pacifist to selectively install just the Player application from your last QuickTime update (unless it came through the App Store, of course).

Not all software vendors use Installer Packages, and even if they do, they may offer their own installation management and updating tools. Microsoft now delivers standalone updates as Installer metapackages, but gives you the option of its own AutoUpdate application.

Adobe and other vendors who employ pervasive copy protection and licensing schemes end up with elaborate installation and updating techniques. In Adobe’s case, this may include Adobe Application Manager, which is buried deep an a maze of folders and files with cryptic names, within the /Library/Application Support/Adobe folder, Adobe Updater and most recently others including Akamai NetSession Interface.

Security: Where did you get that updater?

It looked for a long time as if Apple’s Gatekeeper signature system was going to provide complete protection from Trojans and other downloaded malware. However recent work by Patrick Wardle of Synack has shown that it currently has its own security holes. Further details are here.

The most important message is that you should only run installers which you can be confident are trustworthy, from reliable sources, and they must be downloaded using a secure connection, typically HTTPS or a direct secure link-up such as that provided by the App Store. It is now possible for hackers to put together Installer packages etc. which could sneak malware past Gatekeeper’s protection: beware!

Updated from the original, which was first published in MacUser volume 28 issue 14, 2012.