I know I’m resurrecting an old thread but this problem is still not resolved. When writing my player code for Apple Music I encountered all the issues @adh1003 mentioned. all we want is to have some way of being notified when song finishes playing. I tried to code a workaround for it but at this point I feel it’s just impossible. The best way I came up with was waiting for state changed notification and checking if player’s playback time is greater than track’s duration, but that doesn’t work if user presses „Skip” button on lock screen Of course player’s playback time being greater than track’s duration seems like a bug but at least it’s somewhat helpful… @JoeKun to be honest if framework’s behaviour had to be dumbed down because Apple Music app had trouble deciding if „Not Playing” label should be displayed it means that your programmers are not up to task. If the player actually changed its state to „.stopped” our lives would be much easier I recently worked with Spotify SDK for iOS and that API actually reports correctly about the state changes so I don’t know why Apple’s own framework cannot This issue is literally the only thing that prevents us from creating our own usable wrappers around MPMusicPlayerController. At least in my case, I managed to work around other issues but this one is the most frustrating This API has been left basically unchanged for 12+ years now so I’m not holding my breath but I was excitied when I saw that @JoeKun has been very active in responding to feedback here. Thanks

I also encounter this issue when debugging async code. In 99% cases I cannot print values using the po and I'm getting such message po result.queue.count error: expression failed to parse: error: <EXPR>:8:1: error: cannot find 'result' in scope result.queue.count ^~~~~~ This doesn't happen in synchronous code XCode 14.1

This issue still is still occurring on iOS 16.3.

This is still an issue on iOS 16.4 beta 1

@JoeKun Bumping the thread, this functionality is crucial to a music player API

It is baffling that this feature got silently removed after iOS 15.0 but there is no word about deprecating those functions. It's a real shame, the like/dislike/bookmark commands allowed us to give users more control without unlocking their device. I hope they will be supported again some day

This issue started appearing for us all of a sudden a few days ago when new license agreement had to be accepted. We did accept it and then started seeing the same messages as listed above. This is so infuriating, we've been stuck for 3 days now without being able to install/debug our app and none of the solutions worked. Can anyone from Apple please talk to us?

I'm having the same issue. artwork field is not nil but it doesn't return any image when .image(at:) method is called. Did you manage solve it?

After few updates to iOS this issue still persists. Apple please take a look at it, using MusicKit in the app is currently not viable because of it

I've submitted feedback to Apple, hopefully this gets resolved quickly

I've modified my method slightly to use more modern APIs for reading the files but the result is the same, after few hundreds of reads the MusicKit chokes and stops working completely. I cannot perform any requests like MusicLibraryRequest or play anything using MusicPlayer API fileprivate let artworkQueue: OperationQueue = { let op = OperationQueue() op.underlyingQueue = .global() return op }() fileprivate let artworkCoordinator = NSFileCoordinator() extension Song { func artworkImage(for size: CGSize, completion: @escaping (UIImage?) -> Void) { let imageURL = artwork?.url( width: Int(size.width), height: Int(size.height) ) guard let imageURL, imageURL.scheme != "musicKit" else { return completion(nil) } let intent = NSFileAccessIntent.writingIntent(with: imageURL) artworkCoordinator.coordinate( with: [intent], queue: artworkQueue ) { error in guard error == nil, let imageData = try? Data(contentsOf: imageURL), let image = UIImage(data: imageData) else { return completion(nil) } completion(image) } } }

@JoeKun in my experience there is no difference between using new APIs like ApplicationMusicPlayer on iOS 15-17 and MPMusicPlayerController (possibly because it’s just another layer of abstraction), calling prepareToPlay within a Task also causes the UI to slow down and it often fails when trying to schedule playback of large music collections

@JoeKun I know this thread is pretty old and most probably nothing is gonna change within the API but can you give us any explanation as to why reading queue from system music player is not possible, only from application music player? I just can’t understand what would be the reason for that, it’s such an essential feature for every music playing app and ever since MPMusicPlayerController exists it seems to me that it is made difficult to work with on purpose. I’m just talking about reading the queue, not editing it in any way although it would be nice. And I know that application music player gives us those abilities but it is much less stable than system music player and often fails to play anything with numerous prepareToPlay errors thrown. So we have to choose from offering users more functionality or more stability, I just don’t know why we can’t have both. Those issues like I said are over a decade old at this point so I (and my other colleagues) gave up any hope for a fix. And yes I filed multiple feedback repoerts regarding these issues, without any reply. The iOS 15 APIs didn’t fix any underlying issues with playing from Apple Music, they are just a bunch of wrappers on top of classes that have the same bugs since iOS 3.0! We need a framework that is built from ground up not such nonsense