Guida alla notifica push di Expo Master 2026

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

È lì che le notifiche push di Expo sono o piacevolmente semplici o sorprendentemente fragili.

Expo fornisce a React Native un layer pratico sopra APNs e FCM, che è esattamente il motivo per cui così tanti team lo utilizzano. Ma il gap tra una demo e un'implementazione pronta per la produzione è reale. Il ciclo di vita del token, il timing delle autorizzazioni, la configurazione dei listener, la progettazione dei payload e la pulizia del backend contano. Se anche stai spedito cambiamenti logici dell'app frequente, la necessità di disciplina operativa diventa ancora più acuta, soprattutto se il tuo lavoro di mantenimento della retention dipende da messaggi affidabili e velocità di rilascio. È lo stesso preoccupazione più ampia dietro miglioramento della retenzione degli utenti per l'app mobilela consegna è utile solo se l'esperienza utente che la circonda è prevedibile.

Indice

• La Fondazione per coinvolgere gli utenti con le notifiche di Expo
  • Cosa Expo elimina effettivamente
  • Cosa significa veramente la prontezza per la produzione
• Configurazione e impostazione del progetto iniziale
  • Installa i pacchetti di notifica
  • Aggiungi la configurazione a livello di progetto
  • Imposta un gestore di notifica in anticipo
  • 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 Inbound nel tuo App
  • La ricezione in primo piano e la risposta dell'utente sono eventi diversi
  • Leggi il payload di dati e naviga intenzionalmente
  • Il comportamento in primo piano dovrebbe corrispondere al contesto dell'utente
• Pratiche e trappole comuni per la produzione e la qualità del prodotto
  • 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 appartengono 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 soprattutto. Elimina molta complessità di messaggistica nativa che le squadre non vogliono gestire già il giorno uno. 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 UX delle autorizzazioni e la logica dei messaggi backend.

Quell'astrazione non rende le notifiche '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 p99Ecco un'__CAPGO_KEEP_0__ di 0,17% di errori quotidiani, su decine di milioni di messaggi quotidiani secondo l'analisi di benchmark di Knock’s Expo push che dovrebbe rassicurare qualsiasi team che si chiede se Expo sia adatto solo per prototipiQuello che Expo astrae effettivamente Knock’s Expo push API benchmark analysisRouting del provider:

Expo invia messaggi a

APNs

• APNs APNs APNs per iOS e FCM per Android.
• Formato del token: Il tuo server memorizza e invia un Token di Push Expo al posto di gestire il trattamento dei token specifici per piattaforma in primo luogo.
• Contratto di richiesta: Invi un payload al push API di Expo al posto di integrare direttamente le API native dei provider.

È 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'app 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 veramente 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"

Impostazione e configurazione del progetto iniziale

Un sacco di dolore per le push Expo inizia prima della prima richiesta 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 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, perché il comportamento delle notifiche spesso richiede di essere validato in un build che rifletta la produzione più da vicino di una rapida esecuzione di sandbox.

Installa i pacchetti di notifica

Almeno, di solito avrai bisogno di:

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

I comandi di installazione tipici 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 compatibili.

Aggiungi la configurazione a livello di progetto

Mantieni la tua configurazione esplicita. Un minimo app.json o app.config.js dovrebbe riflettere il fatto che le notifiche fanno parte del tuo contratto di app, non un dopo pensiero.

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

Alcuni dettagli contano qui:

• Identificatori di bundle e nomi di pacchetto Per garantire che le notifiche siano coerenti con l'app che effettivamente viene distribuita.
• 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 aspetta che l'app sia associata al progetto Expo corretto.

Imposta un gestore delle notifiche fin da subito

Molti tutorial di base aspettano troppo a definire il comportamento delle notifiche. Non farlo. Colloca il gestore delle notifiche vicino all'avvio dell'app per garantire un comportamento prevedibile in primo piano.

import * as Notifications from 'expo-notifications';

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

Le 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 il comportamento in primo piano in modo intenzionale, la tua squadra si ritroverà a debuggere le notifiche

,

,

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

,

Richiesta di autorizzazione e cattura di token di push

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

Il richiesta di autorizzazione richiede 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 le autorizzazioni sono state risolte, e solo se sei pronto a memorizzare il risultato sul tuo 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 prima il tipo di dispositivo, impostare il comportamento del canale Android, risolvi le autorizzazioni, verifica la configurazione del progetto, poi richiedi il token di 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 l'errore è realmente la configurazione dell'app, come descritto in Eagerworks’ implementazione delle notifiche Expo: note.

Quello è il motivo per cui il controllo si trova in cima alla funzione. Non nascondilo dietro un aiutante. Faglielo capire.

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 seguito.

Una buona implementazione segue di solito questo flusso:

1. L'utente raggiunge un confine significativo della funzione dell'app.
2. L'app spiega il valore delle notifiche nel proprio UI.
3. L'app richiede il permesso del sistema.
4. L'app memorizza il token sul backend immediatamente se il permesso è stato concesso.

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

In un momento successivo del workflow, questo walkthrough è una utile riferimento visivo:

Per le squadre che stanno costruendo app con rilasci pesanti, è anche utile pensare alla registrazione dei token come parte dello stato operativo dell'app, non solo come parte dell'acquisizione. Questo mindset si adatta bene a flussi di lavoro di consegna di app Expo più ampidove il comportamento dell'app può cambiare frequentemente e lo stato del backend deve rimanere sincronizzato.

Invio di Notifiche dal Server

Una volta che il backend ha un token di push Expo valido, inviare una notifica è facile.

La parte difficile non è la richiesta stessa. 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;
}

È decidere cosa appartiene al payload e quanto fiducia si pone nello stato del client.

Ecco un esempio minimale Node-style usando

Il 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ù aggiornati quando l'utente clicca. È più sicuro di inserire direttamente nel payload grandi o sensibili blob.

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 pattern 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.

Inviare abbastanza dati per indirizzare l'utente. Estrarre 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 solitamente aggiunge alcune responsabilità aggiuntive:

• Persistere gli sforzi di invio: Salvare 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 Expo API in un altro.
• Gestisci la feedback di invalidazione: Se Expo riporta in futuro DeviceNotRegistered, segnala che il token è scaduto e smetti di riprovare senza senso.
• Utilizza un design amico dei webhook: Se il tuo sistema emette già eventi, invia i trigger delle notifiche attraverso lo stesso tipo di processamento di webhook 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.

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 consegna è solo la metà della funzionalità. L'app deve fare qualcosa di coerente quando la notifica arriva e quando l'utente la tocca.

Handling Incoming Notifications in Your App

Che significa gestire due momenti separati:

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

La ricezione in primo piano 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 quando l'app è attiva. addNotificationResponseReceivedListener Esegue quando l'utente tocca una notifica consegnata. 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 lo notano immediatamente.

Il comportamento in primo piano dovrebbe corrispondere al contesto utente

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

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

• Schermo della chat aperto: aggiungi il messaggio e evita un banner ridondante
• 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.

Il token è effimero, non un registro di identità

Un token di notifica Expo è meglio trattato come un affitto, non un dispositivo di identificazione a vita. I token possono rotare 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 di backend pratico memorizza:

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

Non memorizzare un campo di token nella tabella degli utenti e pensare di essere finiti. Gli utenti hanno più dispositivi e i dispositivi cambiano stato.

La strategia di aggiornamento conta più di quanto ammettono la maggior parte dei tutorial

La guida ufficiale dell'ecosistema lascia un vero e proprio divario operativo qui. Il contenuto delle notifiche di Expo spesso non spiega come mantenere la validità dei token all'interno di Cicli di revisione dell'App Store e aggiornamenti OTA, che è particolarmente importante per le squadre che inviano modifiche live perché la affidabilità delle notifiche dipende dallo stato dei token corrente e dalla sincronizzazione del backend, come notato in Documentazione delle notifiche di Expo.

Ciò influenza come progettare i trigger di aggiornamento. Buoni momenti per riconciliare lo stato dei token includono:

• Lancio dell'app dopo un aggiornamento
• Accesso dell'utente
• Modifica delle impostazioni delle autorizzazioni
• Lavoro di rotazione delle credenziali nel processo di rilascio
• Flussi di ripristino dopo biglietti di supporto correlati a push

La sicurezza e la conformità non devono essere al termine della sprint

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

Il discorso di Courier incentrato sull'impresa sui vuoti di notifica di Expo mette in evidenza una mancanza di linee guida pratiche relative alla registrazione del consenso, ai registri di audit e alla minimizzazione dell'esposizione dei dati di payload sensibili. Il takeaway di ingegneria diretta è semplice:

• Non mettere i dati di business sensibili nel testo o nel metadati di payload delle notifiche.
• Registra i cambiamenti di consenso sul server.
• Registra 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 e di conformità dell'app store 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 applichiamo allo stato di autenticazione e agli eventi di pagamento.

Cosa funziona di solito e cosa di solito si rompe

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

Se il tuo team invia cambiamenti logici 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 una visita. Aiuta i team mobili a inviare aggiornamenti velocemente senza dover aspettare la revisione della store, il che è particolarmente utile quando sono necessari flussi di notifiche, logica di routing o riparazioni client-side che devono raggiungere gli utenti velocemente.