Device Token Not Invalidated After App Uninstall (iOS 26.4 Beta)

By saying "token is invalidated" I assume you are talking about receiving a 410 Error for your push request.

This is not an issue new to iOS 26.4. It seems like it just happens that you may have encountered it just yet, or have not noticed it before.

The 410 status was never meant to be a signal for developers to determine that the app has been removed.

It is only a signal to the push provider server that they should stop using that token. Although this could mean that the app may have been removed, it could also mean the token has changed while the app is still installed.

The app token may change due to certain system events. Deleting and reinstalling the app, restoring the device from a backup, resetting the device (and then installing the app), certain major iOS updates, transferring all apps and data to a new device are all events that will cause the token to change. Because of this, it is recommended that apps register for remote notifications at every launch. If the token has changed, the app would need to update the push server to use the new token for the device/user. If an existing token is receiving 410, it might be that the app is still installed but one of these cases occurred.

Indeed if you look at the description of the 410 status, it says "The device token is no longer active for the topic.". Topic, in most cases means "your app". It is an indicator of the state of the token, not the app. And trying to determine whether an app has been deleted or not based on the 410 result is an off-label use that would not guarantee the results you might expect.

Additionally, beginning the return of the 410 state is non-deterministic for the sole purpose of discouraging this interpretation.

To summarize this interpretation: Existence of a 410 status merely indicates that the token is no longer valid and should not be used anymore. It does not mean the app has been deleted. Nor, the lack of a 410 status mean the app is still installed and receiving notifications.

If it is important to your use case that you know notifications are being received, my suggestion would be to link the token to a user account rather than pair it with IDFV, as IDFV is not supposed to be an indicator to determine a unique user either.

Thank you for your response.

I understand the following point:

"To summarize this interpretation: Existence of a 410 status merely indicates that the token is no longer valid and should not be used anymore."

However, in some cases it is difficult to associate a device token with a user account because the app does not provide a login feature or user accounts.

In our case, the following scenario can occur:

1. The user installs the app on a device (IDFV: A, DeviceToken: a)
2. The user uninstalls the app
3. The user reinstalls the app on the same device (IDFV: B, DeviceToken: b)
4. Push notifications are sent using both DeviceToken: a and DeviceToken: b
5. As a result, two push notifications are delivered to the same device

If we cannot associate the device token with a user account, what would be the recommended way to prevent duplicate push notifications being delivered to the same device in this situation?

I would appreciate your guidance.

I'm not sure associating the push device token to a user account would even solve the problem, unless you only allow one token per user account. But that would prevent users from using multiple devices (such as their iPhone and iPad) with the same account.

Our app requires the users to login and we do associate the push device tokens to the respective user account, but we allow multiple tokens per account. And we have noticed for a while that these tokens stack up, even if users only use one device. I don't think we had a case of the same push notification being sent multiple times to the same device yet though. (Haven't tested with iOS 26.4 Beta).

Push notifications are sent using both DeviceToken: a and DeviceToken: b. As a result, two push notifications are delivered to the same device

I understand the two notifications being sent for the same device, but it is not possible that the device is receiving both those notifications if indeed one of them is being sent using the token that belonged to the now deleted app. Once the app is deleted the device will no longer accept any notifications sent using that token.

If the device is indeed receiving two notifications back to back, then there must be something else going on there.

If you can share the apns-id of two such notifications sent and received (within the last couple of days), we can double check, but what you are describing should not be possible.

@HolgerDe

Thank you for your comment.

I have the same understanding as you.

In our case, we observed the following behavior on iOS 26.4 Beta:

1. The app was installed on the device before the OS was updated.
2. The device was then updated to iOS 26.4 Beta.
3. After the OS update, the user uninstalled the app and reinstalled it.
4. The app obtained a new device token after reinstalling.

After that, we sent push notifications using both:

• the device token that was obtained before the uninstall, and
• the new device token obtained after reinstalling the app.

As a result, we observed that two push notifications were delivered to the same device.

@Engineer

Thank you for your previous response.

We re-verified the behavior, and it appears that the device token that was active before the app was uninstalled is still valid. As a result, two push notifications were delivered to the same device.

If you can share the apns-id of two such notifications sent and received (within the last couple of days), we can double check, but what you are describing should not be possible.

As requested, I am sharing the details below.

Notification sent to the latest token (obtained after reinstalling the app)

Request

curl -v --http2 \
--cert cert.p12: \
--cert-type P12 \
-H "apns-topic: {{bundle_id}}" \
-H "apns-push-type: alert" \
-d '{"aps":{"alert":"test1"}}' \
https://api.sandbox.push.apple.com/3/device/{{latest_token}}

(timestamp: 2026-03-13T04:37:20Z)

APNs response

apns-id: 9963707F-7469-1CB3-231A-66B9EC9CFEB3

Xcode log when the notification was received in the foreground (real device)

- - - Push Payload Start - - -
Push received timestamp: 2026-03-13T04:37:24Z
[AnyHashable("aps"): {
  alert = test1;
}]
- - - Push Payload End - - -

Notification sent to the old token (obtained before uninstalling the app)

Request

curl -v --http2 \
--cert cert.p12: \
--cert-type P12 \
-H "apns-topic: {{bundle_id}}" \
-H "apns-push-type: alert" \
-d '{"aps":{"alert":"test2"}}' \
https://api.sandbox.push.apple.com/3/device/{{old_token}}

(timestamp: 2026-03-13T04:37:26Z)

APNs response

apns-id: 113436F8-5E1D-F9A3-D919-A08BCDB59608

Xcode log when the notification was received in the foreground (real device)

- - - Push Payload Start - - -
Push received timestamp: 2026-03-13T04:37:28Z
[AnyHashable("aps"): {
  alert = test2;
}]
- - - Push Payload End - - -

Both notifications were received on the same device.

Could you please help confirm whether this behavior is expected?

Hello @ShotaroAoki

Thank you for this information. We were able to confirm that notifications sent to the old token are indeed being delivered to the device still.

This is not the expected behavior. Once an app is uninstalled, the token it used to have should no longer result in a delivered notification.

We have now found the root cause of this, and it will be fixed in an upcoming iOS update.

While in the meantime this could cause some inconvenience, in the long run you can expect that once an app is deleted from a device, the token will no longer work.

The rules for receiving an error (Status 410) about a no longer valid token at a random time afterwards still holds - that is by design and not going to change.

Hello, @Engineer

Thank you very much for investigating this so quickly.

I understand that the root cause has been identified and that a fix will be included in an upcoming iOS update. We appreciate your efforts and look forward to the fix.

I also understand your explanation regarding the behavior of invalid tokens and the fact that the timing of receiving a Status 410 error is intentionally non-deterministic and will not change.

To help us explain this issue to our app users, I would like to ask a few additional questions:

1. Which iOS versions are affected by this issue?
2. Under what specific conditions does this issue occur?

In particular, we would like to better understand the situations in which an old token may still be treated as valid after the app has been uninstalled.

Thank you for your assistance.

Unfortunately as the issue is still being investigated, we do not have the answers you seek.

We suspect the issue may have started with iOS 26. The root cause is not determined yet, but we believe there is a specific trigger for this issue to surface - that is, it does not effect all apps that get deleted and re-installed every time, all the time.

All that will be part of the investigating and fixing process.