APNS : qu’est-ce que c’est, comment fonctionne Apple Push Notification Service et son architecture

Qu’est-ce qu’APNS ?

Apple Push Notification Service (APNS) est le service propriétaire d’Apple pour acheminer les notifications push du serveur d’application vers les appareils des utilisateurs. Contrairement à FCM, APNS ne prend pas en charge Android ni d’autres plates-formes — il est entièrement lié à l’écosystème Apple.

Le service fonctionne via une connexion TLS persistante que chaque appareil Apple établit avec les serveurs APNS au démarrage. Cette connexion est maintenue en arrière-plan et utilisée pour livrer les notifications avec une latence minimale.

APNS gère toute l’infrastructure de livraison : chiffrement, authentification, priorisation et retransmission lorsque l’appareil est indisponible. Le développeur doit seulement fournir une charge utile correctement formatée et un jeton push valide.

Évolution d’APNS

À l’origine, APNS fonctionnait via un protocole binaire sur les ports 2195–2196. Depuis 2015, Apple a migré le service vers le protocole moderne HTTP/2, qui prend en charge le multiplexage, la compression d’en-tête et les notifications push serveur. HTTP/2 est devenu obligatoire en juin 2020.

Comment fonctionne Apple Push Notification Service ?

Le processus de livraison des notifications push via APNS comprend cinq étapes : enregistrement de l’appareil, obtention du jeton push, envoi de la requête par le serveur, routage APNS et livraison à l’appareil.

• Enregistrement — au lancement, l’appel appelle registerForRemoteNotifications, le système contacte APNS
• Jeton — APNS retourne un jeton push à l’appareil — une chaîne unique identifiant l’app sur l’appareil
• Envoi — le serveur d’application envoie une requête POST à https://api.push.apple.com avec le jeton et la charge utile
• Routage — APNS trouve l’appareil par le jeton et livre le message via la connexion TLS
• Traitement — iOS/macOS affiche la notification ou la transmet à l’app selon l’état

Si l’appareil est indisponible (éteint ou sans réseau), APNS stocke le dernier message pour chaque application et le livre lors du rétablissement de la connexion. La durée maximale de stockage est de 4 semaines, après quoi le message est supprimé.

Authentification APNS : Token et Certificat

Apple prend en charge deux méthodes pour authentifier le serveur d’application lors de l’envoi de notifications push. Chaque méthode a ses propres caractéristiques en termes de période de validité, de gestion et de facilité d’utilisation.

L’authentification basée sur Token est la méthode recommandée par Apple depuis 2019. Vous créez une seule clé p8 dans Apple Developer Console, vous la téléchargez sur votre serveur et signez chaque requête APNS avec elle. La clé n’expire jamais et fonctionne pour toutes les applications de votre compte.

Quelle méthode d’authentification choisir

Pour les nouveaux projets, l’authentification basée sur Token est clairement préférable : une clé p8 pour tout le compte, illimitée, sans lien avec l’environnement. La méthode basée sur Certificat (.p12) est encore utilisée dans les projets existants mais nécessite un remplacement annuel et des certificats séparés pour Sandbox et Production. Tenez compte de l’expiration du certificat lors de la planification CI/CD.

Types de notifications push APNS

APNS prend en charge trois types de notifications push, qui diffèrent par leur comportement sur l’appareil et les exigences d’attributs de requête. Le choix du type dépend du scénario UX et de l’urgence du message.

• Alert — notification standard avec titre, texte et boutons d’action optionnels
• Background — livraison silencieuse de données (push silencieux) sans affichage à l’utilisateur, traitée dans application:didReceiveRemoteNotification
• VOIP — type spécial pour les applications VoIP (PushKit), livré immédiatement même lorsque l’application est fermée

Pour les notifications Background, vous devez spécifier la clé content-available : 1 et définir la priorité sur 5 (livraison économe en énergie). Le système peut limiter le nombre de notifications en arrière-plan si l’application ne les traite pas en temps utile.

Configuration de la priorité de livraison

APNS prend en charge deux valeurs de priorité : 10 (livraison immédiate) et 5 (économe en énergie). Pour les notifications alert, utilisez 10 — l’utilisateur doit les recevoir immédiatement. Pour les notifications background, utilisez 5 — le système peut retarder la livraison pour économiser la batterie. Une priorité incorrecte pour background peut entraîner le rejet d’APNS.

