The fact that there is still no solution to this issue is disheartening.

I have also filed multiple bugs (over the years). None of which were resolved, none of which were fixed. I noticed that the Frameworks Engineer stated: "Beyond that, you might have noticed that we are making a real effort to engage with the developer community on the forums, and that we try to be pretty responsive about any inquiries tagged with MusicKit." There seems to be a lack of response now. Music Kit could be great. It just needs to be made great. It's obviously meant for Apple Music and not meant for developers to use. Not having any volume control for a MPMusicPlayerController is utterly absurd (honestly if it's not surrounded by legality rationale then someone needs the boot). Instead we must adjust the system master volume and piss off the end-user and be the ones to explain to them that this is "what we have to work with". A notification for end of song play would be great too. All in all, if you cannot make improvements because of Apple Music, perhaps Apple Music's Music Kit needs to be solely internal to Apple, and a developer friendly Music Kit should be developed for developers. Please.

This behavior appears to stem from a latent audio session configuration issue within AVAudioPlayer, particularly noticeable on first playback attempts when routing audio over Bluetooth. Despite some recommendations on Stack Overflow, invoking play() on a background or serial queue has no measurable impact on the delay. Through repeated testing, I’ve consistently observed that the initial playback results in a delay of approximately two seconds, during which the audio seems to discover the external speaker and then transitions to the correct Bluetooth output while the player progresses through audio playback. This only occurs during the first use of AVAudioPlayer; all subsequent plays perform as expected. The most effective workaround I’ve found is to immediately play a short silent audio clip after application launch. This appears to pre-initialize the audio session and forces the underlying audio routing to be resolved early, avoiding the lag during actual user-initiated playback. While not at all ideal (the solution makes me cringe), this approach has proven stable and effective.