Guide de mise en œuvre de notifications push Expo 2026

Vous êtes probablement à un point où l'application fonctionne, les utilisateurs ont signé, et le produit souhaite maintenant des flux de re-engagement qui ressemblent à des applications natives. Les rappels de panier. Les invitations de révision. Les alertes de nouveaux messages. Les annonces de mise à jour. Le premier réflexe est souvent de « simplement brancher les notifications push », puis une semaine plus tard, vous êtes en train de déboguer pourquoi un appareil reçoit des alertes, le simulateur semble s'enregistrer correctement, et personne ne peut expliquer pourquoi les appuis ne lancent pas l'écran correct.

C'est là que les notifications push Expo sont soit agréablement simples, soit surprenamment fragiles.

Expo donne aux équipes React Native un niveau pratique sur APNs et FCM, ce qui est exactement pourquoi tant d'équipes l'utilisent. Mais la différence entre une démo et une mise en œuvre prête à la production est réelle. Le cycle de vie des jetons, le timing des permissions, la configuration des écouteurs, la conception des payloads et la suppression des éléments de serveur comptent tous. Si vous envoyez également des modifications fréquentes de logique d'application, le besoin de discipline opérationnelle devient encore plus aigu, surtout si votre travail de rétention dépend de la messagerie fiable et de la vitesse de mise à jour. C'est la même préoccupation plus large derrière rétention des utilisateurs d'applications mobilesLa livraison n'est utile que si l'expérience utilisateur qui l'entoure est prévisible.

Table des matières

• La base pour captiver les utilisateurs avec les notifications Push d'Expo
  • Ce que Expo abstrait réellement
  • Ce que la production prête vraiment signifie
• Configuration initiale du projet et de la configuration
  • Installez les packages de notification
  • Ajoutez une configuration au niveau du projet
  • Définissez un gestionnaire de notification tôt
  • Android nécessite une configuration de canal
• Demandez la permission et capturez les jetons Push
  • La fonction client qui devrait être votre ligne de base
  • Pourquoi Device.isDevice n'est pas facultatif
  • Demander la permission au bon moment
• Envoyer des notifications à partir de votre serveur
  • Ce que chaque champ de la charge utile devrait faire
  • Tenir les charges utiles petites et banales
  • Habitudes de serveur utiles
• Gérer les notifications entrantes dans votre application
  • La réception en avant-plan et la réponse de l'utilisateur sont des événements différents
  • Lire le payload de données et naviguer intentionnellement
  • Le comportement en avant-plan devrait correspondre au contexte de l'utilisateur
• Meilleures pratiques et pièges courants en production
  • Les jetons sont éphémères, pas des enregistrements d'identité
  • La stratégie de rafraîchissement compte plus que ce que la plupart des tutoriels avouent
  • La sécurité et la conformité ne doivent pas se trouver à la fin du sprint
  • Ce qui fonctionne généralement et ce qui se brise généralement

La Fondation pour engager les utilisateurs avec les notifications de push d'Expo

Un Notification de push d'Expo La mise en place est séduisante pour une raison qui l'emporte sur toutes les autres. Elle supprime une grande partie de la complexité de la messagerie native que les équipes ne veulent pas gérer dès le premier jour. Au lieu de construire des canaux APNs et FCM directs en premier, vous pouvez travailler avec la passerelle d'Expo et vous concentrer sur le comportement du produit, la routage, l'UX des permissions et la logique des messages backend.

Cette abstraction ne rend pas les notifications de push « moins réelles ». Elle change simplement où va votre effort d'ingénierie.

Le service est également suffisamment rapide pour que les performances ne soient généralement pas la première chose à craindre. De mars 14, 2023 à juin 12, 2023, les notifications de push d'Expo API ont montré un Temps de réponse médian de 42 millisecondes, 273 millisecondes de latence p99et des une moyenne quotidiennement de 0,17% à travers des dizaines de millions de messages quotidiensselon l'analyse de benchmark de Knock sur l'envoi de messages APICela devrait rassurer tout équipe se demandant si Expo est seulement approprié pour des prototypes.

Ce que fait en réalité Expo

