Guide Maître Expo de notification Push 2026

Vous êtes probablement au point où l'application fonctionne, les utilisateurs sont connectés et le produit souhaite des flux de re-engagement qui ressentent la nativité. Les rappels de panier. Les invitations de révision. Les alertes de nouveaux messages. Les annonces de mise à jour. Le premier instinct 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 une couche 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 production prête à l'emploi est réelle. Le cycle de vie du jeton, le timing des permissions, la configuration des écouteurs, la conception du payload et la suppression du backend comptent tous. Si vous êtes également en train de livrer des changements logiques fréquents dans l'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 retention des utilisateurs de l'application mobileLa 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 fait réellement Expo
  • Ce que signifie vraiment la production prête
• 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
• Demande de permission et capture des jetons Push
  • La fonction client qui devrait être votre ligne de base
  • Pourquoi Device.isDevice n'est pas facultatif
  • Demandez la permission au bon moment
• Envoi de notifications à partir de votre serveur
  • Ce que chaque champ de la charge utile devrait faire
  • Conservez les charges utiles petites et anodines
  • Habitudes serveur utiles
• Gestion des notifications entrantes dans votre application
  • La réception en avant-plan et la réponse de l'utilisateur sont des événements différents
  • Lisez les données de la charge utile et naviguez intentionnellement
  • Le comportement en avant-plan devrait correspondre au contexte de l'utilisateur
• Meilleures pratiques de production et erreurs courantes
  • 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 Push d'Expo

Un Notification push d'Expo La mise en place est attrayante pour une raison qui l'emporte sur toutes les autres. Elle élimine 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 push « moins réelles ». Elle change simplement où va votre effort d'ingénierie.

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

Ce que fait en réalité Expo

Lorsque les équipes disent « Expo push », elles ont souvent en tête 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 du jeton : Votre serveur stocke et envoie un jeton de push Expo au lieu de gérer la gestion des jetons spécifiques aux plateformes en premier.
• Contrat de demande : Vous envoyez un payload vers Expo’s push API au lieu d’intégrer directement les API de fournisseur natif.

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 périmés, 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 ».

Initialisation et configuration du projet

Un grand nombre de douleurs de poussée Expo commencent avant la première invitation de permission. Si votre configuration de projet est négligente, le client code peut ressembler correctement tout en faisant que l'application se comporte de manière incohérente entre les builds.

Commencez avec les bibliothèques correctement installées et un environnement de développement qui correspond à votre chemin de construction. Si vous travaillez au-delà d'Expo Go, il est utile de synchroniser votre flux de travail local avec une configuration de client de développement Expo personnalisée, 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 devriez 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 afterthought.

{
  "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 need to match the app you actually ship.
• Le plugin de notifications s'assure que le projet natif obtient la configuration requise lors de la construction.
• L'ID du projet EAS est important lorsque votre récupération de jeton s'attend à ce que l'application soit associée au projet Expo correct.

Définissez un gestionnaire de notification tôt

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 un avertissement, 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 comme attendu 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 avertissements peuvent paraître incohérents 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 modifier sans précaution rend le comportement de notification plus difficile à raisonner plus tard.

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 la résolution des permissions, et uniquement si vous êtes prêt à stocker le résultat sur votre serveur 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 la vérification se trouve en haut de la fonction. Ne la cachez pas derrière un helper. Faites-la évidente.

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 activer les mises à jour de livraison, rejoindre une conversation ou sauvegarder 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.

Cette dernière étape est là où de nombreux 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;
}

Later in the workflow, this walkthrough is a helpful visual reference:

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 une étape de l'inscription. Cette mentalité convient bien aux workflows plus larges de livraison d'applications Expo Expo app delivery workflowsEnvoyer des Notifications à Partir de Votre Serveur

