Musickit SDK for Android broken after Apple Music app update

I’m experiencing the same issue.

Device: Google Pixel 8a

Apple Music version: 6.5, installed from Google Play

After the user successfully signs in through the new Apple Music authentication UI, the activity returns RESULT_CANCELED, and authManager.handleTokenResult(data) reports USER_CANCELLED, even though the user did not cancel the flow.

Logcat shows Successfully authenticated the account, followed by Failed to post account changed event with ams.error Code=1, and then DialogConnectorViewModel.cancelAction().

This flow worked correctly before the Apple Music update.

I can confirm the same regression with a standalone minimal reproduction app.

Environment: Device: Google Pixel 8

Android: 16 / API 36

Apple Music: 6.5.0 (versionCode 1580)

MusicKit authentication AAR: musickitauth-release-1.1.2.aar

Developer token endpoint returns HTTP 200

Developer token was tested with two separate Apple Media Services keys/configurations

The user completes Apple Music sign-in and does not cancel. Logcat then shows:

Successfully authenticated the account.

Successfully completed IdMS authentication

AMSIDMSAuthenticationCompleteAction succeeded

Failed to post account changed event: ams.error Code 1

DialogConnectorViewModel.cancelAction()

The Activity subsequently returns:

resultCode = RESULT_CANCELED

returned Intent = non-null

Intent extras = [music_user_token_error]

music_user_token_error = 0

TokenResult.isError = true

TokenResult.error = USER_CANCELLED

musicUserToken = null

The same result occurs in both the production application and a brand-new minimal Android app using Apple’s documented authentication flow. It also persists after using a completely new Media ID, private key, and Key ID. The equivalent iOS authentication works with the same backend.

This appears to be an Apple Music 6.5.0 Android regression after successful IdMS authentication, specifically during the internal account-change/dialog completion step. The SDK is reporting a user cancellation even though the user completed authentication.

Could Apple please confirm whether this is a known issue and whether an Apple Music Android update is planned?

Update: I downgraded the Apple Music Android app from 6.5.0 to 5.2.1 using APKMirror. Without changing my application, backend, developer token, Media ID, or Media Services key, authentication immediately succeeded. RESULT_OK was returned, TokenResult.isError=false, and a valid Music User Token was received. Upgrading back to 6.5.0 reproduces the USER_CANCELLED failure. This strongly indicates the regression was introduced in the Apple Music 6.5.0 Android app.

Update: I downgraded the Apple Music Android app from 6.5.0 to 5.2.1 using APKMirror. Without changing my application, backend, developer token, Media ID, or Media Services key, authentication immediately succeeded. RESULT_OK was returned, TokenResult.isError=false, and a valid Music User Token was received. Upgrading back to 6.5.0 reproduces the USER_CANCELLED failure. This strongly indicates the regression was introduced in the Apple Music 6.5.0 Android app.

@joneswr is right. I am facing same issue. its works with old apple music app version 5.2.1 but not with new version 6.5.0.

Still broken on 6.5.1 / 6.5.2 — and the symptom has changed: it no longer returns at all

Adding a data point that may help narrow this down, and one distinction that I think is worth drawing clearly.

Environment

• Apple Music for Android 6.5.2 (1586) and 6.5.1 (1583)
• MusicKit auth AAR: musickitauth-release-1.1.2.aar
• Pixel 7 / Pixel 8
• Apple Account with an active Apple Music subscription — Home, Library and Recently Played are all populated and playback works normally, so this is not a "no subscription" case.

The outcome depends on whether the Apple Music app is already signed in.

Case A — Apple Music is signed OUT: this works

1. Sign out inside the Apple Music app.
2. Start authentication from the third-party app (AuthenticationManager.createIntentBuilder(devToken).build()).
3. Apple Music presents its sign-in screen; complete the sign-in.
4. The approve/consent screen appears and a valid Music User Token is returned. RESULT_OK.

Case B — Apple Music is already signed in: the flow never returns

1. With Apple Music signed in (active subscription).
2. Start authentication exactly the same way.
3. Apple Music opens its SDK landing screen and shows a loading spinner — and stays there indefinitely. We left it for over 100 seconds with no change. The approve/consent screen is never shown, the screen never closes, and no result is ever delivered to the calling app. There is no timeout.
4. The only way out is the Back button, which then delivers USER_CANCELLED to the calling app.

Note that a successful Case A run leaves the account signed in — so an immediate retry reproduces Case B.

This is not the same symptom that was reported for 6.5.0.

As I understand the earlier reports in this thread, on 6.5.0 an already-signed-in account would cause the Apple Music screen to close itself and return CANCELLED more or less immediately. The flow terminated — it just terminated with the wrong result.