Lorsque les équipes disent « Expo push », elles parlent souvent de plusieurs préoccupations séparées regroupées ensemble :

• La mise en œuvre de la navigation : Expo envoie les messages vers APNs pour iOS et FCM pour Android.
• Format de jeton : Votre serveur stocke et envoie un jeton de push Expo au lieu de gérer la gestion de jetons spécifiques aux plateformes en premier lieu.
• Contrat de demande : Vous envoyez un payload vers Expo’s push API au lieu d'intégrer directement les API de fournisseur natives.

Cela est utile, mais cela crée également une confusion courante. Les équipes supposent parfois que Expo est responsable de tous les problèmes de livraison. En pratique, de nombreux échecs proviennent de l'application code, de jetons obsolètes, de payloads malformés ou d'une mauvaise gestion des autorisations.

Règle pratique : Traitez Expo comme un couche de transport fiable, et non comme un substitut d'une conception client et serveur solide.

Ce que signifie vraiment la maturité en production

Un démo fonctionnel prouve seulement que l'un des appareils a accepté un payload une seule fois. La maturité en production signifie autre chose :

C'est la différence entre « notifications envoyées » et « notifications supportent un flux de workflow de produit réel. »

Configuration et paramétrage du projet initial

Un grand nombre de douleurs de mise en œuvre de push Expo commencent avant la première invitation de permission. Si votre configuration de projet est négligée, le client code peut sembler correct tandis que l'application se comporte de manière incohérente entre les builds.

Démarrer avec les bibliothèques installées correctement et un environnement de développement qui correspond à votre chemin de build. Si vous travaillez au-delà d'Expo Go, il est utile de synchroniser votre flux de travail local avec un paramétrage de client de développement Expo personnalisé, car le comportement des notifications doit souvent être validé dans une mise en production plus proche que d'une rapide exécution de sandbox.

Installez les packages de notification

Au minimum, vous aurez généralement besoin de :

• expo-notifications pour les demandes d'autorisation, la récupération de jetons, les écouteurs et la présentation des notifications.
• expo-device car vous devez protéger la récupération de jetons avec Device.isDevice.

Les commandes d'installation typiques dépendent de votre gestionnaire de packages, mais la clé est l'alignement de version avec votre Expo SDK. N'associez pas des versions de packages arbitraires. Laissez Expo résoudre les versions compatibles.

Ajoutez une configuration au niveau du projet

Gardez votre config explicite. Un minimal app.json ou app.config.js devrait refléter le fait que les notifications font partie de votre contrat d'application, et non une pensée après-coup.

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "plugins": ["expo-notifications"],
    "ios": {
      "bundleIdentifier": "com.example.myapp"
    },
    "android": {
      "package": "com.example.myapp"
    },
    "extra": {
      "eas": {
        "projectId": "your-project-id"
      }
    }
  }
}

Un ou deux détails importent ici :

• Identificateurs de paquets et noms de paquets Il est essentiel de s'assurer que l'application que vous déployez correspond à celle que vous avez réellement prévue.
• Le plugin de notifications s'assure que le projet natif reçoit la configuration requise lors de la construction.
• L'ID du projet EAS est crucial lorsque la récupération de jeton s'attend à ce que l'application soit associée au projet Expo correct.

Définissez un gestionnaire de notification dès le début

Beaucoup de tutoriels de base attendent trop longtemps pour définir le comportement de notification. N'attendez pas. Placez-le près du démarrage de l'application afin que le comportement en arrière-plan soit prévisible.

import * as Notifications from 'expo-notifications';

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowAlert: true,
    shouldPlaySound: false,
    shouldSetBadge: true,
  }),
});

Les équipes décident si les notifications en arrière-plan doivent afficher une alerte, jouer un son ou affecter les badges. Le comportement exact dépend de votre produit. Une application de messagerie et une application de paiement ne feront pas les mêmes choix.

Si vous ne définissez pas intentionnellement le comportement en arrière-plan, votre équipe finira par déboguer les « notifications manquantes » qui ont été effectivement reçues mais n'ont jamais été présentées de la manière attendue par le produit.

Android nécessite une configuration de canal

