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):
Profile
Bundle IDs
PayloadScope
Result
Watch-focused (Nano*, Carousel*, .watchapp, SiriExtensions, complications)
451
System
All Watch apps
disappear
Phone-focused superset (third-party + Apple essentials)
481
User
All Watch apps disappear
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.
Topic:
Business & Education
SubTopic:
Device Management
Tags: