Guida di Master Expo per le Notifiche Push 2026

Siete probabilmente al punto in cui l'app funziona, gli utenti sono stati registrati e il prodotto vuole flussi di ri-engaggio che sentano nativi. Ricordi della cesta. Suggerimenti di revisione. Nuove notifiche di messaggio. Annunci di rilascio. La prima istintiva è spesso quella di "mettere a punto le notifiche push", poi una settimana dopo si è impegnati a risolvere perché un dispositivo riceve le notifiche, il simulatore sembra registrare bene, ma nessuno può spiegare perché i tocchi non aprono la schermata giusta.

Quelle sono le notifiche push di Expo, che sono o piacevolmente semplici o sorprendentemente fragili.

Expo offre a gli squadre React Native uno strato pratico sopra APNs e FCM, che è esattamente il motivo per cui tante squadre lo utilizzano. Ma il gap tra una demo e un'implementazione pronta per la produzione è reale. Il ciclo di vita dei token, il timing delle autorizzazioni, la configurazione dei listener, la progettazione dei payload e la pulizia del backend contano. Se si stanno anche inviando cambiamenti logici dell'app, la necessità di disciplina operativa diventa ancora più acuta, soprattutto se il lavoro di retention dipende da messaggi affidabili e velocità di rilascio. Quello è lo stesso problema più ampio dietro lavoro di mantenimento della retenzione degli utenti per l'app mobile: la consegna è utile solo se l'esperienza utente che la circonda è prevedibile.

Indice dei contenuti

• La Fondazione per coinvolgere gli utenti con le notifiche di Expo
  • Cosa Expo astrae effettivamente
  • Cosa significa veramente la prontezza di produzione
• Configurazione iniziale del progetto e configurazione
  • Installa i pacchetti di notifica
  • Aggiungi la configurazione a livello di progetto
  • Imposta un gestore di notifica presto
  • Android richiede la configurazione del canale
• Richiesta di autorizzazione e cattura dei token di notifica
  • La funzione del client che dovrebbe essere il tuo punto di riferimento
  • Perché Device.isDevice non è facoltativo
  • Chiedi il permesso nel momento giusto
• Invia notifiche dal tuo server
  • Cosa dovrebbe fare ogni campo del payload
  • Mantieni i payload piccoli e noiosi
  • Abitudini utili sul lato server
• Gestisci le notifiche in arrivo nella tua app
  • La ricezione in primo piano e la risposta dell'utente sono eventi diversi
  • Leggi il payload dei dati e naviga intenzionalmente
  • Il comportamento in primo piano dovrebbe corrispondere al contesto dell'utente
• Pratiche migliori in produzione e comuni insidie
  • I token sono effimeri, non registri di identità
  • La strategia di aggiornamento conta più di quanto ammettono la maggior parte dei tutorial
  • La sicurezza e la conformità non devono essere considerate alla fine della sprint
  • Cosa funziona di solito e cosa si rompe di solito

La Fondazione per coinvolgere gli utenti con le notifiche push di Expo

Un Notifica push di Expo La configurazione è attraente per una ragione sopra tutte le altre. Elimina molta complessità di messaggistica nativa che le squadre non vogliono gestire già al primo giorno. Invece di costruire il tubo di APNs e FCM direttamente, puoi lavorare con la porta di ingresso di Expo e concentrarti sul comportamento del prodotto, la routing, l'esperienza di autorizzazione e la logica dei messaggi backend.

Quell'astrazione non rende le notifiche push meno reali. Cambia solo dove va il tuo sforzo di ingegneria.

Il servizio è anche abbastanza veloce che il rendimento non è il primo problema da cui preoccuparsi. Dal 14 marzo 2023 al 12 giugno 2023, le notifiche push di Expo API hanno mostrato un 42 millisecondo di tempo di risposta mediano, 273 millisecondo di latenza p99, e un di 0,17% di errori medi giornalieri su context: Capwesome Diff Experience Capgo. Page/area: Capawesome comparison page. Role: Long marketing or legal paragraph. Seen in: page capwesome.astro. di decine di milioni di messaggi Knock’s Expo push API benchmark analysiscontext: Knock’s Expo push benchmark analysis. Page/area: Blog post. Role: Quote or citation. Seen in: page expo-push-notification.astro.

Qual è il vero scopo di Expo

Quando gli sviluppatori dicono “push di Expo”, spesso intendono diversi problemi separati che vengono messi insieme:

• Fornitura di routing: Expo invia messaggi a APNs per iOS e FCM per Android.
• Formato del token: La tua server archivia e invia un token di notifica Expo al posto di gestire il trattamento dei token specifici per piattaforma in primo luogo.
• Richiesta di contratto: You POST a payload to Expo’s push API rather than directly integrating native provider APIs.

È utile, ma crea anche una comune fraintesa. Le squadre a volte suppongono che Expo gestisca ogni problema di consegna. In pratica, molti fallimenti provengono dall'applicazione code, dai token scaduti, dai payload distorti o da un flusso di autorizzazione povero.

Regola pratica: Tratta Expo come un layer di trasporto affidabile, non come un sostituto di un design client e backend solido.

Cosa significa effettivamente la prontezza di produzione

Un demo funzionante prova solo che un dispositivo ha accettato un payload una volta sola. La prontezza di produzione significa qualcos'altro:

Questa è la differenza tra "invia notifiche" e "notifiche supportano un flusso di lavoro di prodotto reale."

Configurazione e configurazione del progetto iniziale

Molte persone affrontano problemi con le notifiche Expo prima del primo avviso di autorizzazione. Se la configurazione del progetto è disordinata, il client code può sembrare corretto mentre l'app si comporta in modo inconsistente tra le build.

Inizia con le librerie giuste installate e un ambiente di sviluppo che corrisponde al percorso di build. Se lavori oltre Expo Go, è utile allineare il tuo flusso di lavoro locale con una configurazione del client di sviluppo Expo personalizzata Un ambiente di sviluppo personalizzato per Expoperché il comportamento delle notifiche spesso richiede di essere validato in un build che riflette la produzione più da vicino di un rapido esecuzione di sandbox.

Installa i pacchetti di notifica

Di minimo, avrai bisogno di:

• expo-notifications per le richieste di autorizzazione, la raccolta dei token, gli ascoltatori e la presentazione delle notifiche.
• expo-device perché dovresti proteggere la raccolta dei token con Device.isDevice.

Le comandi di installazione tipiche dipendono dal tuo gestore di pacchetti, ma la chiave è l'allineamento della versione con il tuo Expo SDK. Non mescolare versioni di pacchetti arbitrarie. Lascia che Expo risolva le versioni compatibili.

Aggiungi la configurazione a livello di progetto

Conserva la tua configurazione esplicita. Un minimo app.json o app.config.js context

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

perché dovresti riflettere il fatto che le notifiche fanno parte del tuo contratto di app, non un dopo pensiero.

• Alcuni dettagli sono importanti qui: è necessario sincronizzare l'app che effettivamente distribuisce.
• Il plugin delle notifiche assicura che il progetto nativo riceva la configurazione necessaria durante la compilazione.
• L'ID del progetto EAS è importante quando il recupero del token attende che l'app sia associata al progetto Expo corretto.

Imposta un gestore delle notifiche presto

Molti tutorial base aspettano troppo a definire il comportamento delle notifiche. Non farlo. Mettilo vicino all'avvio dell'app per garantire che il comportamento in primo piano sia predittibile.

import * as Notifications from 'expo-notifications';

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

Gli squadre decidono se le notifiche in primo piano dovrebbero visualizzare un avviso, riprodurre un suono o influenzare le badge. Il comportamento esatto dipende dal tuo prodotto. Un'app di chat e un'app di pagamento non faranno le stesse scelte.

Se non definisci intenzionalmente il comportamento in primo piano, la tua squadra finirà per debuggare le notifiche 'mancanti' che sono state effettivamente ricevute ma mai presentate nel modo in cui il prodotto si aspettava.

Android richiede la configurazione del canale

