Guía Maestra de Notificaciones de Pus de Expo 2026

Probablemente estás en el punto donde 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. El primer instinto 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. trabajo de retención de usuarios de aplicaciones móvilessolo la entrega es útil si la experiencia del usuario alrededor de ella es predecible.

Índice

• La base para involucrar 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 del 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 Ingresantes en Tu Aplicación
  • La recepción de fondo y la respuesta del usuario son eventos diferentes
  • Lee el payload de datos y navega intencionalmente
  • El comportamiento de fondo debería coincidir con el contexto del usuario
• Prácticas y trampas comunes de producción
  • Los tokens son efímeros, no son 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
  • ¿Qué funciona normalmente y qué normalmente se rompe

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

Un notificación de Expo La configuración 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, puedes trabajar con la puerta de enlace de Expo y enfocarte 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 la notificación de push sea ‘menos real’. Solo cambia dónde va el esfuerzo de ingeniería.

El servicio también es lo suficientemente rápido que el rendimiento no es la primera cosa a la que preocuparse. Desde el 14 de marzo de 2023 hasta el 12 de junio de 2023, la notificación de push de Expo API mostró un tiempo de respuesta mediano de 42 milisegundos, 273 milisegundos de latencia p99, y an una tasa diaria promedio de errores del 0,17% a lo largo de decenas de millones de mensajes diarios, según el análisis de benchmark de Expo push de Knock API. Eso debería tranquilizar a cualquier equipo que se pregunte si Expo es solo adecuado para prototipos.

¿Qué abstrae realmente 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 APNs para iOS y FCM para Android.
• Formato de token: Su servidor almacena y envía un token de empuje de Expo en lugar de gestionar el manejo de tokens específicos de plataforma primero.
• Contrato de solicitud: Envía un payload por POST a Expo’s push API en lugar de integrar directamente las API de proveedor nativo.

Eso 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 fallos 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:

Esa es la diferencia entre "envío de notificaciones" y "notificaciones que apoyan un flujo de trabajo de producto real."

Configuración y configuración del proyecto inicial

Un montón de dolor de cabeza con la notificación de Expo comienza antes de la primera solicitud de permiso. Si la configuración del 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 instaladas correctamente y un entorno de desarrollo que coincida con el camino 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 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 notificaciones

Al menos, generalmente necesitará:

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

Las comandos de instalación típicos dependen del administrador de paquetes, pero la clave es la alineación de versiones con su Expo SDK. No mezcle versiones de paquetes arbitrarias. Deje 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 debería reflejar el hecho de que las notificaciones forman parte del contrato de su aplicación, no un afterthought.

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

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

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 el comportamiento de primer plano de manera intencional, su equipo terminará debatiendo sobre 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 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

Muchas veces los equipos copian este fragmento de un snippet, luego eventualmente se arrepienten.

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

Utilice 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

Esto es uno de los pocos errores que crea mucho ruido mientras parece inofensivo. Los equipos expertos solo solicitan permiso condicionalmente cuando Device.isDevice es verdadero, 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.

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

Los resultados del simulador son útiles para la prueba de 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 elemento 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 determinar qué dispositivo tenía qué token en qué momento.

Aquí está un ejemplo simple de almacenar el token después de la inscripción:

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

Más adelante en el flujo de trabajo, esta guía paso a paso es una referencia visual útil:

Para 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 de inicio. Esta mentalidad se ajusta bien a los flujos de trabajo de entrega de aplicaciones de Expo más amplios 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 de backend tenga un token de Expo Push válido, enviar una notificación es sencillo. La parte difícil no es la solicitud en sí. Es decidir qué pertenece en el payload y cuánta confianza le pone en el estado del cliente.

Aquí hay un ejemplo mínimo en estilo Node 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.

Mantenga los payloads pequeños y aburridos

Según La guía de Courier para notificaciones de ExpoLas 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 producción suele agregar algunas responsabilidades adicionales: "Conservar intentos de envío: "Guardar la intención de notificación con ID de usuario, token, tipo de payload y fecha de timestamp.
• Separar la generación de contenido de la transmisión: Crear copia de mensaje en un nivel y la solicitud de Expo API en otro.
• Gestionar feedback de invalidación: Si Expo informa más tarde que DeviceNotRegistered, marcar ese token como obsoleto y detener la repetición ciegamente.
• Usar 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 oyentes del cliente, envíe una prueba de notificación 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, forma del payload y estado de permiso. Gestionar Notificaciones de Entrada en Su Aplicación

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.

Separate content generation from transport:

Build message copy in one layer and the Expo __CAPGO_KEEP_0__ request in another.

That significa manejar dos momentos separados:

• el aviso llega mientras la aplicación está abierta
• el usuario interactúa con el aviso 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

Este es 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 en 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, actualización de distintivo o refresco silencioso. Una pantalla de correo de soporte puede no necesitar una alerta visible cuando el usuario ya está leyendo esa conversación.

Eso es por lo que tu oyente de primer plano debe ramificarse según la ruta y el tipo de notificación. Por ejemplo:

• Pantalla de chat abierta: añade el mensaje y evita una bandera redundante
• Pantalla de dashboard abierta: muestra una tostada de aplicación ligera
• Evento de cuenta crítico: presenta 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 tu aplicación no distingue estos contextos, los usuarios sentirán 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 fallan no lo hacen 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.

Esa suposición no sobrevive a la producción.

Los tokens son efímeros, no registros de identidad

Un token de notificación de Expo se debe tratar como un alquiler, no como un dispositivo de identidad 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 DeviceNotRegisteredSu servidor de backend 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 de última aparición
• __CAPGO_KEEP_0__ como activo, caducado o revocado

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

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

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 los ciclos de revisión de la Tienda de Aplicaciones y las actualizaciones OTA Lo cual es especialmente importante para los equipos que envían cambios en vivo porque la confiabilidad de las notificaciones depende del estado del token actual y la sincronización con el servidor, como se menciona enLa documentación de notificaciones de Expo Eso afecta cómo diseñan los disparadores de refresco. Buenos momentos para reconciliar el estado del token incluyen:.

Lanzamiento de la aplicación después de una actualización

• Iniciar sesión del usuario
• Cambio de configuración de permisos
• Rotación de credenciales en su proceso de lanzamiento
• Expo
• Flujos de recuperación después de tickets de soporte relacionados con empuje

La seguridad y la conformidad no deben estar 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 atención médica, fintech o comercio regulado

La discusión de Courier enfocada en la empresa sobre las brechas de notificaciones de Expo destaca una 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 sensibles. El consejo de ingeniería directo es simple:

• No ponga datos de negocio sensibles en el texto o 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 las cargas y recupere contenido protegido después de abrir la aplicación

Para equipos que alinean las operaciones de lanzamiento con la conformidad de la tienda de aplicaciones y las prácticas de seguridad __CAPGO_KEEP_0__ app store compliance and API security practicesEl empuje debe incluirse en el mismo disciplina de revisión que la autenticación, la analítica y el registro de eventos de backend

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 al estado de autenticación y a los eventos de pago.

¿Qué funciona normalmente y qué normalmente se rompe

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

Si su equipo envía cambios frecuentes en la lógica de la aplicación y necesita un control más estricto sobre el comportamiento de la liberación, los reenvíos y la visibilidad de la entrega, Capgo es digno de una mirada. 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 rápidamente.