Guía Maestra de Notificaciones de Expo 2026

Probablemente estás en el punto en el que la aplicación funciona, los usuarios se han registrado 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 a la vez sencillas y 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 mensajes confiables 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 del Cuadro

• 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
  • No es opcional porque Device.isDevice
  • 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
• Manejar 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’. Simplemente cambia dónde va el esfuerzo de ingeniería.

El servicio también es lo suficientemente rápido 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 UI 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 notificación de Expo __CAPGO_KEEP_0__

. 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 “notificación de Expo”, 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.
• Solicitud de contrato: Envía un payload por POST a la API de notificación de Expo API en lugar de integrar directamente las APIs de proveedores nativos.

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 radica 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 personalizada Configuración de proyecto y configuraciónporque 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

Por lo menos, generalmente necesitarás:

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

o

• debe reflejar el hecho de que las notificaciones forman parte del contrato de tu aplicación, no un aftertought. debe 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 manejo 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,
  }),
});

Los 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á debbugueando las notificaciones "faltantes" que se recibieron pero nunca se presentaron de la manera 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 para 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 estables. Cambiarlos casualmente hace que el comportamiento de las notificaciones sea más difícil de razonar más adelante.

Solicitar Permiso y Capturar Tokens de Push

Esta es la parte que muchos equipos copian de un snippet, 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 resolver las permisiones, y solo si está listo para almacenar el resultado en su 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 las permisiones, valida la configuración del proyecto, 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 oculte 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 pregunte en la pantalla de bienvenida. No pregunte antes de que el usuario comprenda el valor. El mejor momento es usualmente 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 postergan la inscripción en el servidor. Más tarde, el soporte no puede determinar 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;
}

En una etapa posterior del 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 inscripción 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 a 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 permanecer 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 al payload y cuánta confianza se puede tener 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 El objeto es donde los flujos de trabajo de productos se vuelven útiles. Puedes pasar un tipo y un ID de registro, y luego dejar 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 paquete.

Considere 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íe suficiente datos para dirigir al usuario. Recupere 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:

• Persista los intentos de envío: Almacene la intención de notificación con el ID de usuario, el token, el tipo de payload y la fecha y hora.
• Generar contenido de forma independiente del transporte: Crear copia de mensaje en un nivel y la solicitud de Expo API en otro.
• Manejar feedback de invalidación: Si Expo informa más tarde DeviceNotRegisteredmarcar ese token como obsoleto y detener la repetición ciegamente.
• Diseñar con un patrón de procesamiento de webhooks amigable: Si su sistema ya emite eventos, dirija los disparadores de notificaciones a través del mismo tipo de patrón de procesamiento de webhooks de backend que utiliza en otros lugares. Antes de depurar los escuchadores de 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á saludable. Si no, no comience cambiando la navegación __CAPGO_KEEP_0__. Comience validando el token, forma del payload y 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.

Usar un diseño amigable con webhooks:

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 enrutamiento, 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 tu 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 panel de control abierta: muestre una tostada de aplicación ligera
• Evento crítico de cuenta: surfice 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 la 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 las notificaciones.

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 debe tratar mejor como un alquiler, no como un dispositivo identificador de toda 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 servidor práctico almacena:

• ID de usuario
• plataforma
• metadatos de instalación escopados
• token actual
• timestamp de última aparición
• estado 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 la emisión de notificaciones

No hay seguridad y cumplimiento en el final del sprint

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

La discusión de Courier enfocada en empresas sobre las brechas de notificaciones de Expo destaca la falta de orientación práctica sobre el registro de consentimiento, las huellas de auditoría y la minimización de la 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 en el metadato 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 de datos y recupere contenido protegido después de abrir la aplicación.

Para los equipos que alinean las operaciones de lanzamiento con las prácticas de seguridad y cumplimiento más amplias del app store app store compliance and API security practices__CAPGO_KEEP_0__

Las 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 estados de autenticación y eventos de 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 lógicos 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 echarle un vistazo. 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 con rapidez.