I’m developing a third-party Apple Music streaming app using MusicKit (ApplicationMusicPlayer + catalog requests).
Issue:
Whenever Apple releases an Apple Music update that shows the “What’s New?” onboarding/modal screen in the native Apple Music app, MusicKit in our app completely breaks for all users.
Attempts to play anything (queue, prepareToPlay, etc.) fail silently or with service-related errors.
Playback and most MusicKit operations remain broken until the user opens the native Apple Music app, dismisses the “What’s New?” screen, and returns to our app.
After that single native interaction (we deliberately stopped users from going any further within Apple Music to verify this), everything works perfectly again.
Reproduction Steps:
- Apple Music receives an update with “What’s New?” screen.
- User launches our third-party app and attempts playback.
- MusicKit fails.
- User opens Apple Music → dismisses modal → returns to our app.
- MusicKit works again.
Expected Behavior:
Third-party MusicKit apps should not become non-functional because the native Apple Music app has a pending onboarding screen. Shared backend services (account readiness, tokens, subscription state, etc.) should initialize independently.
Environment:
iOS 26.4.2
Devices verified to be affected:
- iPhone 13 Pro
- iPhone XR
- iPhone 15
Workarounds attempted:
- Re-requesting MusicAuthorization
- Recreating ApplicationMusicPlayer
- Stopping/re-queuing
- Background/foreground app
None resolve it without the native Apple Music interaction. This appears to be a recurring integration fragility with shared Apple Music services.
Has anyone else seen this? Any recommended recovery path or API to force service initialization?
Thanks!
You've narrowed this down well, and the corroborating reply confirms it isn't device-specific. What you're describing isn't expected behavior — third-party MusicKit clients shouldn't lose access to playback because the native Apple Music app has a pending post-update onboarding modal. Shared service initialization (account readiness, subscription state, and so on) should happen independently of the native app's UI state, and the fact that a single Apple Music launch + modal dismiss restores everything to working order points to some shared component lazy-initializing only when Apple Music itself runs.
A few things:
On a "force service initialization" API: there isn't one in public MusicKit, and adding one wouldn't be the right fix — the underlying services shouldn't get into a broken state in the first place. That's the bug.
Please file a Feedback Report. Even if other developers have already filed, duplicates matter — independent reports count as a signal of impact, so each FB from an affected app raises visibility of the issue. Include your reproduction steps, the iOS version, the affected devices, and the workarounds you've already tried (it saves a triage round). If you post the FB number back here, that helps me track it.
Interim workaround at the product level: there's no reliable code-side recovery in the current API. The pragmatic mitigation is to detect the failure and surface a one-line message in your UI ("If playback isn't working, please open Apple Music once and return.") — not satisfying, but it converts a silent failure into a recoverable state for your customers without making them debug it.
I'll keep an eye on this thread.
