¿Qué son las Notificaciones Push (APNs y FCM)?

Una notificación push es un mensaje iniciado en el servidor que los servicios de push de la plataforma entregan al dispositivo, incluso con la app cerrada. Los equipos de producto conocen el push como canal de engagement; esta entrada cubre la maquinaria de entrega — porque la maquinaria explica cada rareza de la que los equipos de producto se quejan. El hecho central: tu servidor nunca habla con el teléfono. Cada sistema operativo móvil mantiene exactamente una conexión persistente, optimizada para batería, con los gateways de push de iOS y Android (APNs, FCM) — y cada notificación de cada app viaja por esa tubería compartida.

Puntos clave

La cadena de entrega, de punta a punta

1  La app le pide al SO registrarse para push
2  El servicio de push de la plataforma emite un DEVICE TOKEN (la dirección)
3  La app envía el token a TU backend, que lo almacena
4  Algo sucede → el backend hace POST de { token, payload ≤4 KB } a APNs / FCM
5  El servicio de push encuentra la conexión persistente del dispositivo → entrega
6  El SO muestra la notificación — o despierta la app brevemente si el push es silencioso

El segundo trabajo de FCM: con las credenciales de APNs cargadas, acepta una
solicitud y reemite una solicitud compatible con APNs para los dispositivos iOS —
una sola superficie de API para ambas plataformas. Un BaaS abstrae incluso eso.

Ambas mitades en código — el cliente registrando su dirección, el backend enviando a un canal:

// JavaScript — Cloud Code (cloud/main.js)
// One send call reaches both platform push services
await Parse.Push.send({
  channels: ['scores'], // or `where:` with an Installation query
  data: {
    alert: 'Kickoff! Follow the match live.',
    badge: 'Increment',
    uri: 'app://match/8fk2',
  },
}, { useMasterKey: true });
// Back4app routes to APNs for Apple devices and FCM for Android — one API

// Flutter / Dart — Back4app Flutter SDK
// Register this install for push: token + channels live in an Installation
final installation = await ParseInstallation.currentInstallation();
installation
  ..set('channels', ['scores']) // subscribe to a topic-like channel
  ..set('user', currentUser);   // enables targeting by user later
await installation.save();
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs or FCM directly.

// iOS / Swift — Back4app Swift SDK
// Register this install for push: token + channels live in an Installation
var installation = ParseInstallation.current
installation?.channels = ["scores"] // topic-like channel
installation?.user = currentUser    // enables targeting by user later
try await installation?.save()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs directly.

// Android / Kotlin — Back4app Android SDK
// Register this install for push: token + channels live in an Installation
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("scores")) // topic-like channel
installation.put("user", ParseUser.getCurrentUser()) // target by user later
installation.saveInBackground()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching the push services directly.

Tokens de dispositivo: la dirección que no deja de cambiar

El ciclo de vida del token es el verdadero trabajo del backend, y la parte que las páginas explicativas se saltan. Registrar: el SO emite un token por instalación de la app. Almacenar: la app lo sincroniza con tu backend en cada arranque — los tokens cambian con reinstalaciones, restauraciones y limpiezas de datos, en silencio. Direccionar: los envíos apuntan a tokens, individualmente o vía el registro. Invalidar: los envíos a tokens muertos vuelven con errores específicos — 410 Gone de APNs, errores de token no registrado de FCM — y FCM considera obsoletos los tokens sin uso durante unos nueve meses. Podar: borra al ver esos errores, de inmediato. Los backends que se saltan el último paso acumulan tablas de tokens en descomposición que desperdician envíos, distorsionan las métricas de entrega y frenan campañas — el problema del token viejo es aburrido, acumulativo y el bug de push más común del mundo real.

APNs vs. FCM

La consecuencia práctica de la primera fila: todo backend cross-platform o integra ambos servicios, o usa FCM como superficie única (cargándole las credenciales de APNs), o le entrega el problema completo a una plataforma que guarda ambos juegos de credenciales — que es donde aterriza la sección de BaaS.

Lo que el push no promete

El contrato honesto, reunido en un solo lugar. Un 200 del servicio de push significa aceptado para entrega, no entregado. Los dispositivos offline no acumulan una cola fiel: APNs conserva solo la notificación más reciente por app; la cola de FCM expira con un TTL. Los optimizadores de batería en Android difieren la entrega de formas que no controlas; los usuarios pueden silenciar un canal o la app entera a nivel del SO, de forma invisible para tu backend. Los pushes silenciosos — despertares en segundo plano sin alerta visible — corren con un presupuesto horario mínimo y se descartan sin error al excederlo, según la documentación oficial de APNs; son pistas de refresh, no un protocolo de sincronización. La regla de diseño que se desprende: el push es el toque en el hombro — los datos en sí viajan por tu API cuando la app se abre, y cualquier cosa que deba llegar sí o sí gana un segundo canal.

Web push, en breve

Los navegadores estandarizaron su propia cadena: la página se suscribe vía la Push API usando tu par de claves VAPID (RFC 8292 — el servidor se identifica con un token firmado, sin registro ante ningún proveedor), el servicio de push del navegador devuelve una subscription (URL de endpoint + claves de cifrado) y tu servidor hace POST de payloads cifrados a ese endpoint según el Web Push Protocol. Un service worker recibe el evento push y muestra la notificación — con el sitio cerrado, y quizá el navegador cerrado en desktop. Cada fabricante de navegador opera su propio servicio de push; la URL del endpoint le dice a tu servidor dónde hacer el POST. La salvedad honesta: en iOS, el web push solo funciona para web apps instaladas en la pantalla de inicio.

Push vs. WebSockets vs. live queries

Son complementos con una frontera: el socket sirve al usuario que mira la pantalla; el push alcanza al usuario que dejó el teléfono. Las apps de chat demuestran el híbrido a diario — los mensajes fluyen por la conexión mientras la app está abierta, y el mismo mensaje se convierte en push en el momento en que deja de estarlo.

Casos de uso comunes

• Mensajes y menciones — el push canónico: alguien te necesita, la app está cerrada.
• Alertas transaccionales — pedido enviado, viaje llegando, pago acreditado: resúmenes de una línea con deep link hacia la app.
• Disparadores sensibles al tiempo — cambios de marcador, alertas de precio, momentos “X está en vivo” adyacentes a la presencia.
• Re-engagement — usado con moderación, con opt-outs por canal, o los usuarios lo desactivan todo.
• Pistas de badge y estado — el presupuesto silencioso gastado en empujar a la app a refrescarse antes de que el usuario la abra.

¿Deberías hacer push? Matriz de decisión

Limitaciones y trade-offs

• La entrega es una probabilidad, no una promesa. Diseña flujos que sobrevivan a un push perdido; reconcilia al abrir la app.
• Los permisos son capital de un solo disparo. El prompt del SO (explícito en iOS y la web, en runtime en el Android moderno) convierte mejor pedido en contexto — y un prompt negado es casi irreversible.
• El registro de tokens es un dataset vivo. Sincroniza al arrancar, poda ante errores, o mira cómo la entregabilidad decae en silencio.
• Los payloads son semipúblicos. Las notificaciones se muestran en pantallas de bloqueo y viajan por infraestructura de terceros — resúmenes e IDs, nunca secretos.
• Dos sistemas de credenciales, una funcionalidad. Claves .p8, credenciales de consola, expiración y rotación — el dolor de configuración es real, una vez por plataforma, y exactamente lo que las capas gestionadas absorben.

Push en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El servicio de push de Back4app convierte toda la cadena en datos: cada instalación se registra como un objeto Installation — token de dispositivo, plataforma, canales y un puntero al usuario capturados automáticamente, como muestran las pestañas de cliente — y una sola llamada de envío direcciona canales (al estilo de topics) o cualquier consulta de Installations (“todos en scores en Android que no abrieron la app esta semana”), con la plataforma guardando tus credenciales de APNs y FCM y enrutando por dispositivo. Los envíos se disparan desde Cloud Code — un afterSave en Message haciendo push al destinatario es la mitad de fallback del patrón híbrido —, desde jobs programados o desde la consola del dashboard para campañas puntuales. La higiene de tokens, las credenciales duales y las rarezas de payload por plataforma se vuelven comportamiento de la plataforma; tu código decide quién y qué, no cómo.