FB23904798

Thank you very much, Kevin — I really appreciate your help. I've filed this via Feedback Assistant: FB[番号をここに] I attached a copy of the profile as installed. I wasn't able to capture a sysdiagnose this time, but I can provide one if it would help — just let me know. Thanks again.

Thank you very much, Kevin — I really appreciate you taking the time to look into this and confirm it should be working. I'll go ahead and file a bug report via Feedback Assistant. I'll capture a sysdiagnose covering the window around when the profile is pushed (and note the exact push timestamp), and attach a copy of the full profile as installed. I'll post the FB number back here once it's filed. Thanks again for your help.

Thank you for the detailed response. I've now verified all three points, plus gathered significant new evidence. Answers to your questions: Yes, all PayloadUUIDs contain valid unique UUIDs (generated with uuidgen). The excerpt in my original post was the complete profile, only abbreviated for readability. 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.