Format de la charge utile APNS

APNS accepte une charge utile au format JSON avec une taille maximale de 4 Ko pour les notifications standard et 5 Ko pour VOIP. La charge utile contient le dictionnaire aps obligatoire avec les paramètres d’affichage et des champs personnalisés optionnels.

{
    "aps": {
        "alert": {
            "title": "Nouveau message",
            "body": "Vous avez 3 discussions non lues"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

La clé thread-id regroupe les notifications dans le Centre de notifications iOS. La clé category lie la notification à une UNNotificationCategory pour afficher les boutons d’action. Sans ces clés, toutes les notifications s’affichent individuellement.

Champs personnalisés dans la charge utile APNS

En plus du dictionnaire aps obligatoire, la charge utile APNS peut contenir des champs personnalisés au niveau supérieur. Ces champs sont accessibles à l’application via le dictionnaire userInfo lors du traitement de la notification. Les données personnalisées sont pratiques pour transmettre des identifiants d’entités, des écrans ou des liens. La taille maximale de la charge utile est de 4 Ko, évitez donc de transférer de grandes quantités de données via push ; chargez-les via API après l’ouverture de la notification.

Exemple d’envoi via l’API HTTP/2

Pour envoyer une notification push depuis le serveur, vous devez exécuter une requête POST vers le point de terminaison APNS avec les en-têtes d’authentification corrects. Voici un exemple en Node.js utilisant l’authentification basée sur Token.

const http2 = require("http2")
const fs = require("fs")
const jwt = require("jsonwebtoken")

const token = jwt.sign(
    { iss: "TEAM_ID", iat: Math.floor(Date.now() / 1000) },
    fs.readFileSync("AuthKey.p8"),
    { algorithm: "ES256", keyid: "KEY_ID" }
)

const payload = JSON.stringify({
    aps: { alert: { title: "Bonjour !", body: "Push de test" } }
})

const client = http2.connect(
    "https://api.push.apple.com"
)

const req = client.request({
    ":method": "POST",
    ":path": "/3/device/DEVICE_PUSH_TOKEN",
    "authorization": "bearer " + token,
    "apns-push-type": "alert",
    "apns-topic": "com.example.app",
    "apns-priority": "10"
})
req.end(payload)

req.on("response", (headers) => {
    if (headers[":status"] === 200) {
        console.log("Push envoyé avec succès")
    }
})

Après l’envoi, APNS retourne le statut HTTP 200 en cas de livraison réussie ou un code d’erreur avec description dans le corps de la réponse. Il est important de traiter les erreurs token-unregistered (410) — ces jetons doivent être supprimés du serveur, car l’application a été supprimée de l’appareil.

Erreurs APNS et leur traitement

APNS retourne des codes de statut HTTP pour chaque requête d’envoi. La livraison réussie retourne le statut 200. Les erreurs nécessitent différentes stratégies de traitement. BadDeviceToken (400) ou Unregistered (410) — le jeton de l’appareil est obsolète et doit être supprimé du serveur. PayloadTooLarge (413) — la limite de 4 Ko a été dépassée, réduisez la charge utile.

TooManyRequests (429) — limite de requêtes dépassée. APNS fixe un quota sur le nombre d’envois par seconde. Lors de la réception de 429, implémentez un backoff exponentiel (exponential backoff) et réessayez. Il est recommandé de ne pas dépasser 100 requêtes par seconde par connexion HTTP/2.

Erreurs côté APNS — 500 et 503 (Erreur Interne du Serveur / Service Indisponible). Ce sont des pannes temporaires de l’infrastructure Apple. Dans ces cas, réessayez avec un délai de 1 à 5 secondes, pas plus de 3 tentatives. Les erreurs 5xx persistantes avec un serveur complètement opérationnel sont rares et généralement liées à des problèmes de connexion TLS.

Pour les environnements de Production, assurez-vous d’implémenter la journalisation de toutes les erreurs APNS avec le jeton, le code d’erreur et l’heure. Cela aidera à identifier rapidement les problèmes de certificats, de quotas ou de jetons d’appareils spécifiques. Vérifiez régulièrement les dates d’expiration des certificats si vous utilisez l’authentification basée sur Certificat.