Une fois que votre serveur backend dispose d'un jeton de mise à jour valide Expo, l'envoi d'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 dossier, puis laisser l'application récupérer les données les plus récentes lorsque l'utilisateur clique dessus. C'est plus sûr que d'insérer des gros ou des blobs sensibles directement dans le payload.

Conservez les payloads petits et sans intérêt

D'après Le 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 mineures telles que { "type": "new_review", "id": 123 } au lieu de grandes chaînes JSON ou de médias intégrés. Cette recommandation correspond à ce qui fonctionne dans les systèmes réels. Les payloads mineurs échouent moins souvent et vieillissent mieux lorsque les logiques de l'application changent.

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

Les habitudes côté serveur

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

• Conservation des tentatives d'envoi : Enregistrez l'intention de notification avec l'ID de l'utilisateur, le jeton, le type de payload et la date et l'heure.
• Éloigner la génération de contenu de la transmission : Construire la copie de message dans une couche et la demande d'Expo API dans une autre.
• Gérer les retours d'informations d'invalidation : Si Expo signale plus tard que DeviceNotRegistered, marquez ce jeton 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, dirigez 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 jeton reçoit une notification simple avec un petit payload, votre chemin de transmission est probablement sain. Si ce n'est pas le cas, ne commencez pas par modifier la navigation __CAPGO_KEEP_0__. Commencez par valider le jeton, 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.

That means handling 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 exécuté lorsque l'application est active. addNotificationResponseReceivedListener exécuté lorsque l'utilisateur clique sur une notification livrée. N'y combinez pas mentalement. Ils servent des chemins UX différents.

Lisez le payload de données et naviguez intentionnellement

Ceci est 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 complets. 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 avant-plan doit correspondre au contexte utilisateur

Lorsque l'application est déjà ouverte, afficher un avertissement système sans y regarder peut paraître maladroit. Parfois, la bonne action est d'afficher un bandeau dans l'application, mettre à jour une vignette ou effectuer une mise à jour silencieuse. Une page de boîte à lettres 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 avant-plan doit se brancher 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 pièges courants

La plupart des paramétrages de notifications 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.

Cet hypothèse ne survit pas en production.

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

Un jeton Expo Push est mieux traité comme un bail, et non comme un identifiant de périphérique à vie. DeviceNotRegisteredLes jetons peuvent tourner après un réinstall, un changement d'OS ou d'autres événements de cycle de vie. Si un jeton revient finalement

votre serveur backend devrait cesser de le traiter comme actif.

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

N'entreposez pas un seul champ de jeton dans 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 le laissent entendre

La guidance officielle de l'écosystème laisse un véritable écart opérationnel ici. Le contenu de notification Expo existant ne présente souvent pas comment maintenir la validité du jeton à travers les cycles de revue de l'App Store et les mises à jour OTA Cela est d'autant plus important pour les équipes qui livrent des changements en direct, car la fiabilité des notifications 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. Les bonnes occasions 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
• Expo
• Expo
• 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écanismes et ignorent le risque opérationnel. C'est acceptable pour les applications de loisirs. Ce n'est pas acceptable 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 documentation Expo sur les notifications, en mettant en avant les problèmes de suivi des consentements, les traçages d'audit et la minimisation de l'exposition des données sensibles dans les payloads. La prise de conscience directe de l'ingénierie est simple :

• Ne mettez pas de données sensibles de votre entreprise dans le texte ou les métadonnées de notification.
• Enregistrez les changements de consentement côté serveur.
• Enregistrez lequel de l'intent de notification a été envoyé à quel jeton.
• Utilisez les ID dans les payloads et récupérez le contenu protégé après l'ouverture de l'application.

Pour les équipes qui alignent les opérations de mise en production avec les pratiques de sécurité plus larges et __CAPGO_KEEP_0__ de l'application Store app store compliance and API security practicespush devrait être inclus 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

Une bonne configuration de mise à jour d'Expo n'est pas compliquée. C'est discipliné.

Si votre équipe livre des changements logiques fréquents dans l'application 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.