Les canaux de notification Android ne sont pas optionnels en pratique. Si vous les ignorez, vos alertes peuvent avoir l'air incohérentes ou ne pas correspondre aux attentes des utilisateurs.

import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';

export async function configureAndroidNotifications() {
  if (Platform.OS !== 'android') return;

  await Notifications.setNotificationChannelAsync('default', {
    name: 'Default',
    importance: Notifications.AndroidImportance.MAX,
  });
}

Définissez cela lors de l'initialisation de l'application. Ensuite, maintenez les ID de canal stables. Les changements les affectant de manière occasionnelle rendent le comportement des notifications plus difficile à raisonner ultérieurement.

Demander la Permission et Capturer les Jetons de Push

C'est la partie que beaucoup d'équipes copient d'un snippet, puis finissent par regretter.

Les demandes de permission nécessitent un timing, une conscience de la plateforme et un traitement asynchrone discipliné. La capture de jetons doit se produire uniquement sur un appareil physique, uniquement après que les permissions soient résolues, et uniquement si vous êtes prêt à stocker le résultat sur votre backend immédiatement.

La fonction client qui devrait être votre point de départ

Utilisez une fonction comme celle-ci comme point de départ :

import * as Device from 'expo-device';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
import { Platform } from 'react-native';

type RegisterResult =
  | { ok: true; token: string }
  | { ok: false; reason: string };

export async function registerForExpoPushNotificationsAsync(): Promise<RegisterResult> {
  if (!Device.isDevice) {
    return { ok: false, reason: 'Push notifications require a physical device.' };
  }

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'Default',
      importance: Notifications.AndroidImportance.MAX,
    });
  }

  const permissions = await Notifications.getPermissionsAsync();
  let finalStatus = permissions.status;

  if (finalStatus !== 'granted') {
    const request = await Notifications.requestPermissionsAsync();
    finalStatus = request.status;
  }

  if (finalStatus !== 'granted') {
    return { ok: false, reason: 'Notification permission was not granted.' };
  }

  const projectId =
    Constants.expoConfig?.extra?.eas?.projectId ??
    Constants.easConfig?.projectId;

  if (!projectId) {
    return { ok: false, reason: 'Missing EAS project ID configuration.' };
  }

  const tokenResponse = await Notifications.getExpoPushTokenAsync({ projectId });

  return { ok: true, token: tokenResponse.data };
}

L'ordre compte. Vous vérifiez le type d'appareil en premier, configurez le comportement du canal Android, résolvez les permissions, validez la configuration du projet, puis demandez le jeton Expo.

Pourquoi Device.isDevice n'est pas facultatif

C'est l'une des rares erreurs qui crée beaucoup de bruit tout en semblant innocente. Les équipes expertes ne demandent la permission que conditionnellement lorsque Device.isDevice est vrai, et un piège commun est de passer outre ce garde, ce qui conduit les développeurs à envoyer des notifications à des jetons de simulateur invalides et à blâmer Expo lorsque le problème est vraiment la configuration de l'application, comme décrit dans Eagerworks’ notes d’implémentation d’Expo pour les notifications.

C’est pourquoi le contrôle se trouve en haut de la fonction. Ne le cachez pas derrière un helper. Faites-le évident.

Les résultats du simulateur sont utiles pour les tests de l’interface utilisateur. Ils ne sont pas fiables pour valider l’enregistrement du jeton de push.

Demandez la permission au bon moment

Ne demandez pas sur l’écran de démarrage. Ne demandez pas avant que l'utilisateur comprenne la valeur. Le meilleur moment est généralement après une action de l'utilisateur qui rend les avantages des notifications concrètes, comme l'activation des mises à jour de livraison, la participation à une conversation ou la sauvegarde d'un élément surveillé.

Une bonne implémentation suit généralement ce flux :

1. L'utilisateur atteint une limite de fonctionnalité significative.
2. L'application explique la valeur des notifications dans votre propre interface utilisateur.
3. L'application demande la permission du système.
4. L'application stocke le jeton sur le serveur backend immédiatement si la permission est accordée.

Ce dernier pas est là où beaucoup d'applications échouent. Elles récupèrent le jeton, le logent localement et reportent l'enregistrement backend. Plus tard, le support ne peut pas déterminer quel appareil avait quel jeton à quel moment.

