This might relate to a similar problem I had with the first beta, where trying to use an AVAudioPlayer caused the app to hang and spit out a lot of errors and not really work. This was resolved in beta 2 but beta 3 has reverted back to the old behaviour where trying to call prepareToPlay() or play() on a valid AVAudioPlayer instance causes lots of error output (and no sound). Additionally, trying to call prepareToPlay() during an onAppear{ } block for the root view of a SwiftUI app appears to block the main thread while all of this error output is being spat out and causes a significant delay in app launch. I've been able to reproduce this bug in a very simple example app. I have filed a feedback: FB8116155 This is an example of the sort of errors I'm getting: https://gist.github.com/lukeredpath/e9485d0d83e6b5f7acea2eedb98e144c Is anyone else able to reproduce this or having similar problems?

We need to add the above ATS exception to our app - the documentation says to add the NSAllowsArbitraryLoadsInWebContent key set to YES in our Info.plist file which I have done. It also states that justification for its use should be provided when submitting for review. However there appear to be some keys in the Info.plist which are intended for just that - but strangely I cannot find any documentation for these keys anywhere - I get literally zero results when searching for the keys in Google: Can anyone explain what the purpose of these undocumented keys are for and if they can in fact be used to provide a justification for using this exception?

I've been battling with a bug in my app where after presenting a modal sheet from another one (by changing the state that the .sheet(item:) binding is connected to) the binding stops receiving .set() calls which means the backing state never gets reset and the sheets just stop working. Steps to reproduce: You have some .sheet(item:) call with a binding so some @State (e.g. an enum). You set the state to one value to trigger the sheet. Something in that sheet (e.g. a button press) changes that state to another value, dismissing the first sheet and presenting the new sheet. You dismiss the second sheet. Set the state to the first value again - the sheet appears. Dismiss the first sheet - this dismissal will not call the binding.set() function leaving the state still on the first value. At this point trying to set the state to the first value again will no longer present the sheet because the state is already that value (even though the sheet has been dismissed). I was able to reproduce this in a brand new SwiftUI project: https://gist.github.com/lukeredpath/89f6e662265e98912069f51abfdaeb88 The docs suggest that this should work as intended, where a change in the item binding value should trigger a dismissal and new modal sheet - which it does - but once the binding stops receiving .set calls it breaks.