Guía maestra de notificaciones de Expo Push 2026

Probablemente estás en el punto donde la aplicación funciona, los usuarios han iniciado sesión y el producto ahora quiere flujos de reenganche que se sientan nativos. Recordatorios de la cesta. Prompts de revisión. Alertas de nuevos mensajes. Anuncios de lanzamiento. La primera intuición es a menudo simplemente 'conectar push', luego una semana más tarde estás depurando por qué un dispositivo recibe alertas, el simulador parece registrarse bien y nadie puede explicar por qué los toques no abren la pantalla correcta.

Es ahí donde las notificaciones de Expo Push son o bien sencillas de manera agradable o bien sorprendentemente frágiles.

Expo ofrece a los equipos de React Native una capa práctica sobre APNs y FCM, lo que es exactamente por qué tantos equipos la utilizan. Pero la brecha entre una demostración y una implementación lista para producción es real. El ciclo de vida del token, el momento de los permisos, la configuración de los escuchadores, el diseño del payload y la limpieza del backend importan. Si también estás enviando cambios lógicos de aplicación con frecuencia, la necesidad de disciplina operativa se vuelve aún más aguda, especialmente si tu trabajo de retención depende de mensajería confiable y velocidad de lanzamiento. Eso es el mismo preocupación más amplia detrás trabajo de retención de usuarios de aplicaciones móvilesla entrega solo es útil si la experiencia del usuario alrededor de ella es predecible.

Contenido de la Tabla

• La Fundación para Engañar a los Usuarios con Notificaciones de Expo
  • ¿Qué es lo que realmente abstrae Expo?
  • ¿Qué significa realmente la preparación para producción?
• Configuración y Configuración del Proyecto Inicial
  • Instale los paquetes de notificación
  • Agregue la configuración a nivel de proyecto
  • Establezca un manipulador de notificaciones temprano
  • Android necesita configuración de canal
• Solicitar permiso y capturar tokens de notificación
  • La función del cliente que debería ser tu base
  • Por qué Device.isDevice no es opcional
  • Pide permiso en el momento adecuado
• Enviar Notificaciones desde tu Servidor
  • ¿Qué debería hacer cada campo del payload?
  • Mantén los payloads pequeños y aburridos
  • Hábitos útiles del lado del servidor
• Gestionar Notificaciones de Entrada en tu Aplicación
  • La recepción en primer plano y la respuesta del usuario son eventos diferentes
  • Lee el payload de datos y navega intencionalmente
  • El comportamiento en primer plano debería coincidir con el contexto del usuario
• Prácticas recomendadas de producción y trampas comunes
  • Los tokens son efímeros, no registros de identidad
  • La estrategia de refresco importa más que la mayoría de los tutoriales admiten
  • La seguridad y la conformidad no pertenecen al final del sprint
  • Lo que funciona normalmente y lo que normalmente se rompe

La Fundación para Enganchar a los Usuarios con Notificaciones de Expo

Un Notificación de Expo La configuración de notificaciones de Expo es atractiva por una razón sobre todas las demás. Elimina una gran cantidad de complejidad de mensajería nativa que los equipos no quieren asumir el día uno. En lugar de construir tuberías de APNs y FCM directas primero, pueden trabajar con la puerta de enlace de Expo y centrarse en el comportamiento del producto, la ruta, la UX de permisos y la lógica de mensajes de backend.

Esa abstracción no hace que las notificaciones sean ‘menos reales’. Solo cambia dónde va el esfuerzo de ingeniería.

El servicio también es lo suficientemente rápido como para que el rendimiento no sea la primera cosa a la que preocuparse. Desde el 14 de marzo de 2023 hasta el 12 de junio de 2023, las notificaciones de API de Expo mostraron un 42 milisegundos de tiempo de respuesta mediano, 273 milisegundos de latencia p99y un tasa diaria de errores promedio del 0,17% en contexto: texto fragmento de HTML de una cadena de Capgo más larga (clave principal `capwesome_diff_experience_capgo`). Página/área: página de comparación de Capawesome. Rol: párrafo de marketing o legal largo. Visto en: página capwesome.astro. Preservar términos de producto/marca y desarrollador de Capgo exactamente. Clave de mensaje `capwesome_diff_experience_capgo` (Capwesome Diff Experience Capgo).millones de mensajes diarios Knock’s Expo push API benchmark analysiscontexto: análisis de benchmark de Knock sobre la __CAPGO_KEEP_0__ de empuje de Expo

. Esto debería tranquilizar a cualquier equipo que se pregunte si Expo es solo apropiado para prototipos.

¿Qué es en realidad lo que abstrae Expo?

• Cuando los equipos dicen “Expo push,” a menudo se refieren a varias preocupaciones separadas empaquetadas juntas: Ruteo de proveedor: Expo envía mensajes a para iOS y FCM para Android.
• Formato de token: Su servidor almacena y envía un token de notificación de Expo en lugar de manejar el manejo de tokens específicos de plataforma primero.
• Contrato de solicitud: Envía un payload por POST a la API de notificación de Expo API en lugar de integrar directamente las APIs de proveedor nativo.

Es útil, pero también crea una confusión común. Los equipos a veces asumen que Expo es responsable de todos los problemas de entrega. En la práctica, muchos errores provienen de la aplicación code, tokens caducados, payloads malformados o flujo de permisos deficiente.

Regla práctica: Trate a Expo como una capa de transporte confiable, no como un sustituto de un diseño de cliente y servidor sólido.

¿Qué significa realmente la preparación para producción?

Un demo funcionando prueba solo que un dispositivo aceptó un payload una vez. La preparación para producción significa algo más:

La diferencia entre ‘enviar notificaciones’ y ‘notificaciones que apoyan un flujo de trabajo de producto real’.

Configuración inicial del proyecto y configuración

Un montón de dolor de Expo push comienza antes de la primera solicitud de permiso. Si la configuración de su proyecto es descuidada, el cliente code puede parecer correcto mientras la aplicación sigue comportándose de manera inconsistente entre compilaciones.

Comience con las bibliotecas correctas instaladas y un entorno de desarrollo que coincida con su ruta de compilación. Si está trabajando más allá de Expo Go, ayuda a alinear su flujo de trabajo local con una configuración de cliente de desarrollo de Expo personalizadaporque el comportamiento de las notificaciones a menudo necesita ser validado en una compilación que refleje más de cerca la producción que una rápida ejecución de sandbox.

Instale los paquetes de notificación

En general, necesitarás al menos:

• expo-notifications para solicitudes de permiso, recuperación de tokens, escuchas y presentación de notificaciones.
• expo-device porque deberías proteger la recuperación de tokens con Device.isDevice.

Las instrucciones de instalación típicas dependen de tu administrador de paquetes, pero la clave es la alineación de versiones con tu Expo SDK. No mezcles versiones de paquetes arbitrarias. Deja que Expo resuelva las compatibles.

Agregue la configuración a nivel de proyecto

mantenga su configuración explícita. Un mínimo app.json o app.config.js porque debería reflejar el hecho de que las notificaciones forman parte del contrato de su aplicación, no un aftertought.

