Guide de notification push Expo 2026

Vous êtes probablement à un point où l'application fonctionne, les utilisateurs ont signé, et le produit souhaite 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. La première impulsion est souvent de « simplement brancher la notification 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 approprié.

C'est là que les notifications push Expo sont soit agréables et simples, soit fragiles et surprenantes.

Expo offre 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 données du serveur comptent tous. Si vous faites également des changements fréquents de logique d'application, le besoin de discipline opérationnelle devient encore plus aigu, surtout si votre travail de retenue dépend de la messagerie fiable et de la vitesse de mise à jour. C'est la même préoccupation plus large derrière amélioration de la fidélité des utilisateurs d'applications mobiles: la livraison n'est utile que si l'expérience utilisateur qui l'entoure est prévisible.

Table des matières

• La Fondation pour captiver les utilisateurs avec les notifications Push Expo
  • Ce que Expo cache réellement
  • Ce que signifie la maturité de production
• Initialisation et configuration du projet
  • Installez les packages de notification
  • Ajoutez une configuration au niveau du projet
  • Configurez un gestionnaire de notification dès le début
  • La configuration du canal Android nécessite
• Demander la permission et capturer les jetons de notification
  • La fonction client qui devrait être votre ligne de base
  • Pourquoi Device.isDevice n'est pas facultatif
  • Demandez la permission au bon moment
• Envoyer des notifications à partir de votre serveur
  • Ce que chaque champ de la charge utile devrait faire
  • Gardez les charges utiles petites et sans intérêt
  • Habitudes utiles côté serveur
• 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
  • Lisez le contenu de la charge utile et naviguez 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 impliquer 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 autorisations 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 soit généralement pas la première chose à craindre. Du 14 mars 2023 au 12 juin 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 % d'erreurs quotidiennes à travers acrossdes dizaines de millions de messages quotidiens Knock’s Expo push API benchmark analysisKnock’s benchmark d’analyse de la messagerie push Expo __CAPGO_KEEP_0__

Expo se concentre en effet sur plusieurs préoccupations distinctes

Quand les équipes disent « messagerie push Expo », elles ont souvent en tête plusieurs préoccupations séparées :

• la mise en route du fournisseur : Expo transmet les messages à APNs pour iOS et FCM pour Android.
• Format du jeton : Votre serveur stocke et envoie un jeton de notification Expo au lieu de gérer la gestion des jetons spécifiques aux plateformes en premier.
• Contrat de demande : Vous envoyez un payload par la méthode POST vers le serveur de notification Expo API au lieu d'intégrer directement les API de fournisseur natif.

C'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 qui soutiennent un flux de workflow de produit réel ».

Initialisation et configuration du projet

Un grand nombre de douleurs de notification Expo commencent avant la première invitation de permission. Si votre configuration de projet est négligée, le client code peut paraître correct alors que l'application se comporte de manière incohérente entre les builds.

Commencez par les bibliothèques correctes installées 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 une mise en place de client de développement Expo personnalisée Initial Project Setup and Configurationparce que le comportement des notifications doit souvent être validé dans une mise en production qui ressemble plus à la production qu'une rapide exécution de sandbox.

Installez les packages de notification

En général, vous aurez 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 parce que 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 la version avec votre Expo SDK. N'allez pas mixez 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 context : Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `alternatives_cta_questions`). Page/zone : page de comparaison des alternatives de mise à jour en direct de Capacitor. Rôle : Paragraphe de marketing ou juridique long. Vu dans : page alternatives.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `alternatives_cta_questions` (Questions de CTA Alternatives). | Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `appflow_cta_questions`). Page/zone : page de comparaison/migration de Appflow. Rôle : Paragraphe de marketing ou juridique long. Vu dans : page ionic-appflow.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `appflow_cta_questions` (Questions de CTA Appflow). | Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `capwesome_cta_questions`). Page/zone : page de comparaison de Capawesome. Rôle : Paragraphe de marketing ou juridique long. Vu dans : page capwesome.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `capwesome_cta_questions` (Questions de CTA Capwesome). | Page/zone : page de services de consulting. Rôle : Sous-titre ou tagline de section. Vu dans : page consulting.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `consulting_faq_subtitle` (Sous-titre FAQ de consulting). | Page/zone : page de comparaison/migration d'Appflow. Rôle : Étiquette de navigation ou élément de navigation court. Vu dans : page ionic-appflow.astro, page ionic-enterprise-plugins.astro, page solutions/ionic-enterprise-plugins.astro. Clé de message `appflow_plugins_or` (Appflow Plugins Ou).

{
  "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"
      }
    }
  }
}

devrait refléter le fait que les notifications font partie de votre contrat d'application, et non une pensée après-coup.

• Un ou deux détails importants ici :  il faut que le contenu de l'application corresponde à celui que vous envoyez réellement.
• Le plugin de notifications assure que le projet natif reçoit la configuration requise lors de la construction.
• L'ID du projet EAS est important 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 tôt

