Developer.apple.com/library/arc…

An overview of the

APNs: Apple Push Notification Server Apple’s APNs allows devices to stay connected to Apple’s Push Notification server and allows developers to Push messages to applications corresponding to users’ devices.

APNS push mechanism

First, let’s take a look at apple’s official explanation of ios push. The following figure

Apple Push Ontification Service (APNs) is the core of remote notification. The service is robust, secure and efficient, allowing developers to easily push notifications to iOS tvOS macOS terminals.

When the application is running on the user device, a secure data interaction connection is established between the user device and APNS, and the application receives notifications through this connection.

The other half of the connection is the notification connection, which is the fixed connection between your server and APNS and requires a push certificate in your developer account. Essentially, the information provider is a server that you configure and deploy, requiring you to write the functionality of the server.

Responsibilities of the server

Your server has the following responsibilities when communicating with APNS:

  • Receive globally unique device verification codes and other data about your app via APNS
  • According to the needs of app functions, decide the notification push time
  • A notification request is established and sent to APNs, which then delivers the notification to the appropriate device

For each notification request, the server needs to do:

  1. Construct a JSON data that contains the notification information
  2. Add device Token and notification information to an HTTP/2 request. About Device Token About HTTP/2 parameters and receipt information
  3. A permanent Security Architecture that sends HTTP/2 requests containing certificates to APNs

For those using multiple servers

The working diagram is shown below: Figure 6-2 depicts the type of virtual network that APNS enables for the device running your application. To handle the notification load, you typically deploy multiple servers, each with its own persistent and secure connection to APNS

Quality of service, store-and-forward, and merge notifications

Apple’s push notification service includes a quality-of-service (QoS) component that performs storage and forwarding. If APNS tries to send a notification and the target device is offline, APN stores the notification for a limited time and sends the notification when the device is available again. This component stores only the latest notifications for each device and each application. If the device is offline, sending a notification request for the device causes the previous request to be discarded. If the device is offline for an extended period of time, all notifications stored in the APN are discarded.

Merger notification

To allow similar notifications to be merged, a collapse identifier can be included in the notification request. Normally, when the device is online, each notification request sent by the user to the APN results in the notification being sent to the device. However, when the apns-collapsor-id key appears in your HTTP/2 request header, APNs will merge requests with the same key value. For example, a news service that sends the same headline twice can use the same collapsed identifier value for both requests. Apn then merges the two requests into one notification and sends it to the device. For details about the APns-collapsor-id keys, see Table 8-2.

Security architecture

APNs uses a two-layer trust mechanism: Connection trust and Device Token trust APNs uses two trust levels to enforce end-to-end encryption authentication and authentication: connection trust and device token trust.

Connect the trustWork between the server and the APNs | between APNs and equipment

The trust between the server and APNs ensures that the connection between the server and APNs is secure. You need to follow the steps to secure the connection between the server and APNs according to the information in this section

Trust between APNs and devices ensures that only authenticated devices can connect to APNs. APNs automatically ensures that the connection between APNs and devices is secure and correct.

When communicating with APNs, the server must implement authentication certificate (token-based authentication) or SSL certificate (certificate-based authentication). You need to implement either of these two authentication methods in developer account, help is here. See the server/APNS connection trust here to determine which authentication mode you want to choose.

A Device token is an opaque NSData that contains the unique identity of an application on a device. Only APNs can decrypt and view the contents of the Device Token. Each app receives its own unique Device token when it sends a remote push registration request to APNs and must then forward the Device Token to your app’s server (see configuring Push support for details). The server must contain the corresponding device token when sending notifications to corresponding devices. APNs uses a Device token to ensure that the notification is sent to the corresponding APP of the corresponding device.

APNs issues new Device Tokens for the following reasons:

  • The user installs your app on the new device
  • You can restore devices through backup
  • After the user reinstalls the system
  • Other system-level events

Therefore, the app must request a Device token when it is launched. See connection trust and Device Token between APNs and devices. See Push Registration Request for code examples

Note: To protect user privacy, do not use device tokens to identify users

Trust between the server and APNs

There are two ways to implement connection trust between a server and APNs

JSON Web Tokens (JWT) can be used to connect tokens with APNs based on HTTP/2 apis. In this mode, you need to provide a public key to Apple. The server needs this key to generate and add to the JWT server to validate the token. Every push request made by the server must contain this token.

You can then implement push requests for all apps in your developer account using a simple token-based connection.

For every push request the server makes to APNs, it receives HTTP/2 feedback from APNs.

The trust server between a certificate-based server and APNs can also implement connection trust through a unique certificate. The server certificate can be obtained from the developer account as a push certificate, based on your app’s unique certificate. The certificate can then be used to implement push requests.

Important To implement HTTP/2 based SSL connections with APNs, your server must include the GeoTrust Gloabl CA as the root certificate. If your server is running macOS, the root certificate is in the keychain. Servers for other systems are installed on a personal basis. You can download it from GeoTrust Root Certificates,

Trust between a token-based server and APNs

Apple Push Notification Authentication Key (Sandbox & Production) you need to configure it in your developer account

This certificate has the following features:

  • A certificate can be used to send a push to all apps included in the account. Can also be used for Voice over Internet Protocol(VoIP). APNs sends this certificate to your app even when it’s running in the background. For details, see APNs Server Certificate, Power Consumption in Development For the best Voice Over IP(VoIP) applications

  • This certificate must be included in a JWt-based connection when a push request is sent

  • The certificate will never expire, but you can always re-acquire it through your developer account, and the old certificate will no longer be used

The following figure shows: establish a trusted connection between the server and APNs using HTTP/2, and send push request to APNs using JWT

As shown, the workflow looks like this:

  1. The server requests a secure connection request based on TLS from APNs
  2. APNs sends an authentication certificate to the server. After the connection between the server and APNs is established, APNs can send push requests
  3. Every push request that the server needs to send must contain a JWT authentication token
  4. APNs sends HTTP/2 acknowledgement to the server. See HTTP/2

Trust between a certificate-based server and APNs

Certificate-based server connections only support a specific application. Certificates need to be generated on your server in advance based on your application bundle, see generating a unique SSL connection certificate to APNs. Depending on the certificate you generate, a trusted connection can also push things related to your app, such as Apple Watch concurrency and Voice-over-Internet Protocol (VoIP). APNs will push these even if the device is only running in the background. Consult communication with APNs for more knowledge, power in Development guidance for instructions on the best use of Voice Over IP(VoIP).

In certificate-based trusted connections, APNs holds a list of revoked certificates, and if the server’s certificate is in the list, APNs revokes the trusted connection with the server (that is, APNs rejects the server’s request).

The process of this connection is as follows:

  1. The server sends a TLS connection request to APNs
  2. APNs sends the certificate to the server
  3. The server needs to send APNs the certificate you previously generated from [developer account], see generating a unique SSL connection certificate to APNs
  4. APNs verifies that the certificate provided by the server is correct and, if so, determines the trusted connection between the server and APNs. The server can now send a push request to APNs.

Connectivity between APNs and devices with Device Tokens

The connection between APNs and each device is automatically established, and there is no need for your app to do anything in the process.

Each device has an encrypted certificate and private key, which are generated when the device is activated and stored in the keychain of the device. When the device is activated, APNs authenticates and authorizes the connection with the device based on the certificate and key of the device.

Here’s how it works:

  1. The device sends a TLS connection request to APNs and the trusted connection setup begins
  2. APNs Receives the APNs certificate to the device
  3. The device operating system authenticates the received APNs certificate and sends its own device certificate to the APNs
  4. APNs verifies the certificate sent by the device. If correct, the trust connection is established

After the trusted connection between the device and APNs is established, the device can apply to APNs for the device-Token of a specific app. For details, see Section configuring Remote Push Support for Registering and Receiving Remote Push.

After receiving the Device Token, the app must send the received device token to its server. See Configuring Remote Push Support for the code, as the device Token is required when the server sends push requests to APNs later

The process of device activation and application for device Token is the same as that of APNs generating a new device token, as shown in the figure below:

Process:

  1. The APP applies for a remote push request from APNs. If the device has registered the remote push request and the device Token of the specific app remains unchanged, APNs returns the existing device Token to the device and goes to Step 4
  2. When a new device needs to register a push request, APNs generates a device token based on the received device certificate and sends it back to the device
  3. The device system passes the received device token to the app and calls the AppDelegate methodapplication:didRegisterForRemoteNotificationWithDeviceToken:
  4. After receiving a Device token, the device needs to send it to your server in binary or hexadecimal format so that the server can use the device Token to send push requests

Important The length of the device token provided by APNs varies. Do not forcibly decode the size of the token

When the server sends a push request to the APNs, the request contains a device token that identifies the unique device and app. This process is the token and Payload process shown in the following figure. APNs decrypts the Device Token to ensure the target of the push request. APNs sends push information about the request to the device if both the sender and receiver of the request are valid.

After the device receives the push from APNs, the operating system delivers the notification to the corresponding APP.

Reference: iOS Remote push -APNs details