Quick start for admins

This is the shortest path from “I have an MDM” to “App Auto-Patch is keeping my Macs current”. It works with any MDM that can deploy a package and upload custom configuration profiles (Jamf Pro, Addigy, Kandji, Mosyle, Microsoft Intune, Workspace ONE and others). A first pilot is mostly editing and uploading five files. You do not need to understand every setting first: this page uses sensible starting values, and the deeper pages are there when you want to change something.

Short on time? Do the five steps in order. Everything else on this site is reference material you can come back to.

Words you will see

• MDM: the tool you use to manage your Macs.
• Configuration profile: a .mobileconfig file you upload to your MDM. It tells macOS to allow something or sets preferences, with no prompt for the user.
• Payload: one block of settings inside a profile.
• Root helper: a small background program (a LaunchDaemon) that App Auto-Patch installs so it can update apps without asking for an administrator password.
• Team ID: the Apple developer identity that signed the app (6GBSVT64FS for the official download). Profiles use it to recognize the real App Auto-Patch.

What you will deploy

One package and four profiles. Each profile has an example file you can start from.

1. The installer package: download it.
2. Approve the helper. Without this, every Mac asks its user to approve the helper in System Settings. Example: com.apple.servicemanagement-AppAutoPatch.example.mobileconfig.
3. Allow notifications. Without this, users see a permission prompt. Example: com.apple.notificationsettings-AppAutoPatch.example.mobileconfig.
4. Allow App Management (privacy permissions). Without this, macOS 15 and later either prompts the user or silently skips an app update. Example: com.apple.TCC.configuration-profile-policy-AppAutoPatch.example.mobileconfig.
5. Baseline settings. Starting values for how App Auto-Patch behaves on your fleet. Example: xyz.techitout.appAutoPatch.baseline.example.mobileconfig.

Step 1: Download the files

1. Download the installer from the Download page. Your MDM may want a link instead of a file: https://downloads.appautopatch.app/AppAutoPatch-latest.pkg always points at the newest build. The package is signed and notarized by Apple.
2. Download the four example profiles listed above (the links are on this page).

Step 2: Edit the profiles

Open each profile in a text editor (or your MDM’s profile editor) and change:

• PayloadUUID: every payload needs its own unique value. Run uuidgen in Terminal to make one, and replace each example value.
• PayloadOrganization: your organization’s name.
• In the baseline profile only: your support team’s name, email, phone and website, and the settings you should decide for your fleet: which day each patch cycle starts, how many days before an update is required, which apps to leave alone, and whether users can change settings at all (see what the baseline does).

Leave the Team ID (6GBSVT64FS) alone when you deploy the official download. Only change it if you build App Auto-Patch yourself and sign it with your own Apple developer account.

Check a file before uploading it:

plutil -lint "xyz.techitout.appAutoPatch.baseline.example.mobileconfig"

It should print OK. Most MDMs sign the profile for you when they deliver it.

Step 3: Upload to your MDM

Add all four profiles as custom profiles (some MDMs call this “upload a .mobileconfig”), and add the package as a software or package deployment. Menu names differ between MDMs and versions, so look for those words.

• Order matters a little. Deliver the profiles first, or at the same time as the package, so users never see a prompt. If the helper was installed before its approval profile arrived, see the recovery steps.
• Start with a pilot. Scope everything to a few test Macs first.
• Jamf Pro: upload each .mobileconfig under Computers, Configuration Profiles. To manage settings with Jamf’s own editor instead, use the Jamf custom schema, xyz.techitout.appAutoPatch.jamf.json, with the preference domain xyz.techitout.appAutoPatch. Jamf lists the settings in one long form, in the same order as the Settings window (Jamf cannot show tabs); the info icon next to each setting shows its key name. To keep App Auto-Patch itself current with a Jamf patch policy, add the Jamf Pro patch source.
• Addigy, Kandji, Mosyle, Microsoft Intune, Workspace ONE: upload each .mobileconfig as a custom profile, and deploy the package as a custom app or software item. You do not need ProfileCreator or iMazing.
• If you prefer to build your own settings profile: import xyz.techitout.appAutoPatch.plist into iMazing Profile Editor, or xyz.techitout.appAutoPatch.json into ProfileCreator. The settings are grouped in tabs that match the Settings window. See Configuration profiles.

Step 4: Check a test Mac

On a pilot Mac, once the profiles and the package have arrived:

1. Helper approved. Open System Settings, General, Login Items & Extensions. App Auto-Patch is listed under Allow in the Background, switched on, and shows that your organization manages it.
2. Privacy allowed. System Settings, Privacy & Security, App Management lists the helper as managed by your organization.
3. No prompts. Open App Auto-Patch. The first-run setup skips the helper approval step, and notifications do not ask for permission.
4. Settings applied. In App Auto-Patch, open the About tab: your support details are shown, and Settings says it is managed by your organization.

If something does not look right, each of these pages has a detailed “Verifying” section: helper approval, notifications and App Management. You can also generate a diagnostic bundle and send it with your report.

Step 5: Roll out

When the pilot Macs look good, widen the scope in your MDM. To change a setting later, edit the baseline profile and push it again: a managed value overrides the matching control in App Auto-Patch’s Settings window, and users cannot change it.