I canali di notifica Android non sono facoltativi nella pratica. Se li ignorate, le vostre avvisi possono sembrare inconsistenti o fallire nel soddisfare le aspettative degli utenti.

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,
  });
}

Imposta questo durante l'inizializzazione dell'app. Poi mantieni stabili gli ID dei canali. Cambiarli casualmente rende più difficile ragionare sul comportamento delle notifiche in seguito.

Richiesta di Autorizzazione e Captura dei Token di Push

Questo è il passaggio che molti team copiano da un snippet, poi si pentono alla fine.

Le richieste di autorizzazione richiedono un timing, una consapevolezza della piattaforma e un trattamento asincrono disciplinato. La cattura dei token deve avvenire solo su un dispositivo fisico, solo dopo che sono state risolte le autorizzazioni e solo se si è pronti a memorizzare il risultato sul backend immediatamente.

La funzione del client che dovrebbe essere il tuo punto di partenza.

Usa una funzione come questa come punto di partenza:

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'ordine conta. Controlli il tipo di dispositivo prima, imposti il comportamento del canale Android, risolvi le autorizzazioni, validi la configurazione del progetto, poi richiedi il token Expo.

Perché Device.isDevice non è facoltativo

Questo è uno dei pochi errori che crea molto rumore mentre sembra innocuo. Gli esperti team richiedono l'autorizzazione condizionalmente solo quando Device.isDevice è vero, e un comune tranello è saltare quel guardiano, che porta gli sviluppatori a inviare notifiche a token di simulator non validi e a incolpare Expo quando il problema è realmente la configurazione dell'app, come descritto in Eagerworks’ implementazione delle notifiche di Expo nota.

Quello è il motivo per cui il controllo si trova in cima alla funzione. Non nasconderlo dietro un aiutante. Faglielo apparire chiaro.

Il risultato del simulatore è utile per il testing della UI. Non è affidabile per la validazione della registrazione del token di push.

Chiedi il permesso nel momento giusto

Non chiedere sulla schermata di avvio. Non chiedere prima che l'utente capisca il valore. Il momento migliore è spesso dopo un'azione dell'utente che rende i benefici delle notifiche concrete, come abilitare gli aggiornamenti di consegna, unirsi a una conversazione o salvare un oggetto segnalato.

Una buona implementazione segue di solito questo flusso:

1. L'utente raggiunge un confine di funzionalità significativo.
2. L'app spiega il valore delle notifiche nella propria UI.
3. L'app richiede il permesso del sistema.
4. L'app memorizza il token sul backend immediatamente se il permesso è stato concesso.

Quel passaggio finale è dove molti app falliscono. Eseguono il recupero del token, lo registrano localmente e rimandano la registrazione sul backend. In seguito, il supporto non può dire quale dispositivo aveva quale token in quale momento.

Ecco un esempio semplice di memorizzazione del token dopo la registrazione:

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;
}

Più avanti nel workflow, questo walkthrough è una utile riferimento visivo:

Per le squadre che sviluppano app con rilascio pesante, è anche utile pensare alla registrazione del token come parte dello stato operativo dell'app, non solo come parte dell'onboarding. Questo modo di pensare si adatta bene a flussi di lavoro più ampi di consegna di app Expo Expo app delivery workflowsInvio di Notifiche dal tuo Server

Una volta che il tuo backend ha un token di notifica Expo valido, inviare una notifica è facile. La parte difficile non è la richiesta stessa. È decidere cosa appartiene al payload e quanto fiducia si mette nello stato del client.

Esempio minimale Node-style usando

Cosa deve fare ogni campo del payload 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;
}

Non trattare il payload come un mucchio di rifiuti. Mantieni ogni campo intenzionale.

Campo

Questo data L'oggetto è dove i flussi di lavoro dei prodotti diventano utili. Puoi passare un tipo e un ID del record, quindi lascia che l'app fetchi i dati più recenti quando l'utente clicca. È più sicuro che inserire grandi o sensibili blocchi direttamente nel payload.

Tenere i payload piccoli e noiosi

