The actual issue here was completely unrelated to the way bindings update. I added a sleep inside of a Task to more clearly see the animation impact and that was having side effects on the animations. I would not have expected a sleep in a Task to impact animations triggered by binding changes outside of that task, but that's clearly not the case. Probably wise to not sleep anywhere that is not an async marked function if you're this close to SwiftUI.

Here's a clip of the incorrect effect in action: https://imgur.com/a/NqJRVra finalTemp is set to 0 when the displayed temp value turns into "..." and then you can see the wiggle as it attempts to interpolate from 0 to the new value, but it's already at the new value.

FWIW, my feedback was resolved with "potential fix identified for an upcoming OS release." Hopefully that means a subsequent 16.1 beta and not 16.2.

Hello again old thread, it appears that currentPlaybackRate is broken in the same way on iOS 16.1 beta 1. This does not appear as a known issue in the release notes. Can we get confirmation that this is returning for the public release @JoeKun?

Hi @FrankSchlegel, It appears that using AVCaptureDevice.authorizationStatus and AVCaptureDevice.requestAccess(for: .video) in the extension works under Ventura where the extension runs as the logged in user, but not under 12.4 where the extension runs as _cmiodalassistants. It would be nice to know if there is a workaround for 12.3+ or if developers wanting to utilize camera streams from this extension will have to set their min target to 13... doing all the camera process in the extension is "the intent behind the design" according to @ssmith_c.

I'd like to add my disappointment in how this was handled. I also have an app released on the App Store that relied on this functionality and just like that... it's completely useless for my customers. What is the point of offering the MusicKit framework if all we can build is a glorified Music app with exactly the same features?

Thanks @JoeKun, that is very helpful context. I've filed similar feedbacks before on adding items to the queue and not immediately being able to play the queue. The transient behavior you mention makes sense for these issues as well, it would be nice to have some more info in the MusicPlayer or Queue docs about what to expect when enqueuing items. You mention the MusicPlayer getting notified that the entries are all resolved - do you have a sense of how best to tie into this notification so I can ensure I take certain actions only after all entries are resolved?