Thank you for your reply, I also just had an AVKit lab and this indeed seems like an issue with the framework(s). To follow up, I filed a feedback (FB18058056) mentioning yours and this discussion. I also realized that using the CustomAVPlayerView as shown above actually works as long as the app doesn't configure the MPRemoteCommandCenter (by adding targets to the shared instance). In my use case, I do have to configure it (as for many other I recon) so I had to come up with another "fix". Personally what I did is to pass the scenePhase to the views configuring/displaying the videos so that when the app enters the .inactive or .background state I can pause the AVPlayers and setup the nowPlayingInfo again (either to nil or current audio). I also do this cleanup as soon as the view disappears (via .onDisappear{}). Ultimately this is not great as there are still some side-effects, for example, If no audio is playing but the user simply opens the view with the video players, the app will appear as Now Playing (even after setting thenowPlayingInfo to nil). But for now, it is a "good enough" workaround, until the underlying issue is addressed.

The bug report (FB14980438) was just closed with the following resolution: Investigation complete - Works as currently designed I received the following feedback: This is expected; swcd requires that the host name complies to NSCharacterSet.URLHostAllowedCharacterSet. I don't understand how this is as intended, as it prevents any app linked to a service with an IDN to use passkeys (and associated domains altogether). Does any one know if there will be a fix at all or a way to use an IDN for passkeys?

I ran in the same issue as you previously. If you use SimpleWebauthn library it expects a Base64URL encoded RP ID hash and apple produces a Base64 encoded one. You can check this SO thread for more details; but basically, when you receive an ASAuthorizationResult.passkeyRegistration you should Base64URL encode the rawAttestationObject. Thus if you have a res object (on the iOS client) that you send back to verifyRegistrationResponse(), adding: res.response.attestationObject = Base64URL.encode(rawAttestationObject!) before sending it back to your server should fix your issue. Please also note that a valid RP ID only consists of the effective domain name so in your case pebblepath.link (without the https://). I hope this is clear enough and helps you fix your problem.

To update this post, the problem still occurs on iOS18.2.1, but there are some slight changes. Now Xcode is able to install the app both with the domain in punycode or or with the special character (it does not Fail to verify code signature anymore). The message returned from the swcd process is still: Domain ac….de….com is invalid. Will not attempt a download. This issue remains critical for developers relying on authentication services hosted on IDNs, as it prevents a migration to passkeys. Hence a resolution in a near future would be highly appreciated. Thank you very much in advance

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.