Release notes

The most recent builds of App Auto-Patch 4, newest first. Earlier builds are in the release archive. Get the current build from the Download page.

Build 91

Released October 14, 2026

Changed

Webhook cards include the app and Installomator versions. Slack and Teams summaries list Version after the computer name. That value is the installed app’s marketing version and build, such as 4.0.0 (91), read from App Auto-Patch.app. Installomator is the bundled script’s VERSION and VERSIONDATE, such as 10.8 (2026-10-01). A missing script or assignment is Unknown. The operating system fact is labeled macOS, and the words Version and Build are left off, so Version 26.7.1 (Build 25G241) is shown as 26.7.1 (25G241).

Build 90

Released October 14, 2026

Changed

Patch counts replace launch signals. A finished patch sends how many applications it updated. A background pass sends AppAutoPatch.Patching.Background.completed. A patch started from the app sends AppAutoPatch.Patching.completed. The number is the signal’s numeric value, so it can be totaled. Apps that were already current are not counted, and a run that updates nothing does not send the signal. A pass run by the root helper is counted when the app next reads that pass. The helper still does not send signals itself. Successful updates in a partially failed app-initiated batch are counted as well.

The app no longer sends App.launched, and TelemetryDeck’s automatic TelemetryDeck.Session.started signal is turned off. Update checks, whether a patch finished, and a diagnostic bundle generated from Settings are unchanged. The About tab text and the TelemetryEnabled description match.

Fixed

Clean reinstalls remove the app-created login agent. The uninstall script now boots out xyz.techitout.appAutoPatch.login from each user session and removes its plist. A clean reinstall no longer inherits a loaded KeepAlive job from the previous installation.
Package upgrades no longer wait on a throttled agent. Postinstall boots out an existing GUI LaunchAgent before terminating the app, then bootstraps a fresh job against the installed bundle. It no longer calls synchronous kickstart -k, which could wait through launchd’s 30-second throttle after a launch-constraint failure.

Build 89

Released October 13, 2026

Fixed

One menu bar process, and login can be turned on in Settings. The package postinstall and a LaunchAgent were each starting a GUI, and both stayed running with their own menu bar icon. The app now keeps one instance per logged-in user. A second launch exits. A LaunchAgent start replaces the other copy when the plist sets AAP_LAUNCH_AGENT=1. If that plist, or the app’s own login agent, is already installed, postinstall kickstarts it instead of also opening the app.

Open at login and keep-running are Settings toggles, and OpenAtLogin and KeepAlive in a configuration profile. Both default to false. A managed value or LockSettings locks the toggle. Keep running starts App Auto-Patch again if the user quits it, and also starts it at login. The app writes ~/Library/LaunchAgents/xyz.techitout.appAutoPatch.login.plist. An organization LaunchAgent already installed for every user stays in charge, and the app does not add a second one.
A hidden quit prompt explains itself and comes back forward. Installomator exit 10 now says the update was postponed (Not Now). Exit 25 says the app needs to quit and the prompt timed out, instead of an unexpected error. While that quit dialog is up, the menu bar and the dashboard say which app App Auto-Patch is waiting on. If another app covers the dialog, App Auto-Patch brings it forward again, then waits 15 seconds before doing that another time.
The menu bar item keeps trying until it has a slot. One re-insert after a hidden launch was not always enough, and the app then stayed running with no menu bar icon. It now keeps asking SwiftUI to re-insert the item, waiting 2, 4, 8, 16, then 30 seconds between tries, and it also tries when the app is activated or the screens change. Turning the icon off still leaves it off.
Labels with appCustomVersion() use that installed version. Discovery was reading appCustomVersion as a variable. Installomator labels define it as a function, so Android Studio stayed pending on the Info.plist version after Installomator had already reported no newer version. The label helper now calls that function the same way Installomator does, including any writes the label itself performs. A package receipt still wins over that function. A receipt for one of these labels keeps Installomator’s version when it differs from Info.plist.

Build 88

Released October 12, 2026

Fixed

Notification cleanup no longer leaves helper processes running. Uninstall and upgrade were launching --clear-notifications for every local account, including accounts with no graphical session. The helper then asked AppKit to terminate, which does not end the process when there is no window server, and the helper stayed running under launchd. Accounts without a gui/<uid> session are now skipped. The helper exits on its own after a few seconds, and the app stops it if that exit does not happen.

Build 87

Released October 12, 2026

Changed

