I can't believe this wasn't considered. The warning needs to be removed, and could be added to something like SwiftLint. Maybe a better solution might be a keyword like @CodeableIgnore we could use. Shouldn't have to handwrite codable code for a single ID property... that's now a requirement. If you're testing your code, you should never run into the issues this warning is out to solve anyway.

I ran into this same issue where I had to fall back to the usual Apple Music API and MusicKit is still missing a bunch of features. Every song in a users playlist (found in their library) would report the same error when attempting to play. Each track in these playlists look like: a.3828342394 But the IDs that come from MusicKit search (MusicCatalogSearchRequest), don't have the "a." prefix.. mostly. Some do. removing this prefix with id.replacingOccurrences(of: "a.", with: "") solved the issue for me. I have no idea why Apples media player can't handle these without modification, nor why there's nothing in the documentation that mentions this limitation. Maybe it's just another bug that will go ignored.

Having a similar problem here. We discovered that this is a bug in the CGContext, and only occurs with some images in some PDFs and not others. Interestingly, it doesn't ALWAYS crash either. Still no solution and we're at the point where we may just end up writing our own renderer using Metal. CGContext PDF stuff goes waaaay back and any other open source code we look at, (event PSPDFKit) will have the same issue.

Fantastic feature with zero support from Apple am I right? Loads of folks are having problems with this feature. Calling UserDefaults from within didFinishLoading results in nothing coming back. So if you have launch counters, or code that needs to run first time, this will be triggered incorrectly. Some folks have had entire keychain data wiped because of this feature. It SHOULD be opt in.

Did you report this, because I'm having the exact same issue. Made a ticket, and nothing...

Just jumping in to say the same thing is happening to me. Earlier today, it was all fine. No code changes. Suddenly, it's broken. I kinda through it may have had something to do with playing my music on multiple devices, i.e Music app on my computer while coding, and music app on my device while testing. Stopping the music on one didn't fix this however. Just to be clear. I can PLAY music just fine. Using the API to search for tracks, or load playlists results in this error.

An Answer: The ID of the item in the QUEUE is different to the actual SONG because this allows for songs to appear more than once in the queue. To get the SONG: if let currentEntry = self.musicPlayer.queue.currentEntry { print("CURRENT - \(currentEntry)") if case let .song(song) = currentEntry.item { print("SONG - \(song)") } } IGNORE BELOW UNLESS YOU WANT A RANT I found that the IDs change A LOT too. I've had to rewrite my stuff a few times now trying to make it all work. My app plays music AND sound effects at the same time. Think, ocean sounds layered with music. It's nearly impossible to keep it all in sync and know when BOTH are playing at once, and managing all the different states. SwiftUI is perfect for this, but the MusicKit just isn't there yet. currentEntry is an ObservableObject, but I've had to hide it away in my model, and listen to the updates using Combine so I can keep things in sync. So for playback you need to listen to both currentEntry AND the playbackState property. I THINK. Pretty sure currentEntry can still have a value even if the playbackState is something other than .playing. It amazing that such a simple thing as showing a play/pause image on a song in your UI is so complicated now. I'm attempting to open things up a bit more in my app (support other services like Spotify), so rather than rely on the song ids that Apple has, instead I'll be looking at the ISRC value for comparison. These can then be used to load up music from another service. You could also try matching the song name AND artist, but this also leaves you open to edges cases (though unlikely) but you could also throw in the song length to the check just to be sure. Hopefully you'll get an official answer soon. My guess is that they actually fix the issues with MusicKit come WWDC23. The new APIs are slightly improved in some areas, but completely broken in others. Of course someone will come in and be like "Can you please give us an example". It's very obvious Apple don't use the new APIs in their own products otherwise they would understand this. For example, we only JUST got the ability to even use currentEntry, which is such a huge oversight. Zero indication that this was broken as per the docs. So you go ahead and spend hours implementing something only to realize it can't do what you need it to do. Lots is missing and there's zero guides online besides the basics on how to use this framework. My guess is very few devs are making apps that need music, so feedback has been low. In saying all this, it's fine. I'm glad they're making these improvements, especially around the work they're now doing with their webinars where devs can get help and ask questions about these topics. It'll only improve from here. It's this transition where we find ourselves struggling.

Few years later, still an issue, but just wanted to say that the proposed fix works. I was having problems when panning the map view, the clustering would stop working. The recommendation solves this. Still haven't found a fix for the number increasing in the cluster when toggling dark/light mode... but that's a dev issue really since users can't do that with a keyboard command like we can.

Just chiming in here too. I found I get a memory leak when re-using the player nodes. I have an app that is essentially a sound board. Playing sounds repeatedly would cause the memory to continue growing. I was able to clear this up by calling Stop() on the node before re-using.