App Installer

What the Mac application installer does

This Automox Worklet™ installs a macOS application on Mac endpoints from a PKG installer or a DMG image. You upload the installer file to Automox alongside the policy and edit three variables in remediation.sh: the installer filename, the .app bundle name, and (for DMGs) the mounted volume name. The Automox agent stages the installer in its working directory at runtime, and the Worklet routes to the matching install path based on the file extension.

For PKG installers, the Worklet calls installer -pkg "$installer" -target / and then verifies that /Applications/$app exists. For DMG images, it runs yes | hdiutil attach -noverify -nobrowse "$installer", copies the .app bundle from /Volumes/$mountPath into /Applications with cp -r, and detaches the volume with hdiutil detach. Either path prints whether the bundle was successfully installed based on a final directory check.

The evaluation script is intentionally minimal: it tests whether /Applications/$app exists as a directory and exits 1 if it does not, which marks the endpoint for remediation. If the bundle is already present, the script exits 0 and the endpoint is skipped. This evaluation is optional and exists so the policy can reinstall the application if a user removes it.

Why automate PKG and DMG installs across your Mac fleet

Many Mac applications are not distributed through the App Store and do not ship with a vendor MDM package. The vendor publishes a PKG installer or a DMG image and expects each user to open it. For a fleet of laptops, that handoff is the bottleneck: the security team approves the install, the help desk sends the link, the user double-clicks the DMG, drags the app to Applications, and forgets to eject the volume. The deployment lands in days, not minutes, and install state across the fleet is inconsistent.

Distributing a vendor PKG or DMG without an Automox policy means either standing up Jamf Pro, building a custom MDM workflow, or an admin connecting to each Mac with the installer in hand. Apply this Worklet through the policy that already covers your macOS endpoints, attach the vendor installer to the policy, and the same install runs on every Mac in scope. The result is consistent across developer laptops, design workstations, and lab Macs, with each install reported back to the Automox activity log.

How PKG and DMG installation works

1. Evaluation phase: The Worklet reads the app variable (the full .app bundle name, for example "Slack.app") and runs test -d /Applications/$app. If the directory exists, evaluation exits 0 and the endpoint is reported compliant. If the directory is missing, evaluation exits 1 and the endpoint is flagged for remediation.

2. Remediation phase: The script validates that the installer variable ends in .pkg or .dmg and exits early if it does not. For a PKG, it calls installer -pkg "$installer" -target /. For a DMG, it runs yes | hdiutil attach -noverify -nobrowse "$installer", copies "$mountPath/$app" into /Applications with cp -r, then runs hdiutil detach "$mountPath". Both paths finish with a directory check on /Applications/$app and print whether the install succeeded.

Mac installer policy requirements

• Mac endpoint with bash, installer, hdiutil, and cp available on the default path (every supported macOS release ships with these)

• Root privileges for the Automox agent (the default agent context already meets this) to run installer -pkg and write to /Applications

• The PKG or DMG file uploaded to Automox and attached to the policy so the agent stages it locally before remediation.sh runs

• Three variables edited in remediation.sh: installer (filename with .pkg or .dmg extension), app (full .app bundle name, case sensitive), and mountPath (volume name when installing from a DMG)

• Notarized installers preferred; non-notarized payloads will be rejected by Gatekeeper unless the developer ID has been allowlisted through your MDM

Expected Mac state after installation

After successful remediation, /Applications/$app exists on the Mac endpoint and the script reports "$app has been successfully installed." in the activity log. The application is registered with launchd as if a user had opened the PKG or dragged the bundle from the DMG. For DMG-sourced installs, the mounted volume is detached and no /Volumes entry remains.

Validate the install by listing /Applications on a remediated endpoint and confirming the new bundle appears, or by reading /Applications/$app/Contents/Info.plist with /usr/libexec/PlistBuddy to capture the CFBundleShortVersionString and CFBundleIdentifier values for audit evidence. If the script reports "$app was not successfully installed.", the most common causes are a mismatch between the app variable and the actual bundle name (case sensitive), a mismatch between mountPath and the DMG's volume label, or a Gatekeeper rejection on a non-notarized installer.