Secondo La guida di Courier per le notifiche di Expo, i token di notifica di Expo dovrebbero essere trattati come ephemeri, i payload che superano i limiti di dimensione di circa 4 KB possono essere eliminati, e un modello affidabile è quello di inviare payload di metadati piccoli come { "type": "new_review", "id": 123 } piuttosto che grandi JSON o media inline. Quell'indicazione corrisponde a ciò che funziona nei sistemi reali. I payload piccoli falliscono meno spesso e invecchiano meglio quando cambia la logica dell'app

Invia abbastanza dati per indirizzare l'utente. Esegui il resto dopo che l'app si apre

Abitudini utili del server

Una funzione di invio base è sufficiente per la prova. Una funzione di produzione aggiunge di solito alcune responsabilità in più:

• Persisti gli tentativi di invio: Salva l'intento di notifica con ID utente, token, tipo di payload e timestamp.
• Separare la generazione del contenuto dal trasporto: Costruisci la copia del messaggio in un layer e la richiesta di Expo API in un altro.
• Gestisci la feedback di invalidazione: Se Expo riporta in seguito DeviceNotRegisteredSegnala che il token è scaduto e fermati di riprovare senza senso.
• Utilizza un design amichevole per webhook: Se il tuo sistema emette già eventi, invia i trigger delle notifiche attraverso lo stesso modello di elaborazione di webhook sul backend che utilizzi altrove. Prima di debuggare gli ascoltatori del client, invia una notifica di test manuale. Se un token riceve una notifica normale con un payload piccolo, il tuo percorso di trasporto è probabilmente sano. Se non, non iniziare cambiando la navigazione __CAPGO_KEEP_0__. Inizia validando il token, la forma del payload e lo stato di autorizzazione. Gestione delle Notifiche In Arrivo nell'App

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.

Gestisci la feedback di invalidazione:

Se Expo riporta in seguito, segnala che il token è scaduto e fermati di riprovare senza senso.

Ciò significa gestire due momenti separati:

• la notifica arriva mentre l'app è aperta
• l'utente interagisce con la notifica dalla barra dei sistemi o dalla schermata di blocco

La ricezione e la risposta dell'utente sono eventi diversi

Un setup affidabile include di solito entrambi gli ascoltatori:

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 Esegue il codice quando l'app è attiva. addNotificationResponseReceivedListener Esegue il codice quando l'utente clicca su una notifica inviata. Non combinarli mentalmente. Servono percorsi UX diversi.

Leggi il payload dei dati e naviga intenzionalmente

Ecco un pattern pratico per il trattamento del tocco:

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');
}

Questo pattern rimane resiliente perché il payload contiene indizi di routing, non documenti interi. Se l'ordine è cambiato dal momento in cui la notifica è stata inviata, l'app può recuperare lo stato del server corrente dopo la navigazione.

Una notifica toccata dovrebbe portare a un destino ovvio. Se il tuo percorso di fallback è vago, gli utenti notano immediatamente.

Il comportamento in primo piano dovrebbe corrispondere al contesto utente

Quando l'app è già aperta, mostrare un avviso di sistema a caso può sembrare goffo. A volte il passo giusto è un banner in-app, aggiornamento della badge o un rinfresco silenzioso. Una schermata di posta in arrivo di supporto potrebbe non avere bisogno di un avviso visibile quando l'utente sta già leggendo quella conversazione.

È per questo che il tuo ascoltatore in primo piano dovrebbe ramificarsi in base alla rotta e al tipo di notifica. Ad esempio:

• Schermo della chat aperto: aggiungi il messaggio e evita un banner ridondante
• Schermo del dashboard aperto: mostra un toast in-app leggero
• Evento critico dell'account: presenta un trattamento UI più forte

Un approccio semplice assomiglia a questo:

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
}

Se il tuo app non distingue questi contesti, gli utenti sentiranno la fatica delle notifiche più velocemente, anche se la consegna è tecnicamente corretta.

Pratiche di produzione migliori e comuni insidie

