[iOS 26 beta] Unexpected Behavior: didRegisterForRemoteNotificationsWithDeviceToken Invoked Before User Notification Authorization on iOS 26 Beta

Hahahaha Are we ready for this new one? Lol. I see what you’ve been doing. Smart! I’m sure I don’t get the messages. I’m just glad we were able to do so i a timely manner.

Feedback reported with sysdiagnose file https://feedbackassistant.apple.com/feedback/18897587

You have not specified whether at the point of you receive the delegate callback you have already made the call to registerForRemoteNotifications() or not.

If you have, and the timing seems to be different, that could be due to a small implementation detail change.

Indeed, the two calls - authorization request and token request - are not interdependent. You can have one without the other even. The authorization request only relates to your app being able to show visible notifications. Where the token request call relates to being able to send push notifications. There is no rule that says one has to be done after the other, or the authorization needs to be complete before you can register for notifications and receive a token.

So, it is possible that some timing change is calling the delegate earlier for your app - depending on how your code flows with regards to originating the two calls to initiate the actions.

If you have NOT called registerForRemoteNotifications() at that point, but still getting the delegate callback, that is unusual but not unexpected or abnormal.

Especially in your case, where you say you are getting a cached token, If you have called registerForRemoteNotifications() in an earlier session (run) of your app, and your app has been closed before the token was returned, the system will cache the token, and may send it to your app via the callback the next time it is run. I suspect, that may be happening if in your case you are getting the callback even before making the call to registerForRemoteNotifications()

In any case, please update your Feedback report to clarify the flow in your legacy app, so the team looking at it has adequate information.

As for this only happening on iOS 26, like I said, this could be a small change in the implementation details that may have changed the timing so the order of calls have changed. In any case, this is explainable, and unless you have made some hard assumptions on the timing and sequence of the calls and callbacks, there should be no harm.

Argun Tekant /  DTS Engineer / Core Technologies

The client requests registerForRemoteNotifications, and then receives a token delegation before the user has acknowledged the notification permission.

For your reference, here are the relevant logs:

<PushToTalk> <ALA_SIGNAL>: Enter -[PushNotificationManager registerForPushNotification:] [2442] PushNotificationTypeRemote Timestamp: 2025-07-24 13:06:12.368408+05:30 <ALA_SIGNAL>: Enter -[AppDelegate application:didRegisterForRemoteNotificationsWithDeviceToken:] [2442] Timestamp: 2025-07-24 13:06:13.575766+05:30

In this situation, if the user subsequently acknowledges the notification permission, and the token received during the initial delegation is not the same as the one received during the registerForRemoteNotifications request, will the client receive another token delegate?

Notification permission and token delivery are not tied together. You can indeed even get a token without getting the authorization (albeit not being of much use as the notifications won't be shown).

I suspect this is due to a changed timing that causes the delegate call to be faster. If this is a problem, you can wait until you have authorization to make the register call.

I theorized that the call you receive could be due to a cached token IF you have not been calling register at that point. As you say you have already called it at that point, there is no reason to presume you will get a second call.