Skip to content

Installation

Jump to bottom
Gil Burns edited this page Jul 18, 2026 · 15 revisions

Installation

Third Party Patcher is distributed as a signed and notarized .pkg installer.

What the Installer Does

The package installs three command-line binaries and a LaunchDaemon:

File Destination
patcher /usr/local/bin/tpp/patcher
patcherscheduler /usr/local/bin/tpp/patcherscheduler
patcherreport /usr/local/bin/tpp/patcherreport
LaunchDaemon plist /Library/LaunchDaemons/com.gilburns.patcher.scheduler.plist

The postinstall script loads the LaunchDaemon immediately:

/bin/launchctl bootstrap system /Library/LaunchDaemons/com.gilburns.patcher.scheduler.plist

On upgrade, the preinstall script unloads the existing daemon first so binaries can be replaced safely.

Deploying via MDM

Deploy the Patcher PPPC:

  1. Upload the provided Available Software_PPPC.mobileconfig to your MDM or if using Intune, upload the Available_Software_Settings_Catalog_PPPC.json.
  2. Scope it to the machines you intend to install Patcher.
  3. Deploy your PPPC configuration profile before the package.

Deploy the Patcher configuration:

  1. Create and Deploy your Patcher configuration profile before the package (see Preference Keys). (Optional. Without this, it should operate with all the built in default settings.)

Deploy the Package:

  1. Upload Third_Party_Patcher-<version>.pkg to your MDM as a managed package.
  2. Scope it to the machines you want to patch.
  3. Deploy your configuration profiles before the package (see Preference Keys).

The daemon starts automatically at install and runs every 10 minutes. Nothing else is required for basic operation.

[!WARNING] Startup Delay The default behavior for Third Party Patcher is a random delay up to 24 hours before it actively starts scans, checks, staging and applying. This is intentional for environments with many devices. This will prevent a situation where all the devices start hammering the network all at once.

If you are installing it on a single device for testing, the recommendation would be to apply this preference to the device to disable this behavior:

sudo defaults write /Library/Preferences/com.gilburns.patcher InitialScanDelayEnabled -bool false

Prerequisites

Requirement Notes
macOS 14 Sonoma or later
swiftDialog Required for user-facing prompts. Use patcher ensure in your workflow or deploy it separately.
Network access to GitHub For Installomator label updates and app downloads. Required unless you supply only Managed Labels.

Installing swiftDialog Automatically

patcher ensure dialog checks whether swiftDialog is present and installs or updates it via if needed:

sudo /usr/local/bin/tpp/patcher ensure dialog

This is safe to include in a postinstall script or as a separate MDM policy.

You can also simply include dialog in your RequiredLabels preference key.

Directory Layout After First Run

After the scheduler runs its first scan, it creates the following layout under /Library/Application Support/Patcher/:

Patcher/
├── Cache/
├── Config/
│   └── config.json
├── Discovered/
│   └── <label>.plist        # one file per discovered app
├── Installomator/
│   ├── Labels/              # downloaded .sh label files
│   └── Version.txt
└── Managed/
    ├── Labels/              # your custom label files (optional)
    └── Version.txt

Finder window showing the Patcher Application Support layout

Uninstalling

# Stop and remove the daemon
sudo launchctl bootout system/com.gilburns.patcher.scheduler
sudo rm /Library/LaunchDaemons/com.gilburns.patcher.scheduler.plist

# Remove the binaries
sudo rm -rf /usr/local/bin/tpp
sudo rm -rf "/Applications/Available Software.app"

# Remove data (optional — removes history)
sudo rm -rf "/Library/Application Support/Patcher"
sudo rm -rf /Library/Logs/Patcher

Clone this wiki locally