You can fix this warning by calling: Task { let duration = try await asset.load(.duration) let time = CMTimeMultiplyByRatio(duration, multiplier: 1, divisor: 2) } But I agree with you that it is a bit weird as it turns a synchronous call into an async one, which can become a pain in some contexts. I don't know why they deprecated asset.duration

I realize that I have actually made a big mistake. When receiving the challenge on the iOS client, I forgot to Base64 decode it, which led ASAuthorizationPlatformPublicKeyCredentialProvider.createCredentialAssertionRequest() to Base64 encode it a second time. When receiving the rawClientDataJSON from the ASAuthorizationResult, in order to send the appropriate challenge back to the server, I was Base64 decoding it from the rawClientDataJSON to then send it in the expected format (removed the second Base64 encoding) to the server. This was a trick I used for the .passkeyRegistration case (as I also forgot to Base64 decode the challenge in the first place there as well), which happened to work as there is no signature produced from the clientDataHash, hence just decoding the challenge afterwards was enough. But for the .passkeyAssertion case, as the signature is produced from the clientDataHash, this obviously doesn't work anymore. When finding this previous "solution", I thought this was just some Base64/Base64URL conversion mistake, but it was actually much more concerning and it led me straight into this error. I guess what could have saved me from this mistake is if both createCredentialAssertionRequest() and createCredentialRegistrationRequest() were doing a type check on the challenge received, to make sure it is of type BufferSource (and not Base64URL encoded) as both navigator.credentials.get() and .create() do and return a type error in case of such mistake. My apologies for this inaccuracy I posted here. I hope this can still help if someone ever runs into the same issue as I did.

I realize I forgot to mention the DTS Case-ID: 9134364. But it has now been a month that I submitted this request and still haven't got any feedback yet.

Just posted a bug report with the following number: FB14980438

Hello, following this thread, I tried again on iOS 18 Beta 7 and the issue is still the same; when looking at the system process swcd, I get the following error: "Domain ac….de….com is invalid. Will not attempt a download". When building, the same app with a domain without any special character, the swcd process executes successfully and the device is able to download the AASA file.