Comparaison APNs vs FCM pour iOS et Android : cycle de vie des jetons, limites de payload, attentes de livraison, et checklist pratique pour réparer les notifications manquantes.
APNs (Apple Push Notification service) et FCM (Firebase Cloud Messaging) sont les tuyaux qui transmettent un message depuis votre serveur jusqu'au téléphone. Ils ne décident pas de ce que votre app fait du message, mais ils influencent fortement s'il arrive, à quelle vitesse il arrive, et sous quelle forme il doit être.
Quand on dit qu'une notification push « fonctionne sur Android mais pas sur iOS » (ou l'inverse), il s'agit rarement d'un seul bug. iOS et Android gèrent différemment le travail en arrière-plan, l'économie d'énergie, les permissions et la priorité des messages. Le même message peut être retardé, remplacé par un plus récent, affiché sans son ou jamais montré si l'app ne peut pas se réveiller pour le traiter.
Cette comparaison se concentre sur les parties qui provoquent le plus de surprises en conditions réelles : comment les jetons d'appareil changent dans le temps, combien vous pouvez mettre dans un payload et comment le structurer, quelle livraison vous pouvez réellement attendre, et les raisons courantes pour lesquelles les notifications semblent disparaître.
Ce guide ne traite pas du choix d'une interface fournisseur de push, de stratégie marketing ou de la construction d'un pipeline d'analytics complet. L'objectif ici est la fiabilité et un débogage plus rapide.
Quelques termes utilisés tout au long du texte :
Bien maîtriser ces bases vous évitera des heures de suppositions quand une « simple push » se comporte différemment entre iOS et Android.
APNs et FCM sont tous deux des intermédiaires entre votre serveur et le téléphone d'un utilisateur. Votre app ne peut pas livrer de manière fiable une notification directement à un appareil via Internet, elle confie donc ce travail à Apple (APNs) ou Google (FCM), qui maintiennent déjà des connexions de confiance avec leurs appareils.
Le flux global est similaire : votre app obtient un jeton, votre backend envoie un message au service de push en utilisant ce jeton, et le service de push le route vers l'appareil.
Sur iOS, l'app s'enregistre pour les notifications distantes et (généralement) demande la permission à l'utilisateur. Apple fournit alors un jeton d'appareil. Votre backend (souvent appelé « provider ») envoie une requête de push à APNs qui inclut ce jeton et votre payload. APNs décide s'il peut livrer et transmet la notification à l'appareil.
Votre backend s'authentifie auprès d'APNs, typiquement via une authentification par jeton (clé de signature). Les anciennes configurations utilisent des certificats.
Sur Android, l'instance de l'app s'enregistre auprès de FCM et reçoit un jeton d'enregistrement. Votre backend envoie un message à FCM, et FCM le route vers l'appareil concerné. Selon l'état de l'app et le type de message, FCM peut afficher automatiquement une notification ou livrer des données à l'app pour traitement.
Votre backend s'authentifie auprès de FCM en utilisant des identifiants serveur (clé API ou compte de service).
Ce que vous contrôlez : le code de l'app, quand vous demandez la permission, le stockage du jeton, la logique backend et le payload que vous envoyez. Ce que contrôlent Apple et Google : le réseau de livraison, la reachabilité, les règles de throttling et de nombreuses conditions de dernière ligne comme les politiques d'économie d'énergie.
La plus grande différence au quotidien entre APNs et FCM est que les jetons ne sont pas « définis une fois pour toutes ». Traitez-les comme des adresses qui peuvent changer sans prévenir.
Sur iOS, le jeton APNs est lié à l'appareil, à votre application et à votre configuration développeur Apple. Il peut changer après une réinstallation de l'app, une restauration de l'appareil, certaines mises à jour d'OS, ou quand on change d'environnement push (sandbox vs production) pendant le développement.
Sur Android, le jeton d'enregistrement FCM peut se rafraîchir lorsque l'app est restaurée sur un nouvel appareil, que l'utilisateur efface les données de l'app, que Google fait une rotation des jetons, ou que l'app est réinstallée. Votre app doit gérer les événements de rafraîchissement et envoyer rapidement le nouveau jeton à votre serveur.
Une règle simple : faites toujours des upserts de jetons, ne faites jamais un « insert and forget ». Quand vous stockez des jetons, conservez assez de contexte pour éviter les doublons et les mauvaises cibles :
Les suppressions sont importantes aussi. Vous apprenez généralement qu'un jeton est mort à partir d'erreurs de livraison, pas via un signal propre d'« uninstall ». Si APNs renvoie une erreur comme Unregistered (souvent avec un statut 410), ou si FCM indique NotRegistered/Unregistered, supprimez ce jeton immédiatement pour arrêter les tentatives infinies.
Une fuite courante : un client se déconnecte et un autre se connecte sur le même téléphone. Si vous ne nettoyez pas ou ne remappez pas le jeton au logout, vous pouvez envoyer des notifications à la mauvaise personne même si la livraison « fonctionne ».
La différence pratique la plus importante entre APNs et FCM est ce que vous pouvez caser dans un message et comment le téléphone le traite à l'arrivée.
La plupart des équipes s'appuient sur un petit ensemble de champs :
order_id, status)Les deux services ont des limites de taille de payload, et la limite inclut vos données personnalisées. Quand vous atteignez la limite, la livraison peut échouer ou le message peut ne pas se comporter comme prévu.
Un schéma fiable est d'envoyer une notification courte plus un ID, puis de récupérer les détails depuis votre backend :
Exemple : au lieu d'envoyer un résumé complet de commande, envoyez { "type": "order_update", "order_id": "123" } et laissez l'app appeler votre API pour charger le statut le plus récent.
Sur Android, un message FCM avec un payload « notification » est généralement affiché par le système quand l'app est en arrière-plan. Un message data-only est remis au code de l'app, mais il peut être retardé ou bloqué par les limites d'arrière-plan et les réglages de batterie.
Sur iOS, les alertes (titre/corps) sont simples, mais les mises à jour en arrière-plan sont plus strictes. Un push en arrière-plan n'est pas une garantie que votre code s'exécutera immédiatement. Traitez-le comme un indice pour actualiser, pas comme un déclencheur temps réel.
Si vous avez besoin de fiabilité, gardez le payload minimal, incluez un identifiant stable, et concevez votre app pour réconcilier l'état à l'ouverture ou à la reprise.
Avec APNs et FCM, la livraison est en best-effort. Le fournisseur essaiera de livrer votre message, mais ne garantit pas que l'appareil l'affichera.
La reachabilité est le premier facteur limitant. Vous envoyez une notification avec un TTL ou une date d'expiration. Si l'appareil revient en ligne après cette fenêtre, le push est supprimé. Si le TTL est très long, l'utilisateur peut voir une ancienne alerte plus tard, ce qui ressemble à un bug.
La priorité affecte le timing, mais ce n'est pas un upgrade gratuit. La haute priorité peut aider les messages sensibles au temps à arriver plus vite, surtout quand l'appareil est en sommeil. L'abus de haute priorité peut mener à du throttling, à une consommation de batterie excessive, ou à ce que l'OS considère votre app comme bruyante.
Les deux systèmes supportent le collapse pour qu'un message plus récent remplace un plus ancien plutôt que de les empiler. APNs utilise un identifiant de collapse, et FCM utilise une collapse key. Si vous regroupez sur quelque chose comme order_status, l'utilisateur ne verra peut-être que le dernier statut, pas chaque étape.
Même quand le fournisseur livre avec succès, le téléphone peut empêcher l'utilisateur de voir la notification :
Considérez le push comme un transport peu fiable : conservez l'état important dans votre backend et faites en sorte que l'app rafraîchisse l'état quand elle s'ouvre, même si une notification ne s'affiche jamais.
Beaucoup de « problèmes de livraison » sont en réalité des problèmes de permissions et de réglages.
Sur iOS, la première demande de permission est cruciale. Si l'utilisateur tape « Ne pas autoriser », les notifications n'apparaîtront pas tant qu'il n'aura pas changé cela dans Réglages. Même après accord, il peut désactiver l'écran de verrouillage, le centre de notifications, les bannières, les sons ou les badges. Les modes Focus et le Résumé programmé peuvent aussi masquer ou retarder les alertes.
Sur Android, les exigences dépendent de la version d'OS. Les versions récentes demandent une permission runtime pour les notifications, donc une mise à jour d'app peut soudainement arrêter l'affichage des notifications tant que l'utilisateur n'a pas approuvé. La visibilité dépend aussi des canaux de notification : si le canal est muet ou d'importance faible, les pushes peuvent arriver sans interrompre l'utilisateur.
Les restrictions d'arrière-plan peuvent aussi briser les attentes. Le mode faible consommation sur iOS et les optimisations de batterie sur Android peuvent retarder le travail en arrière-plan, couper les données ou empêcher l'app de traiter un message data-only.
Pour confirmer ce qui se passe, journalisez ce que l'appareil voit, pas seulement ce que votre backend a envoyé :
Même si votre backend est construit dans un outil no-code, la journalisation côté client reste ce qui sépare « message non reçu » de « reçu mais supprimé ».
Quand un push manque, considérez la chaîne : jeton, fournisseur, payload et comportement de l'app. Les symptômes peuvent être identiques sur iOS et Android, alors vérifiez les mêmes points dans l'ordre.
Puis déterminez si le problème vient du contenu du message ou du comportement de l'app/appareil :
Un schéma pratique : si les utilisateurs iOS signalent des absences mais qu'Android est OK, commencez par envoyer une alerte minimale sur iOS. Si cela marche, concentrez-vous sur la structure du payload et la gestion côté app. Sinon, vérifiez les jetons et les identifiants/environnements APNs.
La plupart des problèmes push ne sont pas des pannes. Ce sont de petits décalages entre ce que votre app attend et ce que APNs ou FCM accepte, ou entre ce que le téléphone permet.
L'erreur la plus fréquente est d'envoyer à un jeton qui n'est plus valide. Les jetons changent après réinstallation, restauration ou refresh. Si votre serveur continue d'utiliser l'ancienne valeur, les pushes n'aboutissent nulle part.
Autre erreur : traiter la livraison push comme garantie. La livraison best-effort signifie que les messages tardifs ou manquants sont normaux quand les appareils sont hors ligne ou soumis à des règles d'économie d'énergie. Pour des événements importants (mises à jour de commande, alertes de sécurité), prévoyez un repli dans l'app comme récupérer le statut le plus récent à l'ouverture.
Causes courantes de notifications manquantes :
Exemple : une app retail envoie une alerte « commande expédiée » avec un gros blob JSON de l'historique de suivi. L'appel d'envoi semble OK, mais le payload est rejeté ou tronqué, et l'utilisateur ne voit rien. Gardez le push léger et mettez les détails derrière une API.
Avant d'assumer que le fournisseur est en faute, faites un contrôle de cohérence :
Ensuite, faites une vérification rapide sur l'appareil : notifications autorisées pour l'app, bon canal/catégorie configuré (les canaux Android sont un piège fréquent), Focus/Ne pas déranger, et restrictions d'arrière-plan.
Un agent support clique sur « Envoyer mise à jour de commande » pour la commande #1842. Les logs backend montrent « notification envoyée », mais le client ne voit rien sur son iPhone ou son Android.
Commencez côté backend. La plupart des notifications « manquantes » ne sont soit pas acceptées par le service push, soit acceptées puis abandonnées plus tard parce que l'appareil ne peut pas (ou ne veut pas) l'afficher.
Recherchez une tentative d'envoi traçable (une mise à jour de commande devrait produire une requête push). Puis vérifiez :
Si les logs montrent un rejet comme « unregistered/invalid token », c'est un problème de cycle de vie du jeton. Si le fournisseur accepte le message mais rien n'arrive, concentrez-vous sur le type de payload et le comportement de l'OS.
Validez maintenant que le téléphone peut afficher l'alerte :
Un résultat fréquent : le jeton est correct, mais le message est data-only (Android) ou il manque la bonne configuration iOS pour le traitement en arrière-plan, si bien que l'OS n'affiche jamais d'alerte. La solution est d'envoyer le bon type de payload pour l'effet désiré (alerte visible vs mise à jour silencieuse) et de conserver des logs propres des mises à jour de jetons et des réponses des fournisseurs.
Les notifications push paraissent simples jusqu'à ce qu'elles deviennent une fonctionnalité centrale. La fiabilité vient des éléments que vous contrôlez : l'hygiène des jetons, la discipline du payload, et un chemin de secours.
Préparez-vous aux ratés. Le push est excellent pour attirer l'attention « maintenant », mais il ne doit pas être la seule voie pour des événements critiques. Une boîte de réception dans l'app permet aux utilisateurs de rattraper leur retard, et l'email ou le SMS peuvent couvrir les actions à forte valeur comme la réinitialisation de mot de passe ou les problèmes de paiement.
Gardez le payload léger. Traitez le payload push comme un indice, pas comme le message complet. Envoyez un type d'événement et un ID, puis récupérez les détails depuis votre API quand l'app s'ouvre ou quand elle reçoit une mise à jour d'arrière-plan appropriée.
Rédigez un court runbook pour votre équipe afin que le débogage reste cohérent : état d'opt-in, fraîcheur des jetons, codes de réponse des fournisseurs, taille/forme du payload et environnement/identifiants.
Si vous construisez avec AppMaster (appmaster.io), il peut être pratique de garder le stockage des jetons, les logs d'audit et la logique métier déclenchant les pushes dans un même backend, tout en publiant des apps natives iOS et Android qui gèrent correctement APNs et FCM.
Quelle est la façon la plus simple d'expliquer APNs vs FCM ?APNs est le service d'Apple pour délivrer les notifications push iOS, et FCM est le service de Google pour Android (et peut aussi cibler iOS via APNs). Votre app décide toujours quoi faire du message, mais ces services déterminent comment s'authentifier, comment formater les payloads et quel comportement de livraison attendre.
Les jetons des appareils restent-ils identiques pour toujours ?Considérez les jetons comme des adresses qui peuvent changer. Stockez-les avec les détails de plateforme et d'environnement, mettez-les à jour dès que l'app rapporte une nouvelle valeur, et supprimez-les quand le fournisseur indique qu'ils sont invalides. La règle pratique est d'« upserter » les jetons et de garder un horodatage « last seen » pour repérer rapidement les enregistrements obsolètes.
Qu'est-ce qui fait généralement changer un jeton push iOS ou Android ?Sur iOS, les jetons changent souvent après une réinstallation, une restauration de l'appareil, certaines mises à jour d'OS, ou si vous passez entre sandbox et production en développement. Sur Android, les jetons FCM peuvent se rafraîchir après réinstallation, lorsque l'utilisateur efface les données de l'app, quand l'appareil est restauré, ou lors d'une rotation des jetons par Google. L'app doit écouter les événements de refresh et envoyer immédiatement le nouveau jeton au backend.
Comment dois-je structurer un payload push pour éviter des problèmes ?Gardez le payload léger et considérez-le comme un déclencheur. Envoyez un court titre/texte (si vous voulez une alerte visible) plus un identifiant stable comme order_id, puis laissez l'app récupérer les détails complets via votre API. Cela évite les limites de payload, réduit les cas limites et uniformise le comportement entre plateformes.
Quelle est la différence entre les messages « notification » et « data-only » ?Un payload de type « notification » est destiné à être affiché à l'utilisateur, tandis qu'un payload « data-only » est destiné à être traité par l'app. Sur Android, les messages data-only peuvent être retardés ou bloqués par les limites d'arrière-plan et les optimisations de batterie, ils ne sont donc pas fiables pour un traitement instantané. Sur iOS, les pushes en arrière-plan ne garantissent pas non plus l'exécution immédiate de votre code : traitez-les comme un indice pour actualiser l'état plutôt que comme un exécuteur de tâches en temps réel.
Les notifications push sont-elles garanties d'être délivrées et affichées ?Non : la livraison est en « best-effort ». Même si APNs ou FCM accepte votre requête, l'appareil peut être hors ligne, le message peut expirer (TTL), le système peut throttler la livraison, ou les réglages utilisateur peuvent masquer l'alerte. Concevez votre app pour que l'état critique soit toujours correct lorsque l'utilisateur l'ouvre, même si la notification n'apparaît pas.
Quelle est la façon la plus rapide de déboguer une notification manquante ?Commencez par séparer « envoyé » et « affiché ». Confirmez que le jeton est à jour, envoyez un payload test minimal titre/texte, et vérifiez que vous utilisez les bonnes informations d'identification APNs/FCM et (pour iOS) le bon environnement. Si le fournisseur accepte le message, regardez les paramètres du téléphone (Focus/Ne pas déranger, permissions de l'app, canaux Android), car la notification peut être reçue mais supprimée avant d'être affichée.
Pourquoi les notifications fonctionnent sur Android mais pas sur iOS (ou l'inverse) ?Sur iOS, les problèmes viennent souvent d'un refus de permission, des modes Focus, ou du ciblage du mauvais environnement APNs (sandbox vs production). Sur Android, les obstacles courants sont la permission runtime des notifications sur les versions récentes, des canaux de notification réduits/muets, et des optimisations de batterie agressives qui retardent le traitement en arrière-plan. Le même envoi serveur peut sembler correct alors que l'appareil empêche silencieusement l'affichage.
Comment le TTL et la « collapse key » affectent-ils ce que voit l'utilisateur ?Le TTL contrôle combien de temps le fournisseur doit continuer d'essayer quand l'appareil est hors ligne, et les paramètres de collapse décident si un message plus récent remplace un message plus ancien en attente. Un TTL court peut faire disparaître une notification si le téléphone reste hors ligne, et les clés de collapse peuvent empêcher l'utilisateur de voir chaque étape en ne gardant que la dernière mise à jour. Choisissez ces valeurs en fonction de l'expérience utilisateur voulue.
Comment AppMaster peut-il m'aider à construire une configuration push fiable ?Conservez le stockage des jetons, les règles de ciblage et les journaux d'envoi ensemble pour tracer chaque tentative de push de bout en bout. AppMaster (appmaster.io) peut aider en centralisant les tables de jetons, l'audit logging et la logique métier déclenchant les envois dans un même backend, tandis que vos apps natives iOS et Android gèrent correctement APNs et FCM. L'important est de journaliser les mises à jour de jetons, les réponses des fournisseurs et la réception côté client pour déterminer si l'échec vient du serveur, du fournisseur ou du périphérique.
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
