MCRestrictionsPayload (allowListedAppBundleIDs) breaks Apple Watch native app enumeration — `nanotimekitcompaniond` reports "Missing .app from directory: /Watch/"

Update — root cause found and a working workaround

I cracked it. Posting the solution here so other admins can stop trying random bundle IDs.

Root cause (confirmed via watchOS sysdiagnose)

When you install a profile with com.apple.applicationaccess + allowListedAppBundleIDs, lsd on the paired Apple Watch immediately sends "uninstalledNotifications" for every PluginKit extension whose bundle ID is NOT in the whitelist. The watch's Carousel then cascades by terminating the parent apps that own those extensions, disguising the action as user initiated quit.

Captured from watchOS sysdiagnose at the moment of profile install:

17:22:56  lsd: Sending uninstalledNotifications for (
   pluginID=com.apple.MobileSMS.MessagesAssistantExtension
   pluginID=com.apple.tincan.SiriExtension
   pluginID=com.apple.SessionTrackerApp.SessionTrackerSiriExtension
)

17:23:13  Carousel: com.apple.MobileSMS:        terminateApplication - uninstalling app (user initiated quit)
17:23:13  Carousel: com.apple.tincan:           terminateApplication - uninstalling app (user initiated quit)
17:23:13  Carousel: com.apple.NanoNowPlaying:   terminateApplication - uninstalling app (user initiated quit)
17:23:13  Carousel: com.apple.SessionTrackerApp:terminateApplication - uninstalling app (user initiated quit)
17:23:13  Carousel: com.apple.HeartRate:        terminateApplication - uninstalling app (user initiated quit)
17:23:13  Carousel: com.apple.DeepBreathing:    terminateApplication - uninstalling app (user initiated quit)

This is why adding more parent-app bundle IDs to the whitelist never helped — the whitelist filter is being applied at the PluginKit level, not the application level.

The workaround

You must whitelist the SiriKit extension bundle IDs of every Apple Watch native app, in addition to the parent bundle ID. Pattern:

com.apple.<app>                         # parent (likely already there)
com.apple.<app>.SiriExtension           # the missing piece
com.apple.<app>.*Extension              # any other PluginKit plugins the app ships

Confirmed critical extensions

For the three apps in my repro:

Validation

Two independent install/remove cycles of a profile containing the above (308 bundle IDs total):

Cycle 1 (install v3): 0 Watch-side extensions in uninstalledNotifications. 
                      Walkie-Talkie, Messages, Find My all stayed visible.
Cycle 2 (remove v3 → reinstall v3): same result.

Before the fix, the same plugins were uninstalled on every profile install.

How to discover the extensions for your deployment

The extension bundle IDs can be enumerated directly from the watchOS sysdiagnose. Trigger a sysdiagnose, extract it, then:

# inside the extracted Watch sysdiagnose folder:
log show --info --debug --last 24h \
    --predicate 'eventMessage CONTAINS "pluginID="' \
    system_logs.logarchive \
    | grep -oE 'pluginID=com\.apple\.[a-zA-Z0-9._-]+' | sort -u

Whatever shows up that you care about — add to allowListedAppBundleIDs.

What is still a bug (Apple-side)

The fact that you have to whitelist watchOS-side extensions through an iOS payload that profiled itself logs as "not supported on any Watch version" is the underlying bug. The workaround above is just rerouting around it.

I will keep the FB open and update the OP if Apple responds. For now: shipping this so others stop chasing the parent bundle IDs.

Environment: iPhone 16 / iOS 26.4.2 (23E261), Apple Watch on watchOS 6.3.1 (build 17U208), supervised iPhone, profile installed locally via Apple Configurator (no MDM server needed to reproduce).

Update — the SiriExtensions workaround does NOT scale. There is no fix inside allowListedAppBundleIDs. Retracting the workaround above. After testing across more devices and iOS versions, no whitelist composition resolves this. Posting an update so other admins stop chasing a dead end.

What broke the original "fix"

The SiriExtensions pattern (<app> + <app>.SiriExtension + <app>.*Extension) worked on iPhone 16 / iOS 26.4.2 + Apple Watch Series 3 / watchOS 6.3.1. It does not generalize.

Reproduced on a second pairing (iPhone 15 / iOS 18.6.2 + modern Watch):

Both lists installed cleanly. Both removed every native Watch app within ~30s.

Ruled out this round

• Other payloads in the profile triggering propagation — no, an isolated profile with only applicationaccess +

allowListedAppBundleIDs reproduces it

• PayloadScope: User — no, both User and System reproduce
• List size or content (Watch-aware vs phone-aware) — no, both fail identically
• Per-key supportedOS metadata override — no, schema metadata only
• Wildcard com.apple.* — not a supported value; only com.apple.webapp is documented (Web Clips only)
• Switching to blockedAppBundleIDs — not viable for kiosk-style allowlists (cannot enumerate "everything except

these few")

Root cause (reconfirmed)

lsd: Sending uninstalledNotifications for (
   pluginID=com.apple.MobileSMS.MessagesAssistantExtension
   pluginID=com.apple.tincan.SiriExtension
   ...
)

Carousel: com.apple.MobileSMS:      terminateApplication - uninstalling app (user initiated quit)
Carousel: com.apple.tincan:         terminateApplication - uninstalling app (user initiated quit)
Carousel: com.apple.NanoNowPlaying: terminateApplication - uninstalling app (user initiated quit)

The Watch's lsd reads the inherited allowListedAppBundleIDs, marks every PluginKit extension not in the list as "uninstalled," and Carousel cascades by terminating the parent apps — disguised as user initiated quit. Meanwhile Apple's own profiled logs MCRestrictionsPayloadHandler not supported on any Watch version at the same moment the propagation happens. The system acknowledges the incompatibility while still executing the propagation. That's the bug.

Why an "exhaustive whitelist" cannot work

The Watch enumerates private extensions (*.notifications, *.appex, daemons, transient extension IDs) that aren't documented. New ones ship with each minor release. The check happens on the Watch side, against the inherited list, so any extension you don't anticipate is nuked at install time. It's not a matter of finding the right N bundle IDs — the check shouldn't be running on the Watch at all.

The only viable fix: DDM com.apple.configuration.watch.enrollment

Declarative Device Management (iOS 16+) lets the MDM server send the Watch its own declarations independent of the iPhone's. The Watch stops inheriting iPhone-side restrictions. For anyone with control over their MDM backend, this is the path. For anyone on a hosted MDM, push your vendor to ship DDM support.

TL;DR for admins arriving from search

• Confirmed bug in how watchOS handles the inherited restriction. Apple's logs label it unsupported on Watch yet still

apply it.

• No working whitelist composition. Don't extend the list — I tried up to 481 entries with SiriExtensions,

widgets, complications, watchkit apps, private extensions. Still broken.

• Removing the profile restores Watch apps after the iPhone re-syncs.
• Real fix: DDM Watch Enrollment from the MDM server side. No client-side workaround.

Environment: iPhone 15 / iOS 18.6.2 (unsupervised), profile installed locally via Safari + Settings. Independent of any MDM server — reproduces with any local .mobileconfig containing allowListedAppBundleIDs.