Starting some time during the iOS 17 beta period, I've been seeing unusual playback rate behavior. I have an app that configures a queue of tracks to play and then sets the playback rate at the start of each new track, getting notified of each new track by observing MPMusicPlayerControllerNowPlayingItemDidChange. In iOS 17, I've noticed that setting the playback rate while an app is in the background will not actually change the playback rate. It appears to, and MusicPlayer.state.playbackRate returns the playback rate that has been requested, but the actual playback rate remains at whatever value it was previously. This is not the case when the app is in the foreground, setting the playback rate works as you would expect, updating the actual rate of playback as well as the value returned from the MusicPlayer. In iOS 16, these playback rate changes would occur normally, regardless of the state of the app in the foreground or background. Given the incorrect rate information coming back from the MusicPlayer state, this would appear to be an unexpected change. I've looked in the SDK diffs for any intentional changes for how playbackRate works and I haven't seen anything new or any new tech notes on the subject. Has anyone seen anything like this in their own implementations?

I put together a small view in SwiftUI which shows a temperature gauge and then hooked it up to a simple animation like so: Arc(temp: finalTemp).animation(.easeIn, value: finalTemp) This works great, it animates nicely when I set the temp from the initial value of 0 to whatever the finalTemp value is. When refreshing this data, I want to display a placeholder state and animate this view back to 0 and then when the data arrives, up to its new value. I attempted this by adding a @Binding var placeholder: Bool to the view and an onChange handler for the placeholder binding: .onChange(of: placeholder) { _ in    if placeholder == true {      finalTemp = 0    } else {      finalTemp = 80    } } However, I can't get the view to animate back to 0 when the placeholder binding is set on. The change handler is called correctly and the finalTemp state is set to 0 as I expected, but the animation never occurs and the view stays reflecting the previous value. When the placeholder binding is toggled false again, the view does update and animate to the new value, in fact it wiggles like it's easing all the way from 0. From a UIKit perspective, this strikes me as a classic case of not running an animation on the main thread. But every call that sets finalTemp occurs on the main thread and I don't see how anything else I'm doing would push a SwiftUI animation onto a thread other than main. What am I doing wrong that prevents the view from animating to zero in the placeholder state?

Hi there - I'm developing an app utilizing MusicKit and I frequently update the queue with new entries while the playlist is currently playing. Occasionally I see this message in the console: [Playback] Inserting entries at the beginning of the queue because previous entry (MusicPlayer.Queue.Entry(id: "4B9D0B42-95E4-4F4C-B9A2-7D25F0BB4971", transientItem: Song(id: "1089596553", title: "Twin Turbo", artistName: "Sensible Soccers"))) is unexpectedly transient: [MusicPlayer.Queue.Entry(id: "21B1233B-44ED-48AE-9739-6045AF5FE170", transientItem: Song(id: "1607400995", title: "Don't Be Afraid (feat. Jungle)", artistName: "Diplo & Damian Lazarus"))] What does this mean? What can I do to prevent it from happening?

Has anyone been able to successfully use MusicCatalogSearchRequest in a playgrounds app? I have configured my playground similar to a regular app: app id with automatic music token generation turned on, music access authorized within the app itself, but whenever I query MusicCatalogSearchRequest I get an error thrown with .developerTokenRequestFailed. Considering musickit is restricted in the sim, it would not surprise me if it was the same in playgrounds but it would be super helpful if I could prototype with musickit in playgrounds 4!