Voici un exemple simple de stockage du jeton après l'enregistrement :

export async function enablePushForCurrentUser(userId: string) {
  const result = await registerForExpoPushNotificationsAsync();

  if (!result.ok) {
    return result;
  }

  await fetch('https://api.example.com/push-tokens', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: 'Bearer user-session-token',
    },
    body: JSON.stringify({
      userId,
      token: result.token,
      platform: Platform.OS,
    }),
  });

  return result;
}

Plus tard dans le flux de travail, ce guide est une référence visuelle utile :

Pour les équipes qui développent des applications avec de nombreuses mises à jour, il est également utile de considérer l'enregistrement des jetons comme faisant partie de l'état opérationnel de l'application, et non seulement comme partie de l'inscription. Cette mentalité convient bien aux flux de livraison d'applications Expo plus larges où le comportement de l'application peut changer fréquemment et l'état du serveur doit rester synchronisé.Envoyer des Notifications à Partir de Votre Serveur

Une fois que votre serveur backend a un jeton de mise à jour valide Expo, envoyer une notification est simple. La partie difficile n'est pas la demande elle-même. C'est déterminer ce qui doit figurer dans le payload et combien de confiance vous placez dans l'état du client.

Voici un exemple minimal Node-style utilisant

Ce que chaque champ du payload doit faire fetch:

type ExpoPushMessage = {
  to: string;
  title: string;
  body: string;
  sound?: 'default' | null;
  data?: Record<string, unknown>;
};

