-
Notifications
You must be signed in to change notification settings - Fork 3
Installomator Integration
Third Party Patcher uses Installomator label files to identify, download, and install third-party applications. Each label is a zsh fragment that defines variables like name, type, downloadURL, expectedTeamID, and appNewVersion for one specific application.
Third Party Patcher does not use the Installomator script itself as a black box — it reads the label files directly to discover apps and check versions, then invokes the patcher binary for the actual installation step.
Labels are stored at:
/Library/Application Support/Patcher/Installomator/Labels/
/Library/Application Support/Patcher/Installomator/Version.txt
The Version.txt file contains the git commit hash of the Installomator release the labels were pulled from. Patcher compares this hash to the latest release on GitHub to decide whether to update.
On each scheduler wake, Patcher checks the configured GitHub repository for a newer release of the labels. If a new version is available, it downloads and extracts the updated label files.
Configuration:
| Key | Default | Description |
|---|---|---|
InstallomatorGitHubAccount |
"Installomator" |
GitHub account |
InstallomatorGitHubRepo |
"Installomator" |
GitHub repository |
InstallomatorGitHubBranch |
"main" |
Branch to pull from |
InstallomatorUpdateDisable |
false |
Disable automatic updates while keeping existing labels |
InstallomatorLabelsDisable |
false |
Disable Installomator entirely; rely solely on Managed Labels |
Tip: Point to your own fork of Installomator using
InstallomatorGitHubAccountandInstallomatorGitHubRepo. This is useful if you need to pin to a specific version or maintain customized labels centrally without using the Managed Labels feature.
Set InstallomatorLabelsDisable to true if you want to manage labels entirely yourself via Managed Labels:
<key>InstallomatorLabelsDisable</key>
<true/>When this is set, Patcher will not download, update, or read from the Installomator Labels folder. Only your Managed Labels are used. If no Managed Labels are present, the scheduler will log a warning and skip all phases that require labels.
Patcher tracks a combined "effective labels version" that incorporates both the Installomator version and the Managed Labels version (see Managed Labels). When either changes:
-
ScanOnLabelUpdatetriggers an immediate scan (if enabled). - Any labels that previously failed to resolve (broken labels) are rechecked.
This means that updating your Managed Labels Version.txt is sufficient to force a recheck of previously broken labels in your managed set.
Patcher evaluates each label in a sandboxed zsh environment to extract metadata without running the full Installomator installation flow. The INSTALL variable is set to "force" to suppress tool helper execution during evaluation.
Fields extracted per label:
| Field | Use |
|---|---|
name |
Display name |
appName |
.app bundle filename for discovery |
targetDir |
Install location (if non-standard) |
appNewVersion |
Latest available version |
appCustomVersion |
Function to determine installed version |
expectedTeamID |
Code signature validation |
blockingProcesses |
Process names that must not be running during install |
type |
Installer type (pkg, dmg, zip, etc.) |
downloadURL |
Direct download URL |
Occasionally a label may report a newer appNewVersion that doesn't correspond to what is actually installed after applying. This can cause Patcher to repeatedly download and discard the installer on every stage cycle (the Spotify problem).
When Patcher detects that a staged install did not bring the installed version to the expected version, it activates a throttle for that label:
- The label is skipped during stage for
VersionMismatchThrottleDays(default: 3 days). - The throttle is automatically cleared when the label reports a different
appNewVersion, indicating a genuine new release is available.
Configuration:
| Key | Default | Description |
|---|---|---|
VersionMismatchThrottleDays |
3 |
Days to suppress re-staging after a version mismatch |
IgnoredLabels — Skip specific labels entirely, even if the app is installed:
<key>IgnoredLabels</key>
<string>adobe* microsoftteams googlechrome</string>Wildcards (*) are supported. Useful for apps managed by other tools (Munki, Mosyle Apps, etc.).
RequiredLabels — Always manage specific labels, even if the app is not currently installed:
<key>RequiredLabels</key>
<string>zoom slack microsoftteams</string>No wildcards. Use this to ensure critical apps are always present and up to date.
When IgnoreManagedApps is true (the default), Patcher automatically reads vendor-specific MDM configuration plists at runtime and excludes those apps' labels from patching if their updates are already centrally managed.
This avoids a conflict where both MDM and Patcher attempt to update the same app, and prevents double-download overhead for apps that are already up to date via their own update mechanism.
| Vendor | MDM plist | Key inspected | Managed when… |
|---|---|---|---|
| Microsoft 365 / Office | /Library/Managed Preferences/com.microsoft.autoupdate2.plist |
HowToCheck |
Key is present and value is not "Manual" (e.g. "AutomaticDownload") |
| Microsoft Edge | /Library/Managed Preferences/com.microsoft.EdgeUpdater.plist |
updatePolicies → global → UpdateDefault |
Value is 0 (disabled) or 1 (automatic silent) |
| Google Chrome | /Library/Managed Preferences/com.google.Keystone.plist |
updatePolicies → com.google.Chrome → UpdateDefault, falling back to global
|
Value is 0 or 1
|
| Google Drive | /Library/Managed Preferences/com.google.Keystone.plist |
updatePolicies → com.google.GoogleDrive → UpdateDefault, falling back to global
|
Value is 0 or 1
|
When a vendor is detected as managed, its full set of related Installomator labels is appended to the ignored list for that run. This is equivalent to adding them manually to IgnoredLabels but requires no configuration and adapts automatically if the MDM policy is later removed.
To disable the automatic detection and manage the ignore list yourself, set IgnoreManagedApps to false.
Some vendors publish separate Installomator labels for beta/canary/dev release channels alongside their production label — e.g. Microsoft Edge ships microsoftedge, microsoftedgebeta, and microsoftedgedev. When IgnoreNonProductionLabels is true (the default), Patcher automatically ignores a label if its name ends with one of the suffixes in NonProductionLabelSuffixes and a label with the same base name (the suffix stripped off) also exists.
<key>IgnoreNonProductionLabels</key>
<true/>
<key>NonProductionLabelSuffixes</key>
<string>beta canary dev</string>With the defaults above, microsoftedgebeta and microsoftedgedev are ignored because microsoftedge is also a known label. A label like figma is untouched since it has no matching suffix, and a hypothetical label such as somethingbeta is left alone if something does not also exist — this guards against a label whose name simply happens to end in one of the suffixes.
This check runs against the full set of available Installomator (and managed) labels, not just apps discovered as installed, so it takes effect on the very first scan.
To disable the automatic detection and manage non-production labels yourself via IgnoredLabels, set IgnoreNonProductionLabels to false.
Some apps have two separate Installomator labels for the exact same app, differing only in installer/delivery mechanism — one that installs a .app directly and one that installs via a .pkg (the pkg-suffixed label). BBEdit is an example: bbedit and bbeditpkg. Running both would just update the same app twice, so Patcher always ignores one side of the pair automatically.
PreferPkgLabels (default true) decides which side wins whenever a label and its pkg-suffixed counterpart both exist:
<key>PreferPkgLabels</key>
<true/>-
true(default) — the pkg-suffixed label (bbeditpkg) is kept; the non-pkg label (bbedit) is added to the ignored list. -
false— the non-pkg label (bbedit) is kept; the pkg-suffixed label (bbeditpkg) is ignored instead.
Like non-production filtering, this runs against the full label catalog, and RequiredLabels can still override it for a specific label if needed.