Notification permissions

App Auto-Patch posts user notifications for several events:

A background-patch pass completed (helper-daemon mode posts via the GUI’s HelperBackgroundPatchObserver; in-app mode posts via BackgroundPatchScheduler).
A self-update is available (when a newer AAP is found by SelfUpdateScheduler).
A self-update has finished installing. By default, macOS shows a system permission prompt the first time AAP tries to post a notification (“AppAutoPatch would like to send you notifications”). On managed Macs that prompt is usually unwanted — admins want notifications either pre-allowed across the fleet or suppressed entirely. This is solved with a com.apple.notificationsettings configuration profile.

TL;DR

A minimal profile that enables AAP notifications fleet-wide:

<dict>
    <key>BundleIdentifier</key>
    <string>xyz.techitout.appAutoPatch</string>
    <key>NotificationsEnabled</key>
    <true/>
    <key>AlertType</key>
    <integer>1</integer>
    <key>BadgesEnabled</key>
    <true/>
    <key>SoundsEnabled</key>
    <true/>
    <key>CriticalAlertEnabled</key>
    <false/>
    <key>ShowInLockScreen</key>
    <true/>
    <key>ShowInNotificationCenter</key>
    <true/>
</dict>
<dict>
    <key>BundleIdentifier</key>
    <string>xyz.techitout.appAutoPatch-persistent</string>
    <key>NotificationsEnabled</key>
    <true/>
    <key>AlertType</key>
    <integer>2</integer>
    <key>BadgesEnabled</key>
    <false/>
    <key>SoundsEnabled</key>
    <true/>
    <key>CriticalAlertEnabled</key>
    <false/>
    <key>ShowInLockScreen</key>
    <true/>
    <key>ShowInNotificationCenter</key>
    <true/>
</dict>

A complete, deployable sample lives next to this doc: com.apple.notificationsettings-AppAutoPatch.example.mobileconfig.

Identifier reference

xyz.techitout.appAutoPatch posts informational notifications. Configure it with AlertType = 1 (temporary banner).
xyz.techitout.appAutoPatch-persistent is the embedded, short-lived notifier for action-required notifications. System Settings shows it as App Auto-Patch Notification. Configure it with AlertType = 2 (persistent alert). The bundle ID did not change when the display name changed, so an existing notification-settings profile keeps applying. Notification Center can keep the previous name, App Auto-Patch Persistent, until the user logs out or the Mac restarts.

macOS controls presentation per bundle ID, not per notification request. The managed preferences TemporaryNotificationTypes and PersistentNotificationTypes choose which identity posts a notification; this Notification Settings payload controls how each identity appears.

Key reference

Key	Type	Notes
`BundleIdentifier`	string	Required. Use one entry for each identifier above.
`NotificationsEnabled`	bool	`true` to allow AAP to post notifications. Set to `false` to suppress every AAP notification on the Mac.
`AlertType`	int	`0` = none, `1` = banner, `2` = alert. Banners auto-dismiss; alerts persist until acted on. AAP’s notifications are short status messages so banners are usually right.
`BadgesEnabled`	bool	Controls the unread-count badge on the AAP icon. Currently AAP doesn’t post badges, so this is effectively a no-op for now — included for forward compatibility.
`SoundsEnabled`	bool	Whether notification sounds play.
`CriticalAlertEnabled`	bool	`true` makes notifications bypass Do Not Disturb and play even when the Mac is on silent. AAP notifications are not time-critical, so this should generally stay `false`.
`ShowInLockScreen`	bool	Whether AAP notifications appear on the lock screen.
`ShowInNotificationCenter`	bool	Whether AAP notifications collect in Notification Center.
`PreviewType`	int	(Optional, macOS 14+.) `0` = always, `1` = when unlocked, `2` = never. Controls when notification content is previewed in the banner vs. hidden behind “Notification”. AAP notifications carry no sensitive data, so leaving this unset is fine.

Verifying it worked

Push the profile.
Launch (or relaunch) AAP.
Open System Settings › Notifications. Find the AAP entry.
Confirm the toggle row reads Managed by your organization — i.e. the user can’t change it.
Trigger a notification path (the easiest is Settings › Advanced › Background Patching with Show a notification when a background pass finishes enabled, then click Discover Applications → Update All) and confirm the toast actually appears. On the command line, profiles list shows every installed profile.

Suppressing notifications (the inverse)

If you want to block AAP notifications fleet-wide, deploy the same profile but with:

<key>NotificationsEnabled</key>
<false/>

This silences every notification path AAP has, including the HelperBackgroundPatchObserver post-pass toast and the self-update banner. Useful in environments where users shouldn’t get any patching-related notifications and AAP runs purely as a background service.

Requirements / caveats

macOS 13 (Ventura) or later — the com.apple.notificationsettings payload predates that, but AAP itself targets macOS 14+.
The profile must be deployed by an MDM. Apple does not allow manual installation of this payload type for App Store / Notarized apps.
Multiple com.apple.notificationsettings payloads are allowed on a single Mac, so adding an AAP-specific payload doesn’t conflict with profiles that already manage other apps’ notification settings.