What the baseline does

Everything not listed here keeps its built-in default. The values are a starting point; change them to suit your fleet.

Installomator

• InstallomatorVersion: main, the default, set so the profile states where Installomator comes from.
• InstallomatorOptions: BLOCKING_PROCESS_ACTION=prompt_user asks the user to close a running app before it is updated, so nobody loses unsaved work. NOTIFY=silent and LOGO=appstore keep Installomator’s own notifications quiet, and IGNORE_APP_STORE_APPS=yes also manages apps that came from the Mac App Store.

Background patching and discovery

• BackgroundPatchClosedAppsScheduler: helperDaemon. The one we recommend for managed Macs: updates to apps that are not open keep running after a user quits the app or logs out.
• DiscoveryFrequency: the root helper looks for updates every 24 hours. The automatic schedule is off unless this key is set.
• AutoResetHelperOnLaunch: restart the helper by itself if it stops responding (the default).

How long users can put updates off (your decision)

• PatchWeekStartDay: the patch cycle starts on Tuesday (3). 1 is Sunday and 7 is Saturday. The original 3.x script counted Monday as 1, so check any value you carry over.
• DaysUntilReset: a weekly patch cycle (7 days).
• DeadlineDaysFocus: automatic focus deferrals stop 2 days into the cycle. DeferralTimerFocus is how long each one lasts (15 minutes). IgnoreDNDApps lists processes (Google Chrome,caffeinate) that do not count as a reason to hold an update back.
• DeadlineDaysHard: updates are required 3 days into the cycle, whatever the user chose. Remove this key if you never want to force an update.
• AggressivePatchDayDeferral: on the deadline day, the deferral choices get shorter as the end of the patching window nears. PatchingEndTime sets that end (17:00 unless you change it); after it no deferral is offered.
• DeferralTimerDefault: the update prompt returns after 1440 minutes (one day) when a user defers. DeferralTimerMenu offers 30 minutes up to 3 days.
• DialogTimeoutDeferral and DialogTimeoutDeferralAction: a dialog nobody answers closes after one hour and defers. DeferralDialogPrimaryButton makes Defer the default button, so a stray Return key press does not start an install.
• DeferralTimerError: wait 60 minutes before trying again after an Update All finished with errors.
• HardDeadlineDialogAllowClose: users can close the required-update dialog after a hard deadline. The countdown keeps running and reminders still appear.

Which apps are managed

• IgnoredLabels: microsoft*, googlechrome*, jamfconnect, zoom*, homebrew, firefox* and 1password*: apps that update themselves or that other tools manage. Edit the list to match your fleet.
• IgnoreExternalDrives: skip apps on external drives and disk images.
• VersionComparisonMethod: IS_AT_LEAST, the default.
• DiscoverSelfUpdateLabel: off, so App Auto-Patch itself does not appear in the list of apps to update. Use this when your MDM updates App Auto-Patch. Leave the key out if you want App Auto-Patch to show up in the list.

Locked down on the Mac

• LockSettings: users cannot change any setting.
• ManagedSilentLaunchEnabled: App Auto-Patch stays in the menu bar with no Dock icon.
• MenuBarConcealAdvancedActions and MenuBarHideQuit: Settings is hidden until a user holds Option, and Quit is removed from the menu bar menu altogether.

Your details

• SupportTeamName, SupportTeamEmail, SupportTeamPhone and SupportTeamWebsite: shown on the About tab. Replace the placeholders.

The profile also has a commented-out section of optional extras, such as turning off anonymous usage data, spreading the first background pass over your fleet, or limiting installs to business hours.

Check before you deploy

A few of these choices matter more than the rest:

• Settings are locked and Quit is hidden. Users cannot change App Auto-Patch’s behavior or quit it. Remove LockSettings and MenuBarHideQuit to give users that control.
• The patch cycle starts on Tuesday. Change PatchWeekStartDay if your patching week starts on another day.
• The deadline day ends at 17:00. AggressivePatchDayDeferral uses PatchingEndTime, which defaults to 17:00. Set it if your working day ends at another time.
• The ignored apps are an example. Check IgnoredLabels against the apps you actually manage elsewhere.
• App Auto-Patch is hidden from its own list. With DiscoverSelfUpdateLabel off, the app does not offer to update itself there, and self-update (SelfUpdateEnabled) is off by default, so deploy new builds with your MDM.

Common questions

Where do I find the manifests (xyz.techitout.appAutoPatch.json and friends)? They are downloads on this site: xyz.techitout.appAutoPatch.plist (for iMazing Profile Editor, with settings grouped in tabs), xyz.techitout.appAutoPatch.json (for ProfileCreator) and xyz.techitout.appAutoPatch.jamf.json (for Jamf Pro). If you use the baseline profile above you do not need any of them.

I want to see every setting. The Preferences reference lists all of them, with defaults and allowed values.

I am upgrading from the original (3.x) script. Your existing profile keeps working with no edits. See Migrating from 3.5.0.

I need something more unusual. See the advanced guides: per-user LaunchAgent and custom Installomator.

Something went wrong. See Reporting issues. Please say that you are using App Auto-Patch version 4 and include the exact version and build.