Without iosApp flag in the InstallApplication command we are able to install an iOS app in mac11 device.    https://developer.apple.com/documentation/devicemanagement/installapplicationcommand/command                As per doc, this flag has to be set to true so that ios app can be installed on mac device, but even without this flag ( default false), the iOS apps installation on MacOS 11 is successful. What is the significance of iOSApp flag?

We sent certificate revocation payload documented at https://developer.apple.com/documentation/devicemanagement/certificaterevocation to iOS device. On the device, the "Certificate Revocation Configuration" is listed but do not see any effect of this revocation. We revoked the certificate of a website and tried to access it from Safari. The access is not blocked. How can we check that the certificates are actually revoked?

We are observing few issues when allow / block list of apps restriction is pushed to iOS 14.5 & iOS 15 devices. Below are the list of issues: System apps are not accessible from Device Layout when a specific non-system app bundle id is added to allowed list. This behaviour is seen both on iOS 14.x & 15. For example calendar, notes, email apps are missing but apps like feedback assistant, whether widgets are seen. When any app is added to blocked app list, all system apps are missing in layout iOS15 but are accessible from App Library. Where as on iOS 14.5 system apps are displayed on Device Layout & App Library even when a particular non-system app is added to blocked app list. On device retirement from MDM, all the apps are not reappearing on the Device layout if allowed / blocked app list was earlier distributed. Only upon uninstall of another app all the apps reappear. When Allowed & Blocked apps list restrictions are sent to device only Web Clip apps are present on Device Layout. Please direct to the right documentation which can confirm the right behaviour of these restrictions on the device.

VerifyRecoveryLockResponse - in this response, we do not get a key as VerifyRecoveryLock like its seen in VerifyFirmwarePasswordResponse where we get a key as VerifyFirmwarePassword. So should we rely only on the commanduuid to map to type of response and handle result accordingly for this type? <dict> <key>CommandUUID</key> <string>08b5bfb1-b547-43b4-b453-340a0dadeb7d</string> <key>PasswordVerified</key> <true/> <key>Status</key> <string>Acknowledged</string> <key>UDID</key> <string>B29422F1-756E-5370-966E-3A6E9E969096</string> </dict> . SetRecoveryLockResponse - in this response also we do not get a key to identify acknowledgement as 'SetRecoveryLockResponse' ( but we can identify with the CommandUUID) . we do not have any field as 'PasswordChanged' to confirm if its already changed like we have for SetFirmwarePasswordResponse. <dict> <key>CommandUUID</key> <string>d19f5ac9-31be-4cd9-9e20-0b034108855a</string> <key>Status</key> <string>Acknowledged</string> <key>UDID</key> <string>B29422F1-756E-5370-966E-3A6E9E969096</string> </dict> even though we could compare commanduuid, it would have been better if we also get the