Guía Maestra de Notificaciones de Pulsación 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

,

, ,,

Índice

• La base para involucrar a los usuarios con notificaciones de Expo
  • ¿Qué es lo que realmente abstrae Expo?
  • ¿Qué significa realmente la producción lista?
• Configuración y configuración del proyecto inicial
  • Instalar los paquetes de notificación
  • Agregar configuración a nivel de proyecto
  • Establecer un manejo 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é debe 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 de fondo y la respuesta del usuario son eventos diferentes
  • Lee el payload de datos y navega intencionalmente
  • El comportamiento de fondo debe 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 deben estar al final de la sprint
  • Lo que funciona normalmente y lo que normalmente se rompe

La Fundación para involucrar a los usuarios con notificaciones de Expo Push

Un La notificación de Expo Push 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, puede 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 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 suele ser la primera cosa a la que preocuparse. Desde el 14 de marzo de 2023 hasta el 12 de junio de 2023, las notificaciones de push de Expo API mostraron un 42 milisegundo de tiempo de respuesta mediano, 273 milisegundo de latencia p99, y un tasa diaria de errores promedio del 0,17% a lo largo de decenas de millones de mensajes diarios, según Knock’s Expo push API análisis de benchmark. Eso debería tranquilizar a cualquier equipo que se pregunte si Expo es solo adecuado para prototipos.

Lo que Expo abstrae en realidad

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: Pone a disposición un payload en 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?

Una demostración en funcionamiento 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 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 instaladas correctamente 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 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á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 comandos de instalación típicos 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.

Agregar configuración a nivel de proyecto

Mantén tu 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 tu 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"
      }
    }
  }
}

Un par de detalles importan aquí:

• Los identificadores de paquetes y nombres de paquetes deben 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

Muchas 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 el comportamiento de primer plano de manera intencional, su equipo terminará depurando 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 sobre más adelante.

Solicitar permiso y capturar tokens de empuje

Esto es la parte que muchos equipos copian de un snippet, luego eventualmente se arrepienten.

Las solicitudes de permisos necesitan una programación de tiempo, 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 permisos 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 los permisos, 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 permisos condicionalmente cuando Device.isDevice es verdadero, y un común error 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 Notas de implementación de notificaciones de Expo de Eagerworks.

Eso es por qué el chequeo se encuentra en la parte superior de la función. No lo esconda detrás de un helper. 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 empuje.

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 una frontera de características significativa.
2. La aplicación explica el valor de las notificaciones en la interfaz de usuario propia.
3. La aplicación solicita permiso del sistema.
4. La aplicación almacena el token en el backend de inmediato 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 backend. 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;
}

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 inscripción del token como parte del estado operativo de la aplicación, no solo como parte de la incorporación. Ese enfoque se ajusta bien a una perspectiva más amplia Flujos de trabajo de entrega de aplicaciones de Expodonde 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 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 de estilo Node utilizando 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;
}

¿Qué debe hacer cada campo del payload?

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

El data El 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.

Mantén los payloads pequeños y aburridos

Según Guía del mensajero de Courier para notificaciones de ExpoLas tokens de notificación de Expo deben tratarse como efímeros, los payloads que superan los límites de tamaño de aproximadamente 4 KB pueden ser descartados, y un patrón confiable es enviar payloads de metadata 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: Guarde la intención de notificación con el ID de usuario, token, tipo de payload y fecha de timestamp.
• Separe la generación de contenido de la transportación: Construya la copia de mensaje en una capa y la solicitud de Expo API en otra.
• Gestionar feedback de invalidación: Si Expo informa más tarde DeviceNotRegistered, marca ese token como obsoleto y detén los intentos de recuperación ciegos.
• 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 oyentes del cliente, envíe un empuje 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, 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.

Eso significa manejar dos momentos separados:

la notificación llega mientras la aplicación está abierta

• la notificación llega mientras la aplicación está abierta
• cuando el usuario interactúa con la notificación desde la bandeja de sistema o pantalla de bloqueo

los eventos de recepción y respuesta del usuario son diferentes

un setup 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.

lea el payload de datos y navegue de manera intencional

Aquí hay 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 resiliente porque el payload contiene pistas de enrutamiento, no documentos completos. 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 incómodo. A veces el movimiento correcto es una bandera de aplicación, actualización de insignia o refresco silencioso. Una pantalla de soporte de bandeja de entrada puede no necesitar una alerta visible cuando el usuario ya está leyendo esa conversación.

Eso es por lo que su oyente de primer plano debe ramificarse por ruta y tipo de notificación. Por ejemplo:

• Pantalla de chat abierta: añada el mensaje y evite un banner redundante
• Pantalla de dashboard abierta: muestre un toast en la aplicación de peso ligero
• Evento de cuenta crítico: 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 cansancio de notificaciones más rápido, incluso si la entrega es técnicamente correcta.

Prácticas recomendadas y trampas comunes de producción

La mayoría de las configuraciones de notificaciones de Expo rotas 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.

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

Los tokens son ephemeris, no registros de identidad

Un token de empuje de Expo se debe tratar 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 DeviceNotRegisteredSu servidor backend debe dejar de tratarlo como activo.

Un modelo de backend práctico almacena:

• ID de usuario
• plataforma
• metadatos de instalación escopados
• token actual
• última marca de tiempo vista
• estado como activo, caducado o revocado

No almacene 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 oficial del ecosistema 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 App y las actualizaciones OTA , lo 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 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
• Trabajo de rotación de credenciales en el proceso de lanzamiento
• Flujos de recuperación después de solicitudes de soporte relacionadas con notificaciones
• La seguridad y la conformidad no deben estar al final del sprint

La seguridad y la conformidad deben ser una prioridad en todo momento

A 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 atención médica, fintech o comercio regulado.

La discusión de Courier sobre las brechas de notificaciones de Expo enfocada en empresas destaca una falta de orientación práctica sobre el registro de consentimiento, huellas de auditoría y minimización de exposición de carga sensible en el payload. El consejo de ingeniería directo 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 las cargas y recupere contenido protegido después de que la aplicación se abra.

Para equipos que alinean las operaciones de lanzamiento con prácticas de seguridad más amplias y __CAPGO_KEEP_0__ de la tienda de aplicaciones app store compliance and API security practicesLas 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 aplicarías a los estados de autenticación y los eventos de pago.

¿Qué funciona normalmente y qué normalmente se rompe?

¿Qué funciona normalmente y qué normalmente se rompe?

Una configuración sólida de envío de Expo 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 una buena opción. 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 de manera rápida.