Skip to content

Configuration profiles

This directory contains the schema files describing every managed preference key that App Auto-Patch (AAP) 4.0 reads. They ship in three files because the macOS MDM ecosystem is split across two incompatible schema formats, and iMazing Profile Editor reads the ProfileCreator format from a .plist:

  • xyz.techitout.appAutoPatch.plist — the ProfileCreator / iMazing manifest as a property list, with the settings grouped in tabs that match the Settings window: Installomator, Deferrals, Advanced, About and Managed Only. Use this with iMazing Profile Editor, or copy it into the ProfileManifests repository (Manifests/ManagedPreferencesApplications). It is generated from the two JSON files by Scripts/manifests/build-plist-manifest.mjs, so edit the JSON and run that script instead of editing the plist by hand.
  • xyz.techitout.appAutoPatch.json — the same ProfileCreator manifest in JSON (uses pfm_subkeys / pfm_name / pfm_type / pfm_default keys), without the tabs. It is the source the plist is generated from. Use this with:
    • ProfileCreator
    • Intune Custom Configuration (when paired with the application’s preference domain xyz.techitout.appAutoPatch)
  • xyz.techitout.appAutoPatch.jamf.json — the equivalent in standard JSON Schema (uses properties / title / type / default / enum / items / minimum / maximum). Use this with:
    • Jamf Pro → Computers › Configuration Profiles › Application & Custom Settings › Upload → Custom Schema
    • Any other MDM that consumes JSON Schema rather than the ProfileCreator format All three files list the same AAP 4.0 keys, with the same defaults and constraints, in the order of the Settings window. Each title starts with its Settings section (for example Focus Deferral › Count limit), and keys with no Settings control are marked (managed only). Pick whichever format matches the editor your team is using. If you are deploying to Jamf Pro, the iMazing manifest will not import — Jamf only understands the Jamf schema.

Jamf Pro cannot group settings into tabs: its custom schema has no such option, and the only grouping it offers (nested objects) would write nested dictionaries into the profile, which App Auto-Patch does not read. The Jamf form is one long list in the same order as the Settings window, with the section in each title and the key name in the info text.

AAP 4.0 deliberately preserves the 3.5.0 preference domain and key names — including IgnoredLabels, RequiredLabels, and OptionalLabels. If you currently deploy a 3.5.0 configuration profile, deploying it against an AAP 4.0 install requires no edits.

The full mapping (with caveats) is documented in PreferencesComparison_3.5.0_vs_4.0.md at the repository root.

  • AutoResetHelperOnLaunch (default true) — automatic root-helper self-heal on app upgrade.
  • ShowMenuBarIcon (default true) — controls the menu-bar item.
  • TelemetryEnabled (default true) — anonymous usage signals. Set false to turn them off. The About toggle is disabled while this key is managed. Signals omit app names, user names, paths, and serial numbers. A finished patch includes how many applications it updated. A launch does not send its own signal.
  • UpdatesAvailableNotificationsEnabled (default true) — fires a single User Notification toast the first time a Check For Updates run surfaces new pending updates. Suppressed when AAP is in the foreground.
  • TemporaryNotificationTypes / PersistentNotificationTypes (build 59) — string arrays that reroute individual notification types between the main-app banner identity (xyz.techitout.appAutoPatch) and the embedded persistent-alert helper (xyz.techitout.appAutoPatch-persistent). Unlisted types keep built-in defaults (informational background-patch events temporary; action-required events persistent). If a type appears in both arrays, persistent wins. Allowed identifiers: backgroundPatchStarted, backgroundPatchCompleted, backgroundPatchFailed, updatesAvailable, acPowerRequired, deferralResuming, hardDeadlineReminder, selfUpdateAvailable.
  • DiscoveryFrequency — hours between automatic root-helper discovery + update checks. Unset or 0 leaves the schedule off. Mid-cycle runs refresh GUI/menu-bar inventory only; notify/dialog wait until NextAutoLaunch. Cadence reset always rediscovers immediately with the full notify/dialog path.
  • BackgroundPatchClosedApps* — periodic silent patching of apps that aren’t currently running. The full key set:
    • BackgroundPatchClosedAppsEnabled — master switch.
    • BackgroundPatchClosedAppsIntervalHours — cadence, 1–24 hours.
    • BackgroundPatchClosedAppsRequireOnAC — skip on battery.
    • BackgroundPatchClosedAppsAllowList / BackgroundPatchClosedAppsBlockList — staged rollouts.
    • BackgroundPatchClosedAppsNotifyOnCompletion — user notification around the background pass (start + completion).
    • BackgroundPatchClosedAppsScheduler — chooses which scheduler drives the cadence:
      • inApp (consumer default) runs an in-process timer; works while the AAP menu-bar item is alive.
      • helperDaemon (recommended for managed Macs) runs the schedule inside the persistent root LaunchDaemon, so background passes survive a user logout or a full quit of the AAP UI.
    • WorkflowStageUpdates (default true in 4.0; the 3.6 script defaulted this to false) — download each detected update’s installer before installing it, including before a background patch of closed apps.
    • BackgroundPatchStartupJitterMaxMinutes (default 0 = disabled) — staggers the first background-pass fire time across a fleet. Each Mac draws a random offset in [0, max] minutes on first launch, persists it for the cycle, and re-randomises after each successful patch. Recommended value for most fleets: 60–240.
  • Deferral enforcement keys (build 50 additions):
    • AggressivePatchDayDeferral (default false) — when true, shrinks the maximum deferral option offered on hard-deadline day as PatchingEndTime approaches. Past PatchingEndTime the prompt is bypassed and the update installs immediately.
    • PatchingEndTime ("HH:mm", default "17:00" when AggressivePatchDayDeferral is enabled) — end of the patching window used by the aggressive-cap logic.
    • DeferralTimerError (default 60 minutes) — how long to wait before another attempt after an Update All finishes with errors. Values below 1 wait 1 minute.
    • WorkflowUpdateAllErrorCompletesPatching (default false) — when true, that same Update All still marks the patching cadence complete until the next reset, and there is no retry.
  1. Import xyz.techitout.appAutoPatch.plist into iMazing Profile Editor, or xyz.techitout.appAutoPatch.json into ProfileCreator.
  2. Set the values you want to manage. Anything you leave unset will fall back to the on-device default documented in pfm_default (or to the user’s local preference if no MDM value is delivered).
  3. Sign and export the resulting .mobileconfig, then deploy via your MDM as a Custom Settings payload.

Approving the root helper daemon (com.apple.servicemanagement)

Section titled “Approving the root helper daemon (com.apple.servicemanagement)”

The Custom Settings profile generated above only configures App Auto-Patch’s preferences — it does not approve the root helper LaunchDaemon. To skip the manual Login Items & Extensions prompt for your fleet, deploy a separate com.apple.servicemanagement profile.

Pre-allowing notifications (com.apple.notificationsettings)

Section titled “Pre-allowing notifications (com.apple.notificationsettings)”

AAP posts macOS user notifications from two identities: the main app (temporary banners) and App Auto-Patch Notification (alerts that stay until acted on). By default macOS shows a system permission prompt the first time each identity tries to post. Deploy a com.apple.notificationsettings profile with both bundle IDs to pre-allow (or fleet-wide suppress) notifications and remove the prompt.