Un grand nombre de tutoriels de base attendent trop longtemps pour définir le comportement de notification. Ne le faites 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é 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 IDs de canal stables. Les changer sans précaution rend le comportement des notifications plus difficile à raisonner plus tard.

Demander la Permission et Capturer les Jetons de Push

C'est là où beaucoup d'équipes copient un morceau de code, puis regrettent finalement.

Les demandes de permission nécessitent du timing, de la conscience de la plateforme et un traitement asynchrone discipliné. La capture de jetons doit se produire uniquement sur un appareil physique, uniquement après 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'un des rares erreurs qui créent beaucoup de bruit tout en paraissant sans danger. Les équipes expérimentées 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 vers 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 de notifications Expo.

C'est pourquoi la vérification se trouve en haut de la fonction. Ne la cachez pas derrière un assistant. Faites-l’é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 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 de backend immédiatement si la permission est accordée.

Cette dernière étape est là où beaucoup d'applications échouent. Elles récupèrent le jeton, le logent localement et retardent l'enregistrement de backend. Plus tard, le support ne peut pas dire 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;
}

L'explication détaillée de ce processus se trouve plus tard dans le flux de travail :

Pour les équipes créant 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. Cela correspond bien à des workflows plus larges de livraison d'applications Expooù le comportement de l'application peut changer fréquemment et où l'état du serveur doit rester synchronisé.

Envoyer des Notifications à Partir de Votre Serveur

Une fois que votre serveur backend dispose d'un jeton de notification 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. 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;
}

Voici un exemple minimal en style Node utilisant

Quel est le but de chaque champ du payload ?

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 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 la messagerie 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 petites 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 petites é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.

Comportements serveurs utiles

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

• Conservez les 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.
• Separer la génération de contenu de la 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 : S'il est rapporté plus tard par Expo DeviceNotRegisteredmarquez ce jeton obsolète et arrêtez de réessayer aveuglément.
• Utiliser un design compatible avec les webhooks : S'il émet déjà des événements votre système, dirigez les déclencheurs de notification à travers le même modèle de traitement de webhooks de backend que vous utilisez ailleurs. Avant de déboguer les écouteurs de client, envoyez d'abord une notification de test manuelle. Si un jeton reçoit une notification ordinaire 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 jeton, la forme du payload et l'état de permission. Gérer les 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.

Gérer les notifications entrantes dans votre application

La livraison n'est que la moitié 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 :

• la notification arrive 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 inclut 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 les deux. Ils servent des chemins UX différents.

Lisez le payload de données 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 serveur actuel après la navigation.

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

Le comportement en arrière-plan devrait correspondre au contexte utilisateur

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

C'est pourquoi votre écouteur en arrière-plan devrait se diviser en fonction de la route et du type de notification. Par exemple :

• L'écran de chat est ouvert : ajoutez le message et évitez un bandeau redondant
• L'écran de tableau de bord est ouvert : affichez un toast léger dans l'application
• Événement compte critique : donnez 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 au niveau technique.

Meilleures pratiques de production et erreurs courantes

La plupart des configurations 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.

Ce postulat ne résiste pas à la production.

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

Un jeton de notification Expo est mieux traité comme un bail, pas 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 backend devrait cesser de le traiter comme actif.

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

Ne stockez pas un champ de jeton sur la table utilisateur et appelez cela 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 documentation officielle de l'écosystème laisse un véritable écart opérationnel ici. Le contenu existant sur les notifications Expo ne précise souvent pas comment maintenir la validité du jeton au cours des cycles de revue de l'App Store et des mises à jour OTA. , ce qui est particulièrement 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 Expo.Ce qui affecte la façon dont vous conçez les déclencheurs de mise à jour. Les bons moments pour réconcilier l'état du jeton incluent : Lancement de l'application après une mise à jour.

Connexion de l'utilisateur

• Changement des paramètres de permission
• Rotation de la clé de votre processus de livraison
• App Store review cycles and OTA updates
• Expo notifications documentation
• Flux de récupération après les billets de support liés à la push

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 commerce réglementé, adjacents à la santé ou au financement.

La discussion de Courier sur les lacunes de notification Expo axée sur les entreprises met en évidence le manque de conseils pratiques sur la gestion des consentements, les traçages d'audit et la minimisation de l'exposition des données sensibles dans les métadonnées de payload. Le takeaway direct de l'ingénierie est simple :

• Ne mettez pas de données commerciales sensibles dans le texte ou les métadonnées de payload de notification.
• Enregistrez les changements de consentement côté serveur.
• Enregistrez lequel de l'intention de notification a été envoyé à quel jeton.
• Utilisez les ID dans les payloads et récupérez du 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 __CAPGO_KEEP_0__ de conformité avec les magasins d'applications app store compliance and API security practicesFlux de récupération après les billets de support liés à la push

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 accordez à 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 push Expo n'est pas compliquée. C'est discipliné.

Si votre équipe livre fréquemment des modifications de logique d'application et a besoin d'un contrôle plus serré sur le comportement de la mise en ligne, les retours en arrière et la visibilité de la livraison, Capgo Écrit par