Por qué las apps híbridas fallan

Si has trabajado con apps híbridas (Ionic, Capacitor, React Native… da igual), sabes que las push notifications son el punto exacto donde todo deja de ser “desarrollo” y pasa a ser supervivencia.

En CODERE me tocó vivirlo de primera mano en un proyecto de apps de fidelización, y una de las fases críticas era integrar notificaciones push en una app híbrida. Sobre el papel: “conectar FCM/APNs y listo”. En la realidad: una distribución multipaís con requisitos distintos por mercado, y varios sistemas emitiendo notificaciones con estructuras diferentes según plataforma, proveedor y tipo de mensaje.

Los entornos de APNs (Apple Push Notification service) ya son una movida de por sí: certificados, entornos, permisos y un largo etc. Pero lo realmente divertido (en el peor sentido humano posible) vino cuando tuvimos que hacer que el frontal soportara notificaciones que no solo variaban entre iOS y Android, sino también según quién las enviaba: no es lo mismo una push emitida desde un proveedor tipo Salesforce o Dynamics que una enviada de forma más directa. Algunas llegaban como notificación visible, otras como push silenciosa (oculta), y el comportamiento cambiaba lo suficiente como para romper flujos enteros.

Y luego está el jefe final: el ciclo de vida de la app. Porque una push no “funciona” cuando te llega con la app abierta. Funciona cuando se comporta bien en todos los estados: primer plano, segundo plano, app cerrada, app muerta, e incluso con el teléfono recién encendido. Las notificaciones tienen que llegar en todos los casos, y la app tiene que enterarse y reaccionar correctamente. En híbrido, conseguir eso sin perder eventos, sin duplicarlos y sin depender de algún tipo de conjuro o encomendación divina es un problema esperpéntico.

Lo que aprendimos es simple: las push no son un “plugin”. Son la integración de conjunto de sistemas y que además afectan a diferentes capas del software. Si lo tratas como una feature suelta, te va a explotar en la cara.

El approach inicial fue el que sigue casi todo el mundo cuando trabaja con apps híbridas: instalar el plugin oficial de Capacitor para notificaciones push, seguir la documentación paso a paso y asumir que, si el ejemplo funciona, el problema está resuelto.

Al principio pareció funcionar… Con la app en primer plano, las notificaciones llegan. Los callbacks se disparan. Todo parece razonable.

El problema empieza cuando sales del happy path y empiezas a probar casuísticas reales. Entonces el sistema empieza a mostrar grietas:

• Notificaciones que no llegan si la app no está en primer plano.
• Notificaciones que llegan, pero con una estructura o forma que no se ha contemplado.
• Notificaciones que llegan al sistema operativo, pero Capacitor no se entera porque la app no está levantada.
• Eventos que se pierden entre estados porque nadie los estaba esperando.

A partir de ahí probamos distintas combinaciones: plugins oficiales, soluciones de terceros, ajustes de configuración, pequeños hacks para “forzar” comportamientos. El patrón se repetía siempre: funcionaban bien en algunos estados de la app, pero fallaban en otros. Y una solución que funciona el 80 % del tiempo no es una solución.

La conclusión fue incómoda, pero clara: no existe nada que cubra el 100 % de las casuísticas por sí solo. El problema es asumir que una pieza aislada puede gestionar un sistema que depende del ciclo de vida del SO, del backend y del estado de la aplicación al mismo tiempo.

Las push notifications son complejas incluso en apps nativas. Eso no lo discuto. Cualquiera que haya trabajado directamente con APNs o FCM sabe que no es un sistema trivial y que el margen de error existe incluso sin capas intermedias.

El problema es que en una app híbrida no tienes una sola capa que pueda fallar. Tienes varias.

Está la capa web, la capa nativa, el puente entre ambas (Capacitor) y, por supuesto, el backend que emite las notificaciones. Cada una tiene su propio ciclo de vida, sus tiempos y sus reglas. Y las push tienen la mala costumbre de atravesarlas todas.

Eso multiplica los puntos de fallo. Y en problemas como este, la arquitectura multicapa no ayuda en absoluto. Un evento puede llegar al sistema operativo, perderse en el puente, no propagarse al frontal web o llegar en un momento en el que la app simplemente no está preparada para procesarlo.

En nuestro caso concreto, el escenario era todavía más delicado. Teníamos un único frontal híbrido con distribución multipaís, funcionando contra distintos sistemas de envío de notificaciones y con estructuras de payload diferentes según mercado, plataforma y proveedor. No era solo iOS contra Android. Era iOS y Android recibiendo mensajes conceptualmente similares, pero técnicamente distintos.

El resultado era previsible: un sistema frágil, difícil de depurar y muy fácil de romper. Era un problema estructural.

Llegar a una solución estable no fue inmediato. Nos llevó varias semanas de I+D, pruebas, diferentes enfoques y bastantes errores controlados. No porque el problema fuera especialmente raro, sino porque no se resolvía atacándolo desde un único punto. La clave fue asumir que las push notifications en apps híbridas no se arreglan con un ajuste, sino con una arquitectura pensada para todos los estados posibles.

El primer paso fue poner orden en el caos.