AppTitle replaces the visible product name. The 3.x preference AppTitle is shown in place of “App Auto-Patch” on the dashboard window, the menu bar popover, notification titles and bodies, and the rest of the on-screen copy. A missing, blank, or whitespace-only value stays “App Auto-Patch”. A managed value overrides a local one. There is no Settings field. This does not rename App Auto-Patch.app, the helper executables, or log lines.

Build 86

Released October 12, 2026

Changed

Dashboard counts and status icons wait until Check for Updates finishes. While Check for Updates is running, Pending Updates, Up to Date, and Alerts show an em dash instead of a number, and each app row leaves its status icon blank. A zero and a yellow caution symbol during that window are not a result. The Check for Updates spinner and the checking banner stay as the progress. Counts and icons return when the check finishes. A re-check of one app, or of the Alerts list, keeps the icons already on screen.

Fixed

App Auto-Patch is not shown as a signature mismatch. Discovery was binding /Applications/App Auto-Patch.app to the 3.x label appautopatch because that name sorts before appautopatch4. Team ID verification then rejected the 4.x signature. The other built-in label is now ignored, and only the configured SelfUpdateLabel can claim this install. With the defaults, that is appautopatch4. A saved row that still uses the other label makes the next Check for Updates run a full discovery. A custom SelfUpdateLabel ignores both built-in names. Hiding App Auto-Patch from the list, or leaving updates to the self-update scheduler, still drops the configured label as before.

Build 85

Released October 11, 2026

Changed

Updates found after the cycle is complete stay visible. Check for Updates can find an app that still has an update after the cycle is already complete. The menu bar keeps the green checkmark and the cycle-complete line, and does not show a deadline. It says how many new updates were found and that they wait for the next cycle. The dashboard lists them under Needs Update. Update All there installs them without starting a new deferral. Background patching leaves them alone until the next cycle.

Fixed

Self-update finds 4.x builds. The default self-update label was appautopatch, which installs 3.x, so a running 4.0 never saw a newer release. The default is now appautopatch4. That label compares CFBundleVersion, and the self-update check does too, so build 84 is not offered again once it is already installed, and a newer build still is. App Auto-Patch copies the label into Installomator when the upstream fragments do not include it yet. A saved SelfUpdateLabel is left unchanged.

Build 84

Released October 11, 2026

Changed

The deferral dialog says how each open app will be updated. Closed apps say they will update in the background. Open apps follow BLOCKING_PROCESS_ACTION. When that option is unset, the line uses Installomator’s default, tell_user, and the built-in InstallomatorOptions value no longer forces prompt_user. A label with updateTool, or type=updateronly, says it will use its own update tool. IGNORE_APP_STORE_APPS=yes and INSTALL=force keep the blocking-action line unless the label is updateronly.

Build 83

Released October 10, 2026

Added

GitHub API requests can use a token. GitHubAPIAuthEnabled and GitHubAPIToken match the 3.7.0 keys. When authentication is on, api.github.com requests that check Installomator send the token, raising the rate limit from 60 to 5,000 requests an hour. A missing token fails those requests instead of sending them unauthenticated. The token is stored in preferences and is not written to the log. Archive downloads on github.com stay unauthenticated. Both keys are in the Installomator settings tab, and a managed value still overrides the control. The root helper reads the value saved in Settings and runs the next Installomator check within a minute after it changes.

Fixed

