There is a misconception in rules that drive tips behaviors. They should be distinct rules for invalidation and distinct rules for dismissal. It should be possible to customize close button as well. There are users who get rid of hint before they try. They would close the tip with the intention of dismissal. There are also users who don't try before learning about the action. They would close the tip with the intention of invalidation.

I think that in such a way, you can easily end up with a recursive accumulation of the view stack in case of a bad connection or so, crashing your app. I'd suggest assigning a new unique identifier to the asynchronous image on placeholder appearance instead, in order to retry without adding to the view stack. Placeholder() .onAppear { Task { try await Task.sleep(for: .seconds(1)) retryID = UUID() // forces image to reload } }

In my case it doesn't change anything. Crash logs from TestFlight are still falsely empty.

Hello, thanks for reaching out! I've already reported the issue to the Feedback Assistant with more detailed information. Here is the number: FB16301047 This also rarely happens when playback progresses without skipping tracks, but only after the queue is altered. In my case, this was done by removing an entry and changing the order of tracks preceding the current entry in the loaded playlist. I've noticed that the issue always occurs after altering the first entry in the queue.

I can confirm that removing .tracks from included properties solved a similar issue with ApplicationMusicPlayer crashing with applicationController: xpc service connection interrupted error after skipping back or forth over the queue created from the playlist.

Is there any way to get a playback offset for preview assets? It could be very interesting to probe audio characteristics from those audio samples such as tempo and rhythm. Then use them for autosync crossfade.

If it comes to preloading... Why is artwork not preloaded for the upcoming entry in advance? I have noticed considerably high latency (~1-2s) in presenting thumbnails on playback control embedded in the notification (so-called Now Playing) on queue shifting forward. The issue affects not only the Application Music Player but also the Music app. I have tried to tweak it by firing a request for artwork, but it seems that cached responses for maximum artwork size are not reused by the Music app.

Me too. ^^