On 6.5.1 / 6.5.2 the trigger looks the same (already signed in), but the ending is different: the screen does not close and nothing is returned at all. The USER_CANCELLED we end up seeing is produced by the user pressing Back to escape the stuck screen, not by the SDK deciding anything.

From an integrator's point of view this is worse than 6.5.0. On 6.5.0 control at least came back to the calling app, so the app could show an error and offer a retry. Now the user is left sitting on a screen that never resolves, and the app is never told that anything failed.

Why this matters in practice: the case that works is the one where the user is not an active Apple Music user. Anyone who actually uses Apple Music is signed in, and therefore lands in Case B every time. The "sign out of Apple Music first" workaround does not hold up in production, and it will also bite on token renewal — by then the user is signed in again, so they are back in Case B.

Our reading is that the already-signed-in path inside the SDK landing screen never reaches a terminal state: when the account step has nothing left to do, the screen neither advances to the consent screen nor returns an error to the caller.

An official acknowledgement would be very welcome here. This has now been broken across 6.5.0, 6.5.1 and 6.5.2, the failure mode has changed without being fixed, and there is no workaround an integrating app can apply on its own.

Please consider filing a bug report about this so our engineering teams can investigate this issue. A resolution may involve changes to Apple's software. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

I have submitted Feedback with the above information as well as additional information.

FB24520173

I completed another controlled test with Apple Music 6.5.2. Environment: Google Pixel 8 Android 17 / API 37 Apple Music 6.5.2, versionCode 1586 musickitauth-release-1.1.2.aar Standalone minimal reproduction app The developer-token endpoint returned HTTP 200. Apple Music opened SDKLandingActivity, then logged: ams.error Code 8: failed to load the Mescal prime session ams.network Code 303: failed to parse a Finance response Missing bag key: isEligibleForPhoneCreate WebContainer subsequently reported Bootstrap: Succeeded Despite reporting a successful bootstrap, SDKLandingActivity remained on its loading spinner. It did not show consent or return any Activity result. After approximately 66 seconds, I pressed Back to escape the stuck screen. Only then did the caller receive: resultCode=RESULT_CANCELED music_user_token_error=0 TokenResult.isError=true TokenResult.error=USER_CANCELLED musicUserToken=null This independently confirms the 6.5.2 non-terminating authorization behavior. The USER_CANCELLED result is generated only after the user presses Back to escape Apple Music’s stalled SDK screen; it is not the original cause of the failure. The same standalone application and developer-token service successfully returned a valid Music User Token with Apple Music 5.2.1.

I am also facing the same loader issue with Apple Music authentication using MusicKit. It was working with Apple Music version 6.5.1, but after updating to version 6.5.2, it is not working again. It just keeps loading, and nothing happens.

Additional impact: Apple Music 6.5.2 authentication regression prevents playback of newly released music

I want to emphasize the urgency and practical impact of this issue.

Apple Music 5.2.1 can still complete MusicKit for Android authentication, but it cannot reliably play some newly released songs whose current Apple Music catalogue IDs are larger than the range handled successfully by that older player.

For example, newly released tracks returned by the Apple Music API have valid catalogue/playback IDs such as:

6778161147

6797908352

6798544240

The API returns valid metadata, playParams, duration, and preview information for these records. PartyAux preserves the complete ID as a string and passes it to MusicKit without truncation or numeric conversion. However, with Apple Music 5.2.1, the selected item may be acknowledged while playback position never advances and no audio begins. Older catalogue IDs continue to play on the same device.

Updating to Apple Music 6.5.2 is not currently a solution because MusicKit authorization stalls inside Apple Music’s SDKLandingActivity. It remains on the loading spinner and never returns a Music User Token. If the user presses Back to escape, the calling application receives:

RESULT_CANCELED

music_user_token_error=0

TokenResult.isError=true

TokenResult.error=USER_CANCELLED

musicUserToken=null

This leaves Android MusicKit applications trapped between two incompatible outcomes:

Apple Music 5.2.1 authenticates, but cannot reliably play some newly released catalogue records.

Apple Music 6.5.2 should support the current catalogue, but its MusicKit authorization handshake does not complete.

There is no viable application-side workaround for newly released songs. Catalogue IDs cannot be truncated or replaced because Apple documents them as string identifiers, and the Apple Music API does not provide third-party applications with an alternative full-track streaming mechanism.

Please prioritize a fix for the MusicKit authorization flow in Apple Music for Android 6.5.2 or provide an updated, supported Android MusicKit authentication SDK. This regression now prevents third-party Android MusicKit applications from both authenticating with the current Apple Music app and reliably supporting newly released music.

Existing Feedback report: FB24599163

Related Feedback report: FB24520173

Related forum thread: https://developer.apple.com/forums/thread/838633