Post not yet marked as solved
This is now happening consistently when trying to request with the includes=albums param.
Apple, please, address our concerns about the instability with your API!
Post not yet marked as solved
@JoeKun
How do we use the includeTopResults param over the REST interface?
Post not yet marked as solved
Okay so iOS 17 is out with the latest Apple Music / MusicKit changes and Android is still stuck on an SDK version form 2021...
Any update from the Apple team would be appreciated.
Post not yet marked as solved
I'm seeing this consistently. 3 failed requests in a row before the 4th actually loads.
Hi team, we're a year on and the MPMusicPlayerController is still as nascent as it was back then (especially on macOS). Are there any plans to prioritise the framework from an app developer's perspective instead of just developing it specifically in the context of Apple Music itself?
Developers really want to support Apple Music in their applications but issues like this make it really really hard to justify.
Post not yet marked as solved
3 years later, this is still a show-stopping issue for many different use cases. Did Apple ever respond to your ticket?
Was there ever a mechanism found to get around this like forcing control away from the MPMusicPlayerController? I've tried tearing down my instance, ending event listeners, brute forcing the audio session to be mixed with others...nothing.
Still the same problem. Works perfectly in the foreground and not at all in the background.
Post not yet marked as solved
Apple team, you'd made reference to the fact you're very active when it comes to MusicKit questions. It's 3 years later and the exceptionally slow spin up time for playback on Android is still very much an issue (your SDK is 3 years old too).
Can we get some clarity here?
Post not yet marked as solved
If Apple could respond on any Android MusicKit issue that'd be great.
I'm going to pile on here. This is a basic basic requirement of a Music engine. Other first-party Apple Frameworks handle end-state events, a dedicated custom state needs to be added which rolls up that track end -> last item in queue -> return to pause scenario into an event.
The Android MusicKit SDK can report the end of a track (via the item changed event) btw.
Apologies for being a little hostile, reading the responses from the Apple folks here annoyed me because they're being snippy over what are glaring omissions in a large first-party framework.
Post not yet marked as solved
Apple. Your documentation for both your APIs and SDKs is not workable in their current form. Developers, myself included are having to fight tooth and nail to try and implement the most basic of functionality you provide.
I implore you to document properly and at least bring the docs up to snuff with what Spotify offer in this regard.
There are so few services that actually support Apple Music for this reason so it's well within your power to increase adoption this way.
Don't be the meme of the guy who puts a stick through the front spokes of his bike.
