com.apple.asam profile installs but is reported as "com.apple.unknown" on iOS 26.5.1 (ASAM not granted)

I'm trying to enable Autonomous Single App Mode (ASAM) for my own app on a supervised iPhone, but UIAccessibility.requestGuidedAccessSession(enabled:) always returns false, even though the com.apple.asam profile installs without error.

Environment

  • Device: iPhone 16 (iPhone18,5), iOS 26.5.1
  • Supervised: yes (verified via DeviceInformation query → IsSupervised = true)
  • MDM: self-hosted NanoMDM. Other payloads (com.apple.webcontent-filter, com.apple.applicationaccess) install and work correctly.
  • App: development-signed, Bundle ID net.self-control-mdm.SessionLock, Team ID 9VH4G6KS29

Profile I'm sending (matches the AutonomousSingleAppMode documentation exactly):

<dict> <key>PayloadType</key> <string>com.apple.asam</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>net.self-control-mdm.asam.payload</string> <key>PayloadUUID</key> <string>...</string> <key>AllowedApplications</key> <array> <dict> <key>BundleIdentifier</key> <string>net.self-control-mdm.SessionLock</string> <key>TeamIdentifier</key> <string>9VH4G6KS29</string> </dict> </array> </dict>

What happens

  1. InstallProfile is Acknowledged with no ErrorChain.
  2. A ProfileList query shows the profile IS installed, but its payload type is reported as com.apple.unknown (display name is preserved).
  3. In Settings → General → VPN & Device Management, the profile shows the payload as "Unknown Payload".
  4. In the app, requestGuidedAccessSession(enabled: true) completion returns success = false.
  5. Rebooting the device does not change anything.

Questions

  1. Is the legacy com.apple.asam profile payload still honored on iOS 26, or has ASAM authorization moved to Declarative Device Management? If DDM is now required, which declaration/configuration should I use to allow-list an app for ASAM?
  2. Does com.apple.unknown in the ProfileList response indicate the payload was genuinely not recognized, or is that expected for this payload type?
  3. Are there additional requirements on iOS 26 (e.g., the app must be an MDM-managed app, or a non-development signature) for requestGuidedAccessSession to succeed?

Thanks in advance.

Does com.apple.unknown in the ProfileList response indicate the payload was genuinely not recognized?

Yes, that's exactly what it means. Either it didn’t recognize the PayloadType or “something” about the payload configuration meant that it was rejected as invalid. My current guess would be that it’s the second case, caused by #3 below.

or is that expected for this payload type?

No, we shouldn't be using it for any "valid" payload configuration.

Checking a few details on the configuration you sent:

  1. PayloadUUID actually contains a valid value, correct?

  2. The snippet you sent is the embedded content of a larger profile content, not the entire content? That's what the documentation shows, but I want to be sure.

  3. As you look through the entire payload, pay attention to what field doesn’t match in the example.

Expanding on that last point, note that "PayloadUUID" and "PayloadIdentifier" exist for the full payload as well as inside "PayloadContent". I haven't specifically confirmed this, but I'd expect overlapping values to confuse the system, likely resulting in an unknown payload. The system uses those values to track these objects, so overlapping values could create collisions that confuse the system.

  1. Is the legacy com.apple.asam profile payload still honored on iOS 26, or has ASAM authorization moved to Declarative Device Management? If DDM is now required, which declaration/configuration should I use to allow-list an app for ASAM?

... 3. Are there additional requirements on iOS 26 (e.g., the app must be an MDM-managed app, or a non-development signature) for requestGuidedAccessSession to succeed?

I'm not aware of us having changed anything here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the detailed response. I've now verified all three points, plus gathered significant new evidence.

Answers to your questions:

  1. Yes, all PayloadUUIDs contain valid unique UUIDs (generated with uuidgen).
  2. The excerpt in my original post was the complete profile, only abbreviated for readability.
  3. I compared every field against the AutonomousSingleAppMode documentation example. No mismatches found, and there are no duplicated PayloadUUID or PayloadIdentifier values anywhere (the top-level and inner values are all distinct: top-level UUID de1bbc5d-e01a-40eb-b42f-1f1f314e643e, inner payload UUID 3531136d-b3d2-47e0-9912-7715cf794831; identifiers net.self-control-mdm.asam vs net.self-control-mdm.asam.payload).

New evidence (clean-slate reproduction):

Since my original post, I fully erased this device and re-enrolled it via Automated Device Enrollment (it is now ADE-enrolled and supervised). The device has only 4 profiles: the MDM enrollment profile and three simple ones (com.apple.dnsSettings.managed, com.apple.applicationaccess x2), all with unique UUIDs. I then regenerated the ASAM profile with brand-new UUIDs and installed it via InstallProfile. Results:

  • InstallProfile returned NotNow repeatedly while the device was locked, then Acknowledged (no ErrorChain) once unlocked. Interestingly, other payload types install fine while locked, so iOS does treat this payload specially at install time.
  • ProfileList still reports the payload as com.apple.unknown.

This appears to rule out the UUID/identifier conflict hypothesis, since the issue reproduces on a freshly erased, cleanly enrolled device with guaranteed-unique values. The profile content is otherwise byte-for-byte the structure from my original post (PayloadType com.apple.asam, PayloadVersion 1, AllowedApplications with BundleIdentifier net.self-control-mdm.SessionLock and TeamIdentifier 9VH4G6KS29, wrapped in a standard Configuration profile).

Given this, could you confirm whether the com.apple.asam profile payload is still supported on iOS 26.5.1, or whether ASAM authorization has moved to a different mechanism (e.g., DDM)? Happy to file a Feedback with sysdiagnose if useful.

Given this, could you confirm whether the com.apple.asam profile payload is still supported on iOS 26.5.1, or whether ASAM authorization has moved to a different mechanism (e.g., DDM)? Happy to file a Feedback with sysdiagnose if useful.

As far as I can tell, what you're describing should work so, yes, I think a bug is a good idea. Please include the following in that bug:

  • A sysdiagnose that covers the time the payload was pushed to the device. Please not what time you pushed the payload in the bug.

  • A copy of the profile you're pushing out.

...then post the bug number back here once it's filed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

com.apple.asam profile installs but is reported as "com.apple.unknown" on iOS 26.5.1 (ASAM not granted)
 
 
Q