Web vs. nativo: cuando una sola restricción decide toda la arquitectura
La elección entre web y nativo rara vez se decide por preferencia tecnológica. Casi siempre la decide un requisito no funcional que parece secundario hasta que no lo es.
La discusión de "web vs. nativo" suele plantearse como una cuestión de preferencia o de velocidad de desarrollo: la web es más rápida de iterar, lo nativo da mejor experiencia. Ese framing es cómodo, pero casi nunca es el que realmente decide el proyecto. En la práctica, la decisión suele estar determinada por un único requisito no funcional que, si se ignora al principio, obliga a una migración costosa después.
El caso que expone el problema
Imaginemos un sistema con dos tipos de usuarios: un administrador que gestiona información desde una oficina, y un coordinador de campo que necesita recibir una notificación, de verdad, confiablemente, incluso con la app cerrada, cuando ocurre un evento crítico en terreno.
Para el administrador, una aplicación web es, sin discusión, la opción correcta: sin fricción de instalación, actualizaciones instantáneas, y ningún requisito que dependa de ejecutarse en segundo plano. Para el coordinador de campo, la pregunta cambia por completo, porque la garantía que necesita, recibir una notificación push confiable, incluso con el navegador o la pestaña cerrados, no es algo que la web pueda ofrecer con la misma certeza que una app nativa o multiplataforma real.
Por qué "notificaciones push" no es una casilla que se marca igual en todas partes
Las push notifications en la web dependen de que el navegador mantenga viva una suscripción y de que el sistema operativo trate esa página como algo digno de despertar, una garantía mucho más débil, y mucho más inconsistente entre plataformas, que la que ofrece una aplicación nativa registrada directamente con el sistema de notificaciones del dispositivo. Si el negocio depende de que esa notificación llegue, porque de lo contrario alguien no atiende una emergencia a tiempo, la diferencia entre "probablemente llegue" y "está garantizado que llegue, con reintentos gestionados por el sistema operativo" no es un detalle técnico menor. Es la diferencia entre un sistema confiable y uno que falla silenciosamente en el peor momento posible.
La arquitectura correcta no es "todo nativo" ni "todo web"
La conclusión productiva no es "hagamos todo nativo para estar seguros", eso sacrifica velocidad de iteración donde no hace falta. La conclusión es segmentar la arquitectura según qué garantía necesita cada tipo de usuario, y aceptar que un mismo producto puede tener un frontend web para quien no necesita esa garantía y una app nativa o multiplataforma para quien sí.
Esto exige resistir una presión muy común en los equipos de producto: la preferencia por un único stack "por simplicidad". La simplicidad de mantener un solo frontend es real, pero no es gratis. El costo se paga en la confiabilidad exacta que el caso de uso más crítico necesita.
La pregunta que hay que hacer antes de elegir stack
No es "¿qué es más rápido de construir?" ni "¿qué prefiere el equipo?". Es: ¿cuál es la garantía más estricta que algún usuario de este sistema necesita, y qué tecnología puede ofrecerla de verdad? Una vez respondida esa pregunta, el resto de la arquitectura se organiza alrededor de ella, no al revés.