@joshgrant All I've found in iOS 18 is even more bugs. The most bizarre of these is that when calling "play" on the application player, it plays for about half a second then self-enters the INTERRUPTED state. For good measure, the event is sent twice. This event is documented as being used for an incoming call. Yeah. Right. Obviously, there's no incoming call. Icing on the cake to get sent the event twice in rapid succession. My application is now incapable of starting music playback when it starts up. The user must un-pause manually. And then, you have all the same nonsense with detecting end-of-playback, after several years. Further, previous heuristics now have more "undetected end" bugs arising so even more problems exist with iOS 18 that I have yet to track down. I think this speaks for itself in terms of software quality and Apple's attitude to developers - total contempt. Other platforms are less hassle, cheaper to develop on and have a bigger user base.

So here we are, another year goes by, another new operating system release and no fix. Apple have abandoned developers for Music; the API where implemented is incredibly unreliable with basic design frustrations all over it, while the vendor-provided applications are rife with bugs and bewildering, inconsistent UI design and navigation choices. Apple doesn't care. I'm abandoning Apple Music in all application development from this point and moving it to Spotify, and will be recommending Spotify as a preferred service henceforth.

Was answered in that other thread - another server-side problem that Apple fixed a couple of days later.

This issue has recurred. Previously working integrations with new developer tokens are return 500 responses. I even tried issuing myself an entirely new API key and unfortunately it still returns 500 responses. New Zealand region, if it makes a difference. Apple service status page shows all-green. It is a little disappointing that the API, the most mission critical interface for any developer, should break in this way just one month ago, then break again in apparently the same way just a few weeks later. This breaks the world for music apps. It makes developers of iOS music apps look like idiots, with frustrated users who cannot be given a good answer on what's gone wrong or when it'll be resolved. When will this be fixed, please, and what steps are Apple taking to ensure that this does not break without Apple noticing again in future (e.g. ensuring that the Apple Service Status page correctly reflects a broken API condition)? Thanks,

Hi @JoeKun. I'm delighted to hear that Apple are now engaging more on the forums. I have in the past submitted polite, fully constructed Feedback Assistant reports related to the playback performance of Apple Music and so far been met with silence. I hope to hear back soon. During the months of development, I've read countless posts on these and other forums from other developers facing what sound like exactly the same bugs, spread over several years, during which time sadly no fixes seem to have been forthcoming. I can only hope that at some point there is a concerted effort within Apple to improve the implementation's reliability. No more "failed to prepare to play"! So far, nobody has directly answered the OP's question. This is the primary issue here: Detecting end of playback. It kinda "feels" like people dancing around admitting that it's impossible, at least cleanly. For whatever reason, when the Apple Music API finishes playing a track and there's nothing else in a playlist, it performs the very strange behaviour of entering a paused state and seeking to the start offset of either the first playlist track, or the last playlist track (LATER EDIT: I also do see sometimes behaviour where current position is reported as fractionally after the end of the track, too). I've never been too clear on this because none of its behaviour in this regard appears to be described in the API documentation, so we have to guess and use observation, leaving developers with no idea if they're relying upon behaviour that's meant to be part of the API's contract between implementation and consumer, or just a random observed quirk. There is a "stopped" state for the media player, but it does not enter this state. Consequently, distinguishing between a user initiated pause event or an "actually I stopped playing" pause event, or a "user initiated pause then the user scrubbed a position slider back to the start of the track" edge case thus takes time-consuming coding effort and heuristic fudging, all because the API doesn't enter a stopped state. At the risk of mentioning a second item and building a laundry list, it'd also be lovely if we could set playback volume for our applications. This used to be possible, but then the ability was removed. It's really quite surprising to me that in 2021 we might be using a media playback API where reliably detecting end of playback is very difficult, and setting playback volume is impossible. I really hope that these matters can be addressed with haste.

I note with frustration that the marked answer does in fact not answer the specifically asked question at all although yes, it's very helpful for the OP in answering a different question from the one they asked, which helps them move forward and that's great. The marked answer does tell you how to unobviously fudge the awkwardly different API classes into a player queue, but ignores all of the entirely valid issues that the OP brings up on detecting end-of-track - an elementary and obvious thing to need and available in every other player API I've ever used. It's just extraordinary that the API could be so obtuse - the playback status is nonsensical (paused), indistinguishable from other events (speaker disconnect), the now-playing items don't make sense (sometimes nil, sometimes not) and the current position is meaningless. Indeed, when it's not zero, often the current position when the event arrives will be returned as either slightly before the song's stated duration, or even slightly after the end of the track! How on earth it's possible to be this completely wrong is a mystery - we've had other remarkably robust APIs for streaming music since dialup in the 1990s. The next question the OP will have is why their queue of music keeps just randomly skipping tracks - and indeed in the worst case, with looping turned on, can even get stuck in a tight loop skipping every single track endlessly - because of the years-old "failed to prepare to play" bug. And that's before we even get to all the new bugs added with lossless, wherein, of course, nothing else actually got fixed - I mean, heaven forbid we improve product quality rather than just jamming in even more buggy features, right? The MediaPlayer API is a very poorly designed interface but on top of that, it's by far the most buggy API I've ever worked with in over 25 years of professional development plus my spare time hobby projects. Apple - hang your head in shame; it's atrocious. I'd be so, so happy to hear that you're going to do some serious engineering to fix it up, but I'm sadly very confident that you just don't care at all.