How do APNS HTTP/2 and APNS HTTP/1.1 Work together?

I reread the docs and saw that the Feedback Service was listed in the "Legacy Information" section of the reference below.

In that section, "when a remote notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that devices's token to its list". This information is returned in the connection.

The new HTTP2 interface looks like it takes care of the feedback service as seen in one of the status codes available in the the request's response.

In the section "Apple Push Notification Service: Communicating with APNs", it has a status code for the APNs response:

"410 The device token is no longer active for the topic."

The whole point of the feedback service was to provide information on when to stop sending remote notifications that will fail to be delievered. This "feedback" is now available in the 410 status code.

You don't need both services. The provider server should use the new HTTP2 protocol as the prefered way to interface with the APNs.

# Reference: Local and Remote Notification Programming Guide

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW1

LazyInstantiation is correct about the most important point:

> You don't need both services.

My suspicion, although I can't back it up with documentation, is that the legacy protocol and the new HTTP/2 protocol operate in entirely separate "pools," and as a result, failed deliveries via HTTP/2 would never trigger a change in the feedback service. That said, there's no reason to be using both protocols at the same time. If you CAN use HTTP/2, you absolutely should for a variety of reasons (immediate status reporting being a very important one).

As one bit of hair-splitting/clarification, the old protocol was NOT HTTP/1.1 (or any other flavor of HTTP, for that matter). The first three versions of the APNs protocol were a custom "binary" protocol designed by Apple and not used anywhere else. Only the most recent version of the APNs API uses a widely-known and widely-used protocol (HTTP/2).

LazyInstantiation/jonchambers

I am able to get push using new HTTP/2 provider services

1). I installed app and get the send payload to APNS using new HTTP/2 provider

2). Got the push notifications in devices

3). Deleted the app and waited 24 hours

4). Again tried to send push for deleted app device token, but still getting 200 status code from APNS

Any guess why it's getting 200 sucess status code instead of "410 The device token is no longer active for the topic."

That is a bug with Apple's APNs service.

I deleted an app which uses the development push server and waited 24 seconds, before trying again. My APNs Provider server still had the previous device token in its cache, since it had not received a response that it was no longer active. I too received the status code of 200; not the 410.

I then reinstalled the app on the device and launched it. It correctly updated a new device token to my APNs Provider server, and sent out requests to both device tokens. I received status codes of 200 on both requests.

I did receive a remote notification correctly in the app with the new device token. The problem is my APNs Provider server is sending requests to inactive tokens which takes up system resources unnecessarily.

My experiments shown that two APIs work together without problems. This means when I send notifications to expired tokens in any mixed order with new and old API, all undeliveries are collected by the Feedback service.

I believe both API work with a sole implementation on Apple servers.

BTW I've never had the luck to receive 410 status in new API, both actual and expired tokens always respond with 200 status. I think the description in Apple documentation is very misleading and make developers think that this status is the replacement for "legacy" Feedback service while it is not.

I wish this could be true... But my experiments show that 410 status by no means is a replacement for the Feedback service. When I send notifications through HTTP/2 API to expired tokens I always get 200 status. But these unsuccessful attempts are still being collected by the Feedback service a second later. So it looks like there is no replacement for Feedback service yet, unless Apple fixes the bug (if it is a bug) or introduces an official replacement for the legacy Feedback service.

> The problem is my APNs Provider server is sending requests to inactive tokens which takes up system resources unnecessarily.

Yeah, same problem here... 😟

>>When I send notifications through HTTP/2 API to expired tokens I always get 200 status.

I have the same issue. Unable to get 410 for an app that was removed. It didn't matter if it was a 24 hours later or 48.

Legacy feedback service is not working either.

For what it's worth: while validating the behavior of our http2 based provider I saw the same behavior you did. That is, when I send a notification using the http/2-based API, I will get an error response if the request is malformed or the token is completely invalid (usually), but if the application has merely been uninstalled, the request will result in a 200/success response. However, in the case of an uninstalled app, the token will appear on the corresponding feedback service a few seconds later. It doesn't matter whether the original request was submitted by the legacy v2 (binary) interface or the new v3 (http/2) interface.

I just confirmed this behavior today on the sandbox endpoints.

So it seems that you're right, the http/2 and "legacy version 2" interfaces probably go to the same backend, and feedback-service items are generated in the same way they always have been — asynchronously. The difference is that it's a real PITA to recover from an error on the binary interface, and much easier to recover from an error on the http/2 interface. But you still need to consult the feedback service for delayed errors.