La maggior parte delle configurazioni di notifiche push Expo non funzionanti non falliscono perché Expo è troppo limitato. Falliscono perché gli squadre assumono che il token sia permanente, i payload possono trasportare qualsiasi cosa e gli aggiornamenti dell'app non influenzeranno la logica delle notifiche.

Quell'assunzione non sopravvive alla produzione.

I token sono effimeri, non registri di identità.

Un Token di notifica Expo è meglio trattato come un affitto, non come un dispositivo di identificazione a vita. I token possono ruotare dopo reinstallazione, cambiamenti di sistema operativo o altri eventi di ciclo di vita. Se un token torna infine DeviceNotRegisteredIl tuo backend dovrebbe smettere di trattarlo come attivo.

Un modello backend pratico memorizza:

• ID utente
• piattaforma
• metadati di installazione a livello di applicazione
• token corrente
• timestamp dell'ultima visualizzazione
• Lo stato può essere attivo, scaduto o revocato

Non memorizzare un campo di token nella tabella degli utenti e considerare il problema risolto. Gli utenti hanno più dispositivi e i dispositivi cambiano stato.

La strategia di aggiornamento è più importante di quanto ammettano la maggior parte dei tutorial

Il supporto ufficiale lascia un vero gap operativo in questo senso. Il contenuto di notifica Expo push spesso non spiega come mantenere la validità del token durante i cicli di revisione dell'App Store e gli aggiornamenti OTA È particolarmente importante per le squadre che inviano cambiamenti live, poiché la affidabilità delle notifiche dipende dallo stato del token attuale e dalla sincronizzazione con il backend, come notato nella documentazione delle notifiche ExpoCiò influisce su come progettare i trigger di aggiornamento. Buoni momenti per riconciliare lo stato del token includono: L'evento di avvio dell'app dopo un aggiornamento.

L'accesso dell'utente

• La modifica delle impostazioni di autorizzazione
• Lavori di rotazione delle credenziali nella tua procedura di rilascio
• status such as active, stale, or revoked
• Don’t store one token field on the user table and call it done. Users have multiple devices, and devices change state.
• Flussi di recupero dopo i ticket di supporto relativi alle push

La sicurezza e la conformità non devono essere lasciate alla fine dello sprint

Molti tutorial di Expo si concentrano sulla meccanica e trascurano il rischio operativo. Va bene per le app di hobby. Non è bene per i prodotti sanitari adiacenti, fintech o commercio regolamentato.

La discussione di Courier focalizzata sull'enterprise evidenzia le lacune di Expo relative alle notifiche mette in evidenza la mancanza di una guida pratica per la registrazione del consenso, le tracce di audit e la minimizzazione dell'esposizione dei dati sensibili nel payload. L'estratto di ingegneria diretta è semplice:

• Non inserire dati aziendali sensibili nel testo o nel metadati del payload delle notifiche.
• Registra le modifiche del consenso sul server.
• Ricorda quale intento di notifica è stato inviato a quale token.
• Usa gli ID nei payload e recupera il contenuto protetto dopo l'apertura dell'app.

Per le squadre che allineano le operazioni di rilascio con le pratiche di sicurezza più ampie e __CAPGO_KEEP_0__ di conformità degli store di app app store compliance and API security practices__CAPGO_KEEP_0__

Le notifiche push sono messaggi destinati agli utenti, ma sono anche un problema di sistemi distribuiti. Trattiamole con la stessa cura che applichi allo stato di autenticazione e agli eventi di pagamento.

Quello che funziona di solito e quello che di solito si rompe

Una buona configurazione di push di Expo non è complicata. È disciplinata.

Se il tuo team invia modifiche logiche dell'app con frequenza e ha bisogno di un controllo più stretto sul comportamento di rilascio, sui rollback e sulla visibilità della consegna Capgo è degno di nota. Aiuta i team mobili a inviare aggiornamenti velocemente senza dover aspettare la revisione della store, il che è particolarmente utile quando sono necessarie flussi di notifica, logica di routing o correzioni client-side che devono raggiungere gli utenti velocemente.