{
  "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 par de detalles importan aquí:

• identificadores de paquetes y nombres de paquetes necesita coincidir con la aplicación que realmente envías.
• El plugin de notificaciones asegura que el proyecto nativo obtenga la configuración necesaria durante la compilación.
• El ID del proyecto EAS es importante cuando la recuperación de tokens espera que la aplicación esté asociada con el proyecto Expo correcto.

Establezca un manipulador de notificaciones temprano

Muchos tutoriales básicos esperan demasiado tiempo para definir el comportamiento de las notificaciones. No lo hagan. Colóquelo cerca del arranque de la aplicación para que el comportamiento de primer plano sea predecible.

import * as Notifications from 'expo-notifications';

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

Las equipos deciden si las notificaciones de primer plano deben mostrar una alerta, reproducir un sonido o afectar las insignias. El comportamiento exacto depende de su producto. Una aplicación de chat y una aplicación de pago no tomarán las mismas decisiones.

Si no definen intencionalmente el comportamiento de primer plano, su equipo terminará debatiendo sobre las notificaciones 'faltantes' que se recibieron pero nunca se presentaron de la manera en que el producto esperaba.

Android necesita configuración de canal

Los canales de notificaciones de Android no son opcionales en la práctica. Si los omiten, sus alertas pueden parecer inconsistentes o fallar en coincidir con las expectativas del usuario.

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

Establezca esto durante la inicialización de la aplicación. Luego mantenga los IDs de canal estable. Cambiarlos casualmente hace que el comportamiento de las notificaciones sea más difícil de razonar más adelante.

Solicitando permiso y capturando tokens de notificación push

Esta es la parte que muchos equipos copian de un snippet, y luego lamentan.

Las solicitudes de permiso necesitan tener un momento adecuado, conciencia de plataforma y manejo asincrónico disciplinado. La captura de tokens debe ocurrir solo en un dispositivo físico, solo después de que se resuelvan las permisos, y solo si está listo para almacenar el resultado en su servidor de backend de inmediato.

La función del cliente que debería ser su punto de partida

Use una función como esta como punto de partida:

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

El orden importa. Primero verifica el tipo de dispositivo, configura el comportamiento del canal de Android, resuelve los permisos, valida la configuración del proyecto, y luego solicita el token de Expo.

¿Por qué? Device.isDevice no es opcional

Esta es una de las pocas equivocaciones que crea mucho ruido mientras parece inofensiva. Los equipos expertos solo solicitan permiso condicionalmente cuando Device.isDevice no es opcional, y un error común es omitir ese guardián, lo que lleva a los desarrolladores a enviar notificaciones a tokens de simulador inválidos y culpar a Expo cuando el problema es realmente la configuración de la aplicación, como se describe en Eagerworks’ implementación de notificaciones de Expo nota.

Por eso, el cheque se encuentra en la parte superior de la función. No lo esconda detrás de un ayudante. Hágalo obvio.

Los resultados del simulador son útiles para la prueba de la interfaz de usuario. No son confiables para validar la inscripción del token de notificación.

Pida permiso en el momento adecuado

No pida en la pantalla de bienvenida. No pida antes de que el usuario comprenda el valor. El mejor momento es generalmente después de una acción del usuario que haga los beneficios de las notificaciones concretos, como habilitar las actualizaciones de entrega, unirse a una conversación o guardar un artículo observado.

Una buena implementación sigue generalmente este flujo:

1. El usuario alcanza un límite de características significativo.
2. La aplicación explica el valor de las notificaciones en su propia interfaz de usuario.
3. La aplicación solicita permiso del sistema.
4. La aplicación almacena el token en el servidor inmediatamente si se concede permiso.

El último paso es donde muchas aplicaciones fallan. Recuperan el token, lo registran localmente y posponen la inscripción en el servidor. Más tarde, el soporte no puede decir qué dispositivo tenía qué token en qué momento.

Un ejemplo simple de almacenamiento del token después de la inscripción es el siguiente:

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

Posteriormente en el flujo de trabajo, esta guía es una referencia visual útil:

Para las equipos que están construyendo aplicaciones con lanzamientos intensivos, también ayuda pensar en la registro de tokens como parte del estado operativo de la aplicación, no solo como parte de la configuración inicial. Esta mentalidad se ajusta bien con los flujos de trabajo más amplios de entrega de aplicaciones de Expo donde el comportamiento de la aplicación puede cambiar con frecuencia y el estado del servidor debe mantenerse sincronizado.Enviar Notificaciones desde su Servidor

Una vez que su servidor tenga un token de notificación de Expo válido, enviar una notificación es sencillo. La parte difícil no es la solicitud en sí misma. Es decidir qué pertenece en el payload y cuánta confianza le pone en el estado del cliente.

Un ejemplo mínimo de Node estilo utilizando

¿Qué debe hacer cada 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;
}

No trate el payload como un contenedor de basura. Mantenga cada campo intencional.

Campo

El data objeto es donde los flujos de trabajo de productos se vuelven útiles. Puedes pasar un tipo y un ID de registro, luego deja que la aplicación obtenga los datos más recientes cuando el usuario haga clic. Eso es más seguro que insertar grandes o sensibles blobs directamente en el payload.