Uninstall removes the 4.0 user preferences. A reinstall came back with the previous cycle already complete because ~/Library/Preferences/xyz.techitout.appAutoPatch.plist was still there. uninstall.sh now forgets that domain, deletes the plist, and deletes it again after cfprefsd exits so the cache cannot write it back. Caches, HTTP storage, logs, and the saved inventory go with it. Managed preferences are left for MDM.
A completed cycle drops failed apps and the deadline countdown. With WorkflowUpdateAllErrorCompletesPatching on, Update All marked the cycle complete but left every failed app in the pending list. Those apps now leave the queue until the next cycle. The menu bar also kept the hard deadline, the days remaining, and the deferral countdown after the cycle was already complete. That section is hidden. The restart date at the top stays.
Menu bar Update All installs the apps that are pending. Yes on the menu-bar confirmation installed nothing. It used the label list from the deferral dialog, and that list was empty, so the patching cycle was marked complete while Acrobat, Chrome, and Snagit were still pending. Yes now installs every app the menu bar shows as pending, including apps that are open. The cycle is marked complete only when a fresh check shows nothing left to install.
Menu bar Update All confirms without opening the app. Update All in the menu bar opened the dashboard and the deferral dialog. It now shows the same “Install updates?” confirmation used when Update is clicked on that dialog. Yes, or the 15-second timer, installs the pending updates and refreshes the menu bar. No cancels. The dashboard is not opened. Update All inside the app still shows the deferral dialog.
LockSettings covers version comparison and Update All errors. LockSettings disabled Save and the other Settings sections, but the version comparison method, the Installomator fallback toggle, and “Mark the cycle complete when Update All has errors” stayed editable. Those controls are now disabled when Settings are locked. A managed VersionComparisonMethod, VersionComparisonInstallomatorFallback, or WorkflowUpdateAllErrorCompletesPatching disables its own control as well. Save was already a no-op while locked, so the values in use did not change.
Staging and closed-app patching finish before the deferral. Finding updates armed a focus deferral immediately, and that skipped both the installer download and the closed-app pass. The check also still looked busy, so the pass that is supposed to run first never started. Pending installers are staged when WorkflowStageUpdates is on, closed apps are patched when that schedule is on, and only then does the deferral notification start.
A failed closed-app pass does not retry immediately. A closed app whose installer macOS rejects was background-patched again as soon as that attempt finished, so the deferral prompt never appeared. Each set of closed apps is tried once. If that pass fails, the deferral is shown. The helper’s own schedule can try the app later.
A launch inventory check starts the DiscoveryFrequency timer. Opening the app when no inventory was on record ran a full discovery and update check, and the root helper then ran DiscoveryFrequency as well because it only remembered its own passes. That second pass discovered the whole inventory again and staged the same installers. A full inventory check now starts that interval. A check of one app after an install does not. If the app is still on its first check, the helper waits up to 20 minutes before starting its own pass.
Installomator stays current unless updates are turned off. An Installomator copy already on disk was never compared with InstallomatorVersion, and InstallomatorUpdateDisable was ignored. The root helper now re-downloads main, release, or custom when the installed stamp differs. main and custom compare the branch’s commit, recorded in source-commit, so a same-day push or a fragments/ edit is picked up. release still compares fragments/version.sh with the latest release tag. It checks at startup and about once a day. Turning InstallomatorUpdateDisable off while Installomator.sh is missing retries within a minute instead of waiting out the previous day-long schedule. InstallomatorUpdateDisable leaves Installomator.sh and fragments/ alone, including a 3.x TRUE / FALSE string. LabelVersionHelper.zsh is still refreshed. A check that cannot reach the source keeps the installed copy. The replacement is built beside the installed copy and renamed into place, so a discovery or patch that is already reading Installomator does not see the folder disappear while the new files are copied.

Behavior change. A Mac that already has an Installomator payload, and does not set InstallomatorUpdateDisable, has that payload replaced the first time the root helper starts on this build, and again whenever the configured source is newer. The Jamf manifest had no field for this key after it was removed, so most Jamf profiles will not have it set. Set InstallomatorUpdateDisable to true before upgrading when the pushed copy should stay.
A dialog-timeout deferral puts the open-apps notice back. When DialogTimeoutDeferral reaches zero and DialogTimeoutDeferralAction is defer, the deferral clears Notification Center, including the notice that open apps still need updates. After that clear finishes, the same persistent notice is posted again when at least one pending app is open. A click on Defer still leaves Notification Center empty. UpdatesAvailableNotificationsEnabled still applies.
The deferral prompt names the apps and skips ones already current. The prompt lists each app’s display name, current version, available version, and whether it is open or closed. The count matches the apps that will actually be updated. When both a deferral count and a deadline date are still open, both are shown. The date leads when it is less than 24 hours away. The required-update prompt and the watcher log say whether the count ran out, the date passed, or both. A configuration where DeadlineDaysHard is at least DaysUntilReset logs a warning, because that date can fall on the current day. Resetting the deferral cycle clears LastHardDeadlineFiredAt.

Update All and Install Now recheck the pending labels first and drop any that are already current. Installomator exiting 0 with “No newer version” is recorded as already up to date, not as a successful patch. Progress text uses the display name.

Changed

Deferral durations use a menu. The deferral dialog listed every DeferralTimerMenu duration as a radio button. With the pending-app list on the same dialog, a long menu pushed the buttons down the screen. The durations are now a one-row menu. The selected duration stays visible, and Defer still applies it. The required-update prompt still hides the duration choices.