export async function sendExpoPushNotification(token: string) {
  const message: ExpoPushMessage = {
    to: token,
    title: 'New review received',
    body: 'Tap to open the order details.',
    sound: 'default',
    data: {
      type: 'new_review',
      orderId: 'ord_123',
      screen: 'OrderDetails',
    },
  };

  const response = await fetch('https://exp.host/--/api/v2/push/send', {
    method: 'POST',
    headers: {
      Accept: 'application/json',
      'Accept-encoding': 'gzip, deflate',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(message),
  });

  const result = await response.json();
  return result;
}

N'abusez pas du payload. Gardez chaque champ intentionnel.

Champ

Le data l'objet est là où les flux de travail des produits deviennent utiles. Vous pouvez passer un type et un ID de registre, puis laisser l'application récupérer les données les plus récentes lorsque l'utilisateur clique. C'est plus sûr que d'insérer des gros ou des blobs sensibles directement dans le payload.

Maintenez les payloads petits et sans intérêt

Selon La guide de Courier pour les notifications Expo, les jetons de notification Expo devraient être traités comme éphémères, les payloads qui dépassent les limites de taille d'environ 4 Ko peuvent être abandonnés, et un modèle fiable est d'envoyer des payloads de métadonnées de petite taille comme { "type": "new_review", "id": 123 } au lieu de grandes JSON ou de médias intégrés. Cette recommandation correspond à ce qui fonctionne dans les systèmes réels. Les payloads petits échouent moins souvent et vieillissent mieux lorsque les logiques de l'application changent.

Envoyez suffisamment de données pour router l'utilisateur. Récupérez le reste après que l'application s'ouvre.

Les habitudes côté serveur

Une fonction d'envoi de base est suffisante pour les tests. Une fonction de production ajoute généralement quelques responsabilités supplémentaires :

• Persister les tentatives d'envoi : Enregistrer l'intention de notification avec l'ID de l'utilisateur, le jeton, le type de payload et la date et l'heure.
• Étant donné le contenu de génération et le transport : Construire la copie du message dans une couche et la demande d'Expo API dans une autre.
• Gérer les retours d'informations d'invalidation : Si Expo signale ultérieurement que le token est DeviceNotRegistered, marquez-le comme obsolète et arrêtez les tentatives aveugles.
• Utiliser un design compatible avec les webhooks : Si votre système émet déjà des événements, routez les déclencheurs de notification à travers le même modèle de traitement de webhooks backend que vous utilisez ailleurs. Avant de déboguer les écouteurs de client, envoyez d'abord une mise à jour de test manuelle. Si un token reçoit une notification simple avec un petit payload, votre chemin de transport est probablement en bonne santé. Si ce n'est pas le cas, ne commencez pas par modifier la navigation __CAPGO_KEEP_0__. Commencez par valider le token, la forme du payload et l'état de permission. Gestion des notifications entrantes dans votre application

Before debugging client listeners, send a manual test push first. If a token receives a plain notification with a tiny payload, your transport path is probably healthy. If not, don’t start by changing navigation code. Start by validating the token, payload shape, and permission state.

La livraison n'est qu'une partie de la fonctionnalité. L'application doit faire quelque chose de cohérent lorsque la notification arrive et lorsque l'utilisateur la clique.

La livraison n'est qu'une partie de la fonctionnalité. L'application doit faire quelque chose de cohérent lorsque la notification arrive et lorsque l'utilisateur la clique.

Cela signifie gérer deux moments séparés :

• l'arrivée de la notification alors que l'application est ouverte
• l'utilisateur interagit avec la notification depuis la barre des notifications ou l'écran de verrouillage

La réception et la réponse de l'utilisateur sont des événements différents

Un setup fiable comprend généralement les deux écouteurs :

import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';

export function useNotificationObservers(
  onForegroundMessage: (notification: Notifications.Notification) => void,
  onNotificationTap: (response: Notifications.NotificationResponse) => void
) {
  useEffect(() => {
    const receivedSub = Notifications.addNotificationReceivedListener(
      (notification) => {
        onForegroundMessage(notification);
      }
    );

    const responseSub = Notifications.addNotificationResponseReceivedListener(
      (response) => {
        onNotificationTap(response);
      }
    );

    return () => {
      receivedSub.remove();
      responseSub.remove();
    };
  }, [onForegroundMessage, onNotificationTap]);
}

addNotificationReceivedListener s'exécute lorsque l'application est active. addNotificationResponseReceivedListener s'exécute lorsque l'utilisateur clique sur une notification livrée. N'y combinez pas mentalement. Ils servent des chemins UX différents.

Lisez les données de payload et naviguez intentionnellement

Voici un modèle pratique pour la gestion des clics :

type NotificationData = {
  type?: string;
  orderId?: string;
  screen?: string;
};

export function handleNotificationTap(
  response: Notifications.NotificationResponse,
  navigation: any
) {
  const data =
    response.notification.request.content.data as NotificationData;

  if (data.screen === 'OrderDetails' && data.orderId) {
    navigation.navigate('OrderDetails', { orderId: data.orderId });
    return;
  }

  if (data.type === 'new_review') {
    navigation.navigate('Inbox');
    return;
  }

  navigation.navigate('Home');
}

Ce modèle reste résilient car le payload contient des indices de navigation, pas des documents entiers. Si l'ordre a changé depuis que la notification a été envoyée, l'application peut récupérer l'état du serveur actuel après la navigation.

Une notification cliquée devrait conduire à un destinataire évident. Si votre chemin de secours est vague, les utilisateurs le remarquent immédiatement.

Le comportement en premier plan doit correspondre au contexte utilisateur

Lorsque l'application est déjà ouverte, afficher un avertissement système sans réfléchir peut paraître maladroit. Parfois, la bonne action est un bandeau d'application, une mise à jour de badge ou une mise à jour silencieuse. Une page de boîte de réception de support ne nécessite peut-être pas d'avertissement visible lorsque l'utilisateur lit déjà cette conversation.

C'est pourquoi votre écouteur en premier plan doit se diviser en fonction de la route et du type de notification. Par exemple :

• Écran de chat ouvert : ajoutez le message et évitez un bandeau redondant
• Écran de tableau de bord ouvert : affichez un toast léger en application
• Événement compte critique : affichez un traitement UI plus fort

Une approche simple ressemble à ceci :

export function handleForegroundNotification(
  notification: Notifications.Notification,
  currentRouteName: string
) {
  const data = notification.request.content.data as { type?: string };

  if (currentRouteName === 'ChatThread' && data.type === 'new_message') {
    // refresh local thread state
    return;
  }

  // otherwise show your own in-app UI or update badges
}

Si votre application ne distingue pas ces contextes, les utilisateurs ressentiront une fatigue des notifications plus rapidement, même si la livraison est correcte sur le plan technique.

Meilleures pratiques de production et erreurs courantes

La plupart des configurations de notifications de push Expo ne fonctionnent pas car les équipes supposent que le jeton est permanent, que les payloads peuvent transporter n'importe quoi et que les mises à jour de l'application ne toucheront pas la logique des notifications.

Ce supposé ne survit pas en production.

Les jetons sont éphémères, pas des enregistrements d'identité

Un jeton de notification Expo est le mieux traité comme un bail, et non comme un identifiant de dispositif à vie. DeviceNotRegisteredLes jetons peuvent tourner après un réinstall, des changements d'OS ou d'autres événements de cycle de vie. Si un jeton revient finalement

votre serveur devrait cesser de le traiter comme actif.

• Un modèle de serveur pratique stocke :
• ID d'utilisateur
• plateforme
• méta-données d'installation scoping
• jeton actuel
• État tel que actif, obsolète ou révoqué

Ne stockez pas un champ de jeton sur la table utilisateur et appelez-le terminé. Les utilisateurs ont plusieurs appareils, et les appareils changent d'état.

La stratégie de mise à jour compte plus que la plupart des tutoriels ne l'admettent

La guidance officielle de l'écosystème laisse un véritable écart opérationnel ici. Le contenu de notification push Expo existant ne précise souvent pas comment maintenir la validité du jeton à travers les cycles de revue de l'App Store et les mises à jour OTA , ce qui est d'autant plus important pour les équipes qui livrent des changements en direct car la fiabilité de la notification dépend de l'état actuel du jeton et de la synchronisation back-end, comme le note la documentation des notifications ExpoCela affecte la façon dont vous conçez les déclencheurs de mise à jour. De bons moments pour réconcilier l'état du jeton incluent : Lancement de l'application après une mise à jour.

Connexion de l'utilisateur

• Modification des paramètres de permission
• Rotation de jeton dans votre processus de livraison
• Travail sur votre processus de livraison
• Travail sur votre processus de livraison
• Flux de récupération après les billets de support liés à la poussée

La sécurité et la conformité ne doivent pas se trouver à la fin du sprint

Beaucoup de tutoriels Expo se concentrent sur les mécaniques et ignorent le risque opérationnel. C'est bien pour les applications de loisirs. Ce n'est pas bien pour les produits de santé, fintech ou commerce réglementé.

La discussion de Courier axée sur les entreprises met en évidence les lacunes de la prise en charge des notifications Expo met en évidence un manque de conseils pratiques autour de la gestion du consentement, des traçages d'audit et de la minimisation de l'exposition des données sensibles dans les payloads.

• Le takeaway direct de l'ingénierie est simple :
• Ne mettez pas de données sensibles d'entreprise dans le texte ou les métadonnées de notification.
• Enregistrez les changements de consentement côté serveur.
• Enregistrez l'intention de notification envoyée à quel token.

Utilisez les ID dans les payloads et récupérez le contenu protégé après l'ouverture de l'application. Pour les équipes alignant les opérations de mise à jour avec les pratiques de sécurité plus larges et API de l'application StoreLa poussée doit être incluse dans le même examen disciplinaire que l'authentification, les analyses et les journaux d'événements backend.

Les notifications Push sont des messages destinés aux utilisateurs, mais elles constituent également un problème de systèmes distribués. Traitez-les avec la même attention que vous appliquez à l'état d'authentification et aux événements de paiement.

Ce qui fonctionne généralement et ce qui fonctionne généralement

Un bon setup de push Expo n'est pas compliqué. C'est discipliné.

Si votre équipe livre des changements logiques fréquents d'applications et a besoin d'un contrôle plus serré sur le comportement de la mise en production, les retours en arrière, et la visibilité de la livraison, Capgo vaut la peine d'y jeter un coup d'œil. Il aide les équipes mobiles à envoyer des mises à jour rapidement sans attendre la revue de la boutique, ce qui est particulièrement utile lorsque les flux de notification, la logique de routage ou les corrections côté client doivent atteindre les utilisateurs rapidement.