En la capa web, dejamos de asumir que el payload que llega es “usable”. Independientemente de cómo viniera la notificación, la transformamos a un formato interno común que la aplicación pudiera entender sin condicionales infinitos. Un patrón Adapter de manual: mapear, normalizar y pintar correctamente en el frontal. Nada exótico, pero absolutamente necesario para que el sistema no dependiera del emisor.

Después, bajamos al nivel donde realmente se decide si una push funciona o no.

Creamos un plugin nativo con un servicio dedicado, responsable de recibir las notificaciones y propagarlas hacia las capas superiores. En Android, el hecho de declarar este componente como servicio permite que la aplicación reciba y procese notificaciones incluso cuando está muerta, que es el escenario donde la mayoría de soluciones híbridas fallan. En iOS, también fue necesario añadir lógica nativa específica para asegurar que las notificaciones llegaran correctamente al bridge y no se perdieran en el arranque.

Para Salesforce, el enfoque tuvo que ser distinto. Al gestionar las push mediante su SDK propietario, de forma bastante opaca, fue necesario implementar una integración nativa específica que interceptara y reenviara los eventos correctamente. Aquí no había atajos ni plugins genéricos que valieran.

En cuanto a la presentación de las notificaciones al usuario, Capacitor sigue utilizando el plugin oficial para recoger las push del panel del sistema y mostrarlas en la app. La diferencia es que ahora ese plugin es solo una pieza más dentro de un sistema controlado, no el centro de toda la lógica.

Todo este conjunto se diseñó para ser configurable y reutilizable mediante configuración, no código hardcodeado. El objetivo era claro: que esta solución pudiera aplicarse a cualquier app híbrida, independientemente del país, el proveedor de notificaciones o la estructura del payload.

Después de pelear con las notificaciones push en apps híbridas, hay varias conclusiones que quedaron claras y que conviene asumir antes de que el proyecto esté demasiado avanzado.

• Si vas a usar push notifications, decídelo desde el inicio del desarrollo. No es una feature que se añada al final. Afecta a la arquitectura, al diseño del backend y a la forma en la que la app gestiona su ciclo de vida. Tratarla como un extra suele acabar en parches y deuda técnica.
• Necesitas un set de pruebas sólido y realista. No basta con probar con la app abierta en un único dispositivo. Hay que testear en Android e iOS, con la app en primer plano, en segundo plano, cerrada y muerta. Si no lo pruebas así, fallará.
• El emisor importa tanto como el receptor. No es lo mismo recibir una push desde un backend propio que desde plataformas como Salesforce o Dynamics. Cada sistema estructura y entrega las notificaciones de forma distinta, y eso condiciona completamente la solución.
• El plugin no es la solución, es solo una pieza del puzle. Los plugins de Capacitor funcionan, pero no pueden resolver por sí solos un problema que depende del sistema operativo, del backend y del estado de la aplicación. Pensar lo contrario es delegar un problema de arquitectura en una dependencia.

Estas lecciones son el resultado de intentar que las push funcionen con usuarios reales y en todos los escenarios posibles.

Esta es una pregunta recurrente. Y no es casualidad. He visto muchas apps híbridas fracasar y terminar rehaciéndose en nativo por un único motivo: las push notifications. No por rendimiento, no por UX, no por escalabilidad. Solo por no haber sabido gestionar bien este punto crítico.

Siendo claros: las apps híbridas siguen siendo viables y, en muchos casos, una muy buena solución. Funcionan excepcionalmente cuando se entienden sus limitaciones y se diseñan los sistemas adecuados alrededor.

En nuestro caso, resolver el problema implicó una investigación profunda, tocando distintos lenguajes de programación, bajando a nivel nativo cuando hizo falta y trabajando con documentación incompleta o directamente inexistente. Aquí no hubo atajos. Y, por una vez, la IA tampoco fue de gran ayuda. El problema no estaba bien definido en ningún sitio, así que no había respuestas mágicas que copiar.

Esto marca la diferencia entre el éxito y el desastre.

Si tienes un equipo técnico experimentado, con visión cross-layer real, que entiende cómo funciona el backend, el bridge, la capa nativa y el frontal web, y que además tiene curiosidad y tolerancia a probar cosas que no están documentadas, una app híbrida puede funcionar perfectamente incluso en escenarios complejos.

Si no es así, el resultado suele ser el contrario: soluciones frágiles, dependientes de plugins, difíciles de depurar y que acaban colapsando en producción. Las apps híbridas no perdonan la falta de criterio técnico. Y las push notifications suelen ser el punto donde eso se hace evidente.

Si estás desarrollando una app híbrida y las push te están dando problemas, no estás haciendo nada “mal”. Estás chocando con uno de los puntos más delicados del desarrollo mobile híbrido moderno. La diferencia está en si decides parchearlo o resolverlo bien.

En ROGUE SYNTAX nos gusta trabajar en ese espacio incómodo donde los tutoriales se acaban: sistemas híbridos, integraciones complejas y problemas que no se arreglan copiando código. Si tu app está creciendo y empieza a romperse, probablemente no necesite más plugins, sino mejor arquitectura.

---

Y no, no siempre hay que rehacer todo en nativo. Pero sí hay que saber cuándo meter mano, dónde y por qué.