Build 82

Released October 9, 2026

Added

The app follows the macOS language. On-screen text, menu bar copy, and notifications use the language chosen in System Settings. Spanish, French, German, Portuguese, Italian, Dutch, Japanese, and Simplified Chinese are included. A language this build does not translate stays in English. Log lines stay in English.
Installing 4.0 removes a leftover 3.x install. The package install runs /usr/local/bin/appautopatch --uninstall when that 3.x command is present. That removes the 3.x symlink, /Library/Management/AppAutoPatch, and the xyz.techitout.aap LaunchDaemon. If the command is missing or the uninstall fails, the 4.0 install continues. The 4.0 app, its support folder, the root helper, and the shared preferences are left in place.

Build 81

Released October 9, 2026

Changed

App Store rows say who updates them. A Mac App Store app on the status list used to say “Mac App Store — update there”. That read like a task for the user. The row now says “Updated by the App Store”. The bag icon tooltip and the app detail use the same wording, and still mention IGNORE_APP_STORE_APPS=yes.

Build 80

Released October 8, 2026

Fixed

Clicking the menu bar icon again closes the panel. A second click on the menu bar icon hid the panel and then opened it again. That click now closes the panel and leaves it closed. The next click opens it.

Build 79

Released October 8, 2026

Fixed

Webhooks are sent, and Teams uses an Adaptive Card. A finished patch posts a summary when WebhookFeature is all, or failures and a label failed. A run started from the app is posted by the XPC service. The root helper posts its own closed-app pass, and reads webhook settings from the console user when they are not managed. The same run is not posted twice. Teams receives a Workflows Adaptive Card. Slack still receives Block Kit. A failed POST is written to the log. The unused webhook wrapper in the XPC service is removed.
Label lists accept the 3.x string and both array forms. IgnoredLabels, RequiredLabels, and OptionalLabels accept a whitespace-separated string, an array containing one such string, or an array with one label per string. A wildcard such as microsoft* stays one label. The app and the root helper read all three forms.

Build 78

Released October 7, 2026

Changed

Anonymous usage signals no longer include deferrals. The GUI no longer sends a TelemetryDeck signal when a user defers an update. The signals that remain cover launch, a full update check, a finished patch, and a diagnostic bundle generated from Settings. The About tab text and the TelemetryEnabled description match.

Build 77

Released October 7, 2026

Added

Anonymous usage signals. The GUI can send anonymous TelemetryDeck signals for launch, a full update check, a finished patch, and a diagnostic bundle generated from Settings. Counts are bucketed. App names, user names, paths, and serial numbers are not included. TelemetryEnabled defaults to true. Settings → About has a toggle, and a managed false disables the toggle and stops signals. The root helper and the XPC service do not send them. Command-line runs exit before telemetry starts.
Menu bar deadline, diagnostic output, package receipts, and sleep-aware installs. The menu bar Deadline section and the dashboard Update Deadline pill stay hidden when every app is up to date and no countdown is running. Seeded deadline dates are unchanged.

--generate-diagnostic-bundle prints progress, the archive size, and a short next step on stderr when a terminal is attached or --verbose is set. The zip path is still the only stdout line. --help lists the command. The GUI no longer opens its own bundle identifier as an NSUserDefaults suite, which removes the Foundation warning.

A label with packageID reports the pkg receipt version when one exists, matching Installomator. Homebrew no longer stays pending because /Applications/Homebrew.app has a different version.

The per-label Installomator timeout counts awake time (systemUptime). A sleep no longer expires the budget. A timeout log includes both awake time and wall-clock time.

Fixed

Partial Update All, sudo diagnostics, deferral events, and helper log volume. A failed or partial Update All re-checks the labels it submitted, so a label that already succeeded drops out of the next retry. Install Now, including a hard-deadline countdown, sends only labels that still need an update. If none do, the dialog closes and the cycle is marked complete.

sudo --generate-diagnostic-bundle collects the console user’s preferences, fallback logs, and crash reports. metadata.txt adds a Console user section. With nobody logged in, the bundle keeps using the running user.

The root helper sets deferral-events to root:staff mode 0775 on startup, and a failed event write is logged instead of discarded.

The helper logs a startup-jitter hold or an active deferral when the value changes, and otherwise at most once every five minutes. The console user’s NextAutoLaunch is cached for 60 seconds.