Approving the helper (Service Management)

New to deploying App Auto-Patch?

The quick start walks through the whole setup in order, with ready-made profiles you can edit and upload.

App Auto-Patch installs a root LaunchDaemon (the “root helper”) that runs Installomator with elevated privileges. Out of the box macOS requires the end user to approve that daemon once via System Settings › General › Login Items & Extensions. On a managed Mac that prompt can be removed entirely with a com.apple.servicemanagement configuration profile. This doc covers the correct rule values for App Auto-Patch 4.x.

TL;DR

Use RuleType=Label for App Auto-Patch’s helper. The recommended rule is:

<dict>
    <key>RuleType</key>
    <string>Label</string>
    <key>RuleValue</key>
    <string>xyz.techitout.appAutoPatch.roothelper</string>
</dict>

A RuleType=TeamIdentifier rule is a good belt-and-braces complement. RuleValue must be the Team ID that signed the installed app: 6GBSVT64FS for Robert Schroeder’s Developer ID (the repo default), or 4XSYV3BTMX for Andrew Spokes’ Developer ID. See Which Team ID in Profile Manifests/MDM-AppManagement.md.

Why Label, not BundleIdentifier?

The Service Management Rules array matches against attributes that BTM (Background Task Management) stores on each launch item. For an SMAppService-registered daemon — which is how AAP installs its root helper — BTM stores the launchd plist’s Label as the daemon’s BTM Identifier. RuleType=Label matches against that field directly, so it reliably auto-approves the daemon. RuleType=BundleIdentifier, by contrast, matches against BTM’s Assoc. Bundle IDs field. SMAppService-registered daemons do not have that field — only curated legacy daemon items (installed via .pkg into /Library/LaunchDaemons and /Library/PrivilegedHelperTools) do. As a result, BundleIdentifier rules don’t reliably match against AAP’s helper regardless of what RuleValue you give them. This mis-match was the actual cause of issue #6 and issue #11. You can verify the daemon’s BTM record yourself with:

sudo sfltool dumpbtm | grep -A 15 techitout

For AAP’s helper you’ll see something like:

Name: xyz.techitout.appAutoPatch.roothelper
Type: daemon (0x10)
Identifier: xyz.techitout.appAutoPatch.roothelper   ← this is what Label matches
URL: Contents/Library/LaunchDaemons/xyz.techitout.appAutoPatch.roothelper.plist
Parent Identifier: identifier "xyz.techitout.appAutoPatch" and …

Note there’s no Assoc. Bundle IDs line — confirming why BundleIdentifier rules can’t match.

Identifier reference for AAP

• Helper LaunchDaemon Label / bundle id: xyz.techitout.appAutoPatch.roothelper
• Parent app bundle id: xyz.techitout.appAutoPatch
• Team identifier: 6GBSVT64FS

Choosing a RuleType

Apple’s Service Management framework supports five rule types (reference). In order of preference for App Auto-Patch:

1. Label — exact match against the daemon’s BTM Identifier, which is set from the launchd plist’s Label key. This is the only rule type that reliably matches an SMAppService-registered daemon. Recommended.
2. TeamIdentifier — matches anything signed by the AAP development team (6GBSVT64FS). Broader than Label, but a good complementary rule since AAP currently ships only one launch item under that team.
3. BundleIdentifier / BundleIdentifierPrefix — these match against BTM’s Assoc. Bundle IDs field, which is not populated for SMAppService-registered daemons. Don’t use these for AAP. They were the source of the original incorrect recommendation in this file (issues #6 and #11).
4. LabelPrefix — prefix-match against the daemon’s BTM Identifier. Equivalent to Label for AAP since AAP only registers one daemon; use only if you want to also catch future sibling daemons under the same prefix.

Sample profile

A complete, ready-to-sign sample lives next to this doc:

• com.apple.servicemanagement-AppAutoPatch.example.mobileconfig The sample profile contains two rules:

<!-- Primary rule: match by launchd Label -->
<dict>
    <key>Comment</key>
    <string>App Auto-Patch root helper (daemon, by launchd Label)</string>
    <key>RuleType</key>
    <string>Label</string>
    <key>RuleValue</key>
    <string>xyz.techitout.appAutoPatch.roothelper</string>
</dict>
<!-- Belt-and-braces fallback: anything signed by AAP's team -->
<dict>
    <key>Comment</key>
    <string>Anything signed by App Auto-Patch development team (fallback)</string>
    <key>RuleType</key>
    <string>TeamIdentifier</string>
    <key>RuleValue</key>
    <string>6GBSVT64FS</string>
</dict>

If either rule matches, the daemon is auto-approved. The TeamIdentifier rule is the safety net for any future macOS release that changes how Label rules evaluate against SMAppService daemons.

Verifying it worked

1. Push the profile.
2. Install (or reinstall) App Auto-Patch.
3. Launch App Auto-Patch.
4. Open System Settings › General › Login Items & Extensions and confirm the AAP entry shows up under Allow in the Background and is toggled on with a managed by your organization badge — i.e. the user can’t disable it.
5. Confirm the AAP first-run wizard skips step 1 (“Approve the root helper”) because the helper status is already enabled. On the command line, sudo sfltool dumpbtm | grep -A 15 techitout shows the AAP daemon’s BTM record. After a successful match the Disposition field should read [enabled, allowed, visible, notified] and you should see a Generation greater than 0.

Daemon was registered before the profile arrived

If the daemon was already in BTM (registered by a previous AAP install) before the profile was pushed, the rule may not retroactively apply on some macOS versions. Recovery is straightforward:

1. Run sudo "/Applications/App Auto-Patch.app/Contents/Resources/uninstall.sh" to remove the daemon registration entirely.
2. Reboot.
3. Confirm the profile is still installed (profiles list).
4. Reinstall AAP.
5. Re-check sudo sfltool dumpbtm | grep -A 15 techitout — the daemon should come up auto-approved on first registration.

Requirements / caveats

• macOS 13 (Ventura) or later. The com.apple.servicemanagement payload was introduced in macOS Ventura and AAP 4 targets macOS 14+ anyway.
• The profile must be deployed by a user-approved MDM. Apple does not permit manual installation of this payload type.
• The payload only manages launch items the system already knows about. AAP must have been installed (and its daemon registered) at least once before BTM has the daemon in its database. Practically: ship the AAP installer and the profile to the same Mac in either order, but make sure both eventually arrive.
• Multiple com.apple.servicemanagement payloads are allowed on a single Mac, so you can keep an existing profile that approves other daemons and add an additional one for AAP.