Conserven los payloads pequeños y aburridos

Según La guía de Courier para notificaciones de Expo, los tokens de notificación de Expo deben tratarse como ephemeris, los payloads que exceden los límites de tamaño de aproximadamente 4 KB pueden ser descartados, y un patrón confiable es enviar payloads de metadatos pequeños como { "type": "new_review", "id": 123 } en lugar de grandes JSON o medios inline. Ese consejo coincide con lo que funciona en sistemas reales. Los payloads pequeños fallan menos a menudo y envejecen mejor cuando cambian la lógica de la aplicación.

Envíen suficiente datos para dirigir al usuario. Recuperen el resto después de que la aplicación se abra.

Hábitos útiles del lado del servidor

Una función de envío básica es suficiente para la prueba. Una función de producción suele agregar algunas responsabilidades adicionales:

• Persistan los intentos de envío: Almacenen la intención de notificación con el ID de usuario, token, tipo de payload y fecha y hora.
• Separar la generación de contenido del transporte: Construya el texto de la notificación en un nivel y la solicitud de Expo API en otro.
• Manejar la retroalimentación de invalidación: Si Expo informa más tarde DeviceNotRegisteredmarque ese token como obsoleto y detenga los intentos de reintentar de manera ciega.
• Utilice un diseño amigable con webhooks: Si su sistema ya emite eventos, dirija los disparadores de notificaciones a través del mismo patrón de procesamiento de webhooks de backend que utiliza en otros lugares. Antes de depurar los escuchadores del cliente, envíe una notificación de prueba manual primero. Si un token recibe una notificación plana con un payload pequeño, su ruta de transporte probablemente está sana. Si no, no comience cambiando la navegación __CAPGO_KEEP_0__. Comience validando el token, la forma del payload y el estado de permiso.

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 entrega solo es la mitad de la característica. La aplicación tiene que hacer algo coherente cuando llega la notificación y cuando el usuario la toca.

Separar la generación de contenido del transporte:

Eso significa manejar dos momentos separados:

• La notificación llega mientras la aplicación está abierta
• El usuario interactúa con la notificación desde la bandeja de notificaciones o pantalla de bloqueo

La recepción y la respuesta del usuario son eventos diferentes

Un conjunto de configuración confiable suele incluir ambos escuchadores:

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 Se ejecuta cuando la aplicación está activa. addNotificationResponseReceivedListener Se ejecuta cuando el usuario hace clic en una notificación entregada. No los combinen mentalmente. Sirven diferentes rutas de UX.

Lee el payload de datos y navega intencionalmente

Aquí está un patrón práctico para el manejo de 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');
}

Este patrón permanece resistente porque el payload contiene pistas de navegación, no documentos enteros. Si el orden ha cambiado desde que se envió la notificación, la aplicación puede recuperar el estado del servidor actual después de la navegación.

Una notificación pulsada debe llevar a un destino obvio. Si su ruta de fallback es vaga, los usuarios lo notan inmediatamente.

El comportamiento de primer plano debe coincidir con el contexto del usuario

Cuando la aplicación ya está abierta, mostrar una alerta de estilo de sistema de manera ciega puede sentirse torpe. A veces, el movimiento correcto es una bandera de aplicación en pantalla, actualización de una insignia o refresco silencioso. Una pantalla de bandeja de entrada de soporte puede no necesitar una alerta visible cuando el usuario ya está leyendo esa conversación.

Por eso, su oyente de primer plano debe ramificar según la ruta y el tipo de notificación. Por ejemplo:

• Pantalla de chat abierta: agregue el mensaje y evite una bandera redundante
• Pantalla de inicio abierta: muestre una notificación en pantalla ligera
• Evento crítico de la cuenta: presente un tratamiento de interfaz de usuario más fuerte

Un enfoque simple se parece a esto:

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 su aplicación no distingue estos contextos, los usuarios sentirán una fatiga de notificaciones más rápido, incluso si la entrega es técnicamente correcta.

Prácticas recomendadas de producción y trampas comunes

