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

We tried installing ipa file in m1 Mac ( tried both mac11 and mac12 silicon mac), but it failed with error informing - Error Domain=ASDErrorDomain Code=660 "Could not create PKProduct". Attaching the log and plist details ipa-failure-devicelog.txt the plist - install application command

We are trying out Account Driven User Enrollment feature. Device is expected to send the device info(plist) (snippet below) during User enrolment in new flow as part of profile download request. Device is sending with HTTP request content type as "application/x-www-form-urlencoded", because of this HTTP request content type, we are not able to read the body as stream of bytes and parse the xml. In comparison to usual device enrolment workflow device info gets posted with the http request content-type  as "application/pkcs7-signature" which has been working fine without any issues. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>LANGUAGE</key> <string>en-US</string> <key>PRODUCT</key> <string>iPhone10,2</string> <key>VERSION</key> <string>19A222</string> </dict> </plist> Can you please confirm if this is an issue from Apple side? Any suggestions around this?

This is in reference to the feedback ticket : https://feedbackassistant.apple.com/draft/57929340, we would like to know if there are any test enterprise websites that Apple can suggest to test passkeys declaration.