Anthony’s Mac Labs Blog

📦 Generic App-Packaging Recipes for AutoPkg

Posted 2018 November 17

One of the MacAdmin-friendly features I love about the app Packages by Stéphane Sudre is Quick Build: the ability to build a package installer for a self-contained app by simply dragging-and-dropping that app onto the Packages app. If you’re using a software distribution system that wants package installers, this can be a great time saver. But if you’re reading this, you’re probably an AutoPkg user and have automated creating package installers using app-specific recipes (either your own or those written by others). Still, sometimes you need to build such a package once or twice, so writing a recipe doesn’t actually save you time.

In doing the background work for my previous post on running a recipe with the --pkg option, I wondered if AutoPkg could package up any app on demand like Packages does. It turns out that it can. Here’s how.


I’ve added two new recipes to my repo: PackageApp.pkg and PackageDmgApp.pkg. The whole point of them is to replicate the Packages Quick Build feature. The two recipes differ in only one respect: PackageApp expects you to supply the path to the app bundle whereas PackageDmgApp expects the path to the disk image that contains the app.

If you have trust verification turned on (and you should), you’ll want to create an override for each of these recipes. Since neither recipe uses any input variables, you won’t need to edit the overrides. Of course, you will need my jazzace-recipes repo downloaded to your local RecipesRepo.

Here’s probably the simplest way to use the PackageApp recipe:

  1. In Terminal, type autopkg run PackageApp.pkg --pkg (making certain there is a space after --pkg).
  2. Locate the app you want to bundle up into a package installer in the Finder and drag-and-drop it onto the Terminal window. (Terminal will enter the path to the app automatically.)
  3. Press Return.

The package will be built and placed in your AutoPkg Cache under the identifier of the recipe (e.g., local.pkg.packageapp if you created an override). Because you are doing this on demand, the recipe asks AutoPkg to build the package every time, even if there seems to be an identical package in the cache.

The workflow for the PackageDmgApp.pkg recipe is the same, except you drop a disk image (with an app inside) on the Terminal window—AutoPkg will automatically mount the disk, extract the app, and then dismount it. This is probably the best use case, since Packages requires that you drag the app onto it (which means you have to manually mount the disk image first).

Output Differences Between Packages and AutoPkg

These recipes rely on the AppPkgCreator processor introduced in AutoPkg 1.0.0. At first glance, it appears that the packages generated by that processor are the same as those generated by the Packages app. But there are a few minor differences in the metadata that may interest Mac Admins:

  Packages app AppPkgCreator (AutoPkg)
PackageFileName AppName.pkg AppName-version.pkg
PackageIdentifier company.qb-pkg.AppName
e.g., org.mozilla.qb-pkg.firefox
e.g., org.mozilla.firefox
PackageVersion 1.0 or Bundle Version (preference setting) CFBundleShortVersionString
InstallPrefixPath blank /

These are the values you will find in the installer receipt (/var/db/receipts)—the values in the left column are the keys in the related plist stored there. The actual payload is the same; neither method messes with the app bundle.


The limitations of this ad hoc AutoPkg packaging method are not numerous but are worth noting:

When It Absolutely, Positively…

Most of the time, you’ll want to write a proper pkg recipe so that you can take advantage of the extra security you get from Code Signature Verification. But when you have something from a trusted source that you need to get packaged now, AutoPkg can do the job for you using these new recipes.