La mayoría de las configuraciones de notificaciones de Expo que no funcionan no fallan porque Expo es demasiado limitado. Fallan porque los equipos asumen que el token es permanente, los payloads pueden llevar cualquier cosa y las actualizaciones de la aplicación no afectarán la lógica de notificación.

No sobrevive a la producción esa suposición.

Los tokens son efímeros, no registros de identidad

Un token de notificación de Expo se trata mejor como un alquiler, no como un dispositivo de identificación a lo largo de la vida. Los tokens pueden rotar después de reinstalar, cambios de sistema operativo o otros eventos de ciclo de vida. Si un token eventualmente regresa DeviceNotRegistered, su servidor debe dejar de tratarlo como activo.

Un modelo de backend práctico almacena:

• ID de usuario
• plataforma
• metadatos de instalación escalados
• token actual
• timestamp visto por última vez
• estatus como activo, caducado o revocado

No almacenes un campo de token en la tabla de usuarios y llámelo hecho. Los usuarios tienen múltiples dispositivos, y los dispositivos cambian de estado.

La estrategia de refresco importa más de lo que admiten la mayoría de los tutoriales

La guía de la comunidad oficial deja un verdadero vacío operativo aquí. El contenido de notificaciones de Expo existente a menudo no explica cómo mantener la validez del token a lo largo de Ciclos de revisión de la tienda de aplicaciones y actualizaciones OTAlo cual es especialmente importante para los equipos que envían cambios en vivo porque la confiabilidad de la notificación depende del estado del token actual y la sincronización del servidor, como se menciona en documentación de notificaciones de Expo.

que afecta cómo diseñan los disparadores de refresco. Buenas veces para reconciliar el estado del token incluyen:

• lanzamiento de la aplicación después de una actualización
• ingreso del usuario
• cambio de configuración de permisos
• rotación de credenciales en su proceso de liberación
• Flujos de recuperación después de tickets de soporte relacionados con empuje

No hay seguridad y cumplimiento al final del sprint

Muchos tutoriales de Expo se centran en mecánicas y omiten el riesgo operativo. Eso está bien para aplicaciones de hobby. No está bien para productos de comercio electrónico relacionados con la atención médica, fintech o comercio regulado.

La discusión de Courier enfocada en empresas sobre las brechas de notificaciones de Expo destaca una falta de orientación práctica sobre el registro de consentimiento, registros de auditoría y minimización de exposición de paquetes de datos sensibles. El resultado directo de la ingeniería es simple:

• No ponga datos de negocio sensibles en el texto o metadatos de carga de notificaciones.
• Registre los cambios de consentimiento en el lado del servidor.
• Registre qué intención de notificación se envió a qué token.
• Utilice IDs en los paquetes y recupere contenido protegido después de abrir la aplicación.

Para equipos que alinean las operaciones de lanzamiento con prácticas de seguridad más amplias y __CAPGO_KEEP_0__ de cumplimiento de la tienda de aplicaciones app store compliance and API security practicesPara equipos que alinean las operaciones de lanzamiento con prácticas de seguridad más amplias y __CAPGO_KEEP_0__ de cumplimiento de la tienda de aplicaciones, el empuje debe incluirse en el mismo disciplina de revisión que la autenticación, el análisis y el registro de eventos de backend.

Notificaciones de empuje son mensajes dirigidos a los usuarios, pero también son un problema de sistemas distribuidos. Trátalos con el mismo cuidado que aplicas a los eventos de autenticación y pago.

¿Qué funciona normalmente y qué normalmente se rompe

Una configuración sólida de notificaciones de Expo no es complicada. Es disciplinada.

Si su equipo envía cambios de lógica de la aplicación con frecuencia y necesita un control más estrecho sobre el comportamiento de la liberación, los reenvíos y la visibilidad de la entrega, Capgo Es recomendable. Ayuda a los equipos móviles a enviar actualizaciones rápidamente sin tener que esperar a la revisión de la tienda, lo cual es especialmente útil cuando los flujos de notificaciones, la lógica de enrutamiento o las correcciones en el lado del cliente necesitan llegar a los usuarios lo antes posible.