Apps móviles basadas en web: guía práctica (PWA, wrappers WebView y alternativas nativas)
“App móvil basada en web” suele significar una de dos cosas:
- Una web app que corre en el navegador móvil (a veces instalable como PWA)
- Una web app empaquetada como app Android/iOS (un wrapper WebView como Capacitor)
Se ven parecidas para el usuario, pero se comportan distinto en rendimiento, acceso al dispositivo, distribución en tiendas y mantenimiento a largo plazo. Este post desglosa las opciones sin fingir que una gana en todos los casos.
Qué es realmente una “app móvil basada en web”
Una app basada en web usa HTML/CSS/JavaScript para la UI y la lógica. La pregunta es: ¿dónde corre?
- Navegador (PWA): Corre en Chrome/Safari como un sitio, con experiencia de “instalación” opcional.
- App WebView (Capacitor/Cordova/custom): Corre dentro de un shell de app nativa, pero sigue renderizando la UI en un WebView.
- Frameworks de UI nativa (React Native/Flutter): No son realmente “basados en web” en la UI; renderizan UI nativa (o nativa del framework), pero escribes una vez para varias plataformas.
Opción 1: PWA (Progressive Web App)
Qué es
Una PWA es una web app mejorada con manifest y service worker para caché offline, prompts de instalación (varían por plataforma) y comportamiento tipo app.
Cuándo encaja bien
- Quieres un solo codebase y despliegue inmediato (sin vueltas por la tienda de apps).
- La app es sobre todo contenido + formularios + dashboards.
- El soporte offline es “nice to have”, no crítico.
Dónde las PWA se quedan cortas
- Las limitaciones en iOS siguen en cosas como comportamiento en segundo plano y algunas APIs.
- Las notificaciones push son complejas entre plataformas y han sido irregulares (sobre todo en iOS según versión de OS y políticas).
- Monetización y descubrimiento en tienda son distintos frente a apps nativas.
Si tu producto es básicamente web, una PWA suele ser la opción más honesta.
Opción 2: TWA (Trusted Web Activity) para Android
Qué es
Una Trusted Web Activity es el enfoque de Google en Android para empaquetar tu experiencia web como una app usando Chrome por debajo. Es común cuando quieren “nuestra web en Play Store”.
Cuándo encaja bien
- Te importa sobre todo Android y quieres distribución en Play Store.
- No necesitas funciones nativas profundas más allá de lo que da la web.
- Ya tienes un sitio sólido y optimizado para móvil.
Inconvenientes
- Sigues atado a las “realidades de la web app”.
- La integración nativa profunda no es el objetivo de TWA.
Piensa en TWA como: “PWA + wrapper para Play Store”, no como “plataforma de app completa”.
Opción 3: Wrappers WebView (Capacitor, Cordova o WebView custom)
Qué es
Tu UI corre en un WebView, pero el empaquetado es una app Android/iOS real. Puedes puentear JavaScript con APIs nativas.
Por qué existe Capacitor
Si haces “solo un WebView”, enseguida acabas reconstruyendo lo mismo:
- selector de archivos / subida
- deep links + intents
- flujo de permisos
- notificaciones push
- acceso a cámara/galería
- botón atrás + integración de navegación
- temas de ciclo de vida (background/foreground, muerte del proceso)
Capacitor (y alternativas antiguas como Cordova) estandarizan eso con:
- una estructura de proyecto nativo predecible
- un sistema de plugins
- herramientas para builds e integración con la plataforma
Cuándo encajan bien los wrappers WebView
- Quieres reutilizar tu UI web (React/Vue/etc.) y publicar en Android/iOS.
- Necesitas funciones nativas pero no una UI totalmente nativa.
- Quieres distribución en tienda y seguir yendo rápido con herramientas web.
Cuándo encajan mal
- Estás haciendo algo muy animado, gráfico o sensible al rendimiento donde un WebView se notará “web”.
- Necesitas una UX muy nativa de plataforma con integración profunda con el SO y trabajo en segundo plano.
Capacitor vs “WebView custom”
- WebView custom: simple el día 1, caótico el día 30.
- Capacitor: más setup al principio, menos caos después.
Si el proyecto va a crecer, “solo un WebView” suele ser deuda técnica que eliges a propósito.
Opción 4: React Native / Flutter (no son UI web, pero son multiplataforma)
No son “basados en web” en la UI, pero son alternativas habituales cuando la gente cree que quiere una app basada en web y en realidad quiere una app con sensación nativa.
React Native
- Mejor si ya eres desarrollador React y quieres componentes nativos.
- Reescribes la UI con componentes de RN (no HTML/CSS).
Flutter
- Buen rendimiento y UI consistente entre plataformas.
- Construyes la UI en el framework de Flutter (Dart).
Úsalos cuando el pulido de UX y el rendimiento nativo importen más que reutilizar la UI web.
Checklist de decisión (elige el camino menos doloroso)
Responde a estas preguntas:
1) ¿Necesitas distribución en app store?
- No → PWA
- Sí (solo Android) → TWA
- Sí (Android + iOS) → sigue leyendo
2) ¿Necesitas funciones nativas del dispositivo?
- No mucho → PWA o TWA
- Sí → Capacitor (wrapper WebView) o RN/Flutter
3) ¿Quieres reutilizar tu UI web existente?
- Sí → Capacitor
- No / te vale rehacer la UI → React Native o Flutter
4) ¿Rendimiento y “sensación nativa” son requisito prioritario?
- Sí → React Native / Flutter
- No / moderado → Capacitor
Trampas habituales (aquí es donde fallan los proyectos)
“Es solo un wrapper” se convierte en una app real
En cuanto añades:
- notificaciones push
- persistencia de login
- subida/descarga de archivos
- deep links
- modo offline
deja de ser “solo un wrapper”. Planéalo desde el día uno o asume la deuda.
Offline no es una casilla
Offline implica:
- estrategia de caché
- resolución de conflictos
- límites de sincronización en segundo plano
Si no quieres pensar en eso, no prometas offline.
La UX móvil no es la UX de escritorio
Áreas de toque, scroll, teclado, safe areas, navegación atrás—las web apps necesitan diseño móvil de verdad para resultar aceptables.
Una recomendación “por defecto” sensata
- Si eres un equipo web y tu producto es web-first: PWA primero, luego empaqueta si hace falta.
- Si necesitas tienda + funciones nativas pero quieres reutilizar web: Capacitor.
- Si necesitas la mejor sensación nativa: React Native o Flutter.
El trade-off honesto es: velocidad y reutilización vs sensación nativa e integración profunda.