Apple
Head Nerds

Double Click to Install: Create a PKG even your users can install from

You’ve got a script. Maybe you wrote it or maybe you found it online, but it handily solves a problem your users face or does a task you typically spend several minutes on with a single command many times a day. With any RMM platform, it would normally be a simple matter of deploying the script to those devices, setting the schedule for it to run, then sitting back and sipping your beverage of choice. Unless you’re in the server roomno food or drink in the server room.

But what if the problem you’re solving is that Mac that can’t connect to the server? Or that its configuration is somehow corrupted and it won’t stay connected? Or, for that matter, the user is remote and you don’t have a remote management platform yet and need to install one.

You’ve wandered into a classic catch-22: in order to install or fix remote management, you need working remote management.

You could email the script to the user with instructions for running it in the Terminal, but that way lies madness. Terminal is scary. Nobody reads the instructions. And even when they do, there’s no way to anticipate every question you’ll get: “Do I include the quotation marks around my password? What is my password?”

No. You need to deliver something that any average user can double-click on and be reasonably confident it will run without a hitch.

Installing your new app

Aside from the occasional custom installer app, there are two primary ways in which a user installs applications on their Mac. The first is dragging the new app’s icon into the Applications folder. The second is launching the macOS Installer.app by double-clicking on a PKG file. The package format includes the ability to run scripts before and/or after the installation process. You can use this to your advantage even if you’re not actually installing anything. While building a full drag-and-drop application requires learning Xcode and Swift, all you need to create your own PKG installer is a Mac and your script.

I write most of my automations in Bash, or to be more precise these days, zsh. I still call them “Bash scripts” because I like to believe it makes me sound like I’m swinging a battle axe (“Script, bash!”). But a script deployed via PKG can be in any language the target Mac understands. AppleScript, Python, Ruby, PowerShell—if you are confident that a compatible interpreter is installed, use your weapon of choice. Just be sure to include the proper “shebang” line at the beginning (#!/bin/bash for example).

Once your script is tested and working, rename it to “postinstall” and put it into a folder called “scripts”.

Related Product

N‑central

Manage large networks or scale IT operations with RMM made for growing service providers.

Avoiding Terminal terror

The rest is done in Terminal. Do not be afraid. There are utilities that will do this part for you and add in some optional bells and whistles but, for our purposes, it requires just two commands.

Navigate to your scripts folder, the one with “postinstall” in it. That will need to be executable so it will run as part of the installation. Like so:

chmod a+x postinstall

Then, the magic incantation to create the package:

sudo pkgbuild –identifier your.unique.identifier –nopayload –scripts /path/to/scripts /path/to/package-name.pkg

Replace “your.unique.identifier” with a string that will identify you as the author in case someone examines the PKG. These are usually in the form of a “reverse domain name” like “com.example.installer” but really, it could be anything that’s unique. Also, fill in the paths for the scripts folder and where you want the PKG file to appear.

If you’ve done it right, you should end up with a file you can send to any user and have them double-click and install. The script will run, hidden behind the friendly façade of the system installer, with no need for them to launch Terminal or type in commands. They will need to remember their password though.

[Challenge for advanced students: Write your own script that automates this process!]

© N‑able Solutions ULC and N‑able Technologies Ltd. All rights reserved.

This document is provided for informational purposes only and should not be relied upon as legal advice. N‑able makes no warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained herein.

The N-ABLE, N-CENTRAL, and other N‑able trademarks and logos are the exclusive property of N‑able Solutions ULC and N‑able Technologies Ltd. and may be common law marks, are registered, or are pending registration with the U.S. Patent and Trademark Office and with other countries. All other trademarks mentioned herein are used for identification purposes only and are trademarks (and may be registered trademarks) of their respective companies.