La web es un buen lugar para enviar una pantalla. Es un mal lugar para alcanzar el dispositivo. Un checkout o una página de contenido vive feliz dentro de un WebView; en el momento en que una función necesita una pieza real de hardware —un periférico Bluetooth, una etiqueta NFC, una notificación que realmente despierte el teléfono, una tarea que corre mientras la app está cerrada— la plataforma web se queda sin espacio. Esa brecha es el techo de capacidades, y es donde los mini-programas H5 calladamente dejan de poder competir con lo nativo.
El dispositivo que la web no ve del todo
Los sistemas operativos móviles exponen una enorme superficie nativa: cámaras, sensores biométricos, Bluetooth, NFC, ubicación precisa, ejecución en segundo plano, notificaciones locales, compartir del sistema, marcos de salud y wallet. La plataforma web solo alcanza una porción, y esa porción es desigual. Estándares web como Web Bluetooth, Web NFC, WebUSB, WebHID y Web Serial son experimentos exclusivos de Chromium —no existen en Safari ni en la mayoría de los WebViews dentro de apps. Así que la misma pantalla H5 se comporta distinto según qué motor la renderice, y la promesa de «escribir una vez» se rompe justo cuando una función necesita el dispositivo.
Un mapa de capacidades que sigue al motor
Las tablas de compatibilidad hacen concreto el techo. Web Bluetooth es totalmente compatible en Chrome y Edge (incluido Chrome en Android) pero no tiene soporte en Safari, en Safari en iOS, ni en los WebViews de Android o iOS (MDN). Web NFC puede leer y escribir etiquetas en Chrome en Android (89+) y en Android WebView (89+), pero está ausente en todos los navegadores de escritorio y en Safari en iOS (MDN). Web Push es el caso más cruel en la plataforma de Apple: un ingeniero DTS de Apple confirmó que «las notificaciones Web Push no funcionan en apps con un WKWebView». En iOS, Web Push existe solo para web apps que el usuario agregó a la pantalla de inicio (iOS 16.4+), nunca para contenido renderizado dentro del WebView de otra app. Una app de tráfico que incrusta H5 para sus comerciantes, por tanto, no puede prometer emparejamiento Bluetooth, toque NFC ni push confiable a esos comerciantes —no en iOS, y no de forma consistente en Android.
El arreglo frágil: un puente privado
La salida a la que recurren los equipos es un puente de JavaScript —un canal privado, inventado por cada super-app, que permite al H5 llamar al código nativo. Funciona, hasta que no. Cada host reinventa la rueda: una forma de API distinta, una historia de permisos distinta, un modelo de seguridad distinto, y una nueva superficie para los problemas de inyección y ataque que esta serie ya cubrió. Los puentes se actualizan al ritmo del host, no de la web, así que se desvían de la plataforma web documentada y unos de otros. El resultado es una capacidad que existe, pero fragmentada, ingobernable e imposible de auditar en el catálogo de mini-programas que aloja una plataforma.
La solución del runtime
Un runtime de propiedad del host reemplaza el puente ad hoc con una API de capacidades estandarizada y revisada. En lugar de que cada mini-programa negocie un canal privado, el runtime expone un conjunto consistente de capacidades del dispositivo —Bluetooth, NFC, push, tareas en segundo plano, cámara, biometría, notificaciones locales, compartir del sistema— detrás de una interfaz única, versionada y con permisos por capacidad que funciona igual en cada plataforma que el host soporta. El host define qué puede solicitar un mini-programa, el usuario lo concede por capacidad, y la llamada pasa por una ruta que la plataforma puede auditar. La capacidad deja de ser un proyecto científico por app y se vuelve un servicio gobernado.
| Dimensión | WebView | Runtime de propiedad del host |
|---|---|---|
| Alcance nativo | Una porción; depende del motor | Una API de capacidades consistente |
| Bluetooth / NFC | Solo Chromium; ausente en iOS WebView | Expuesto uniformemente donde el dispositivo lo permite |
| Push en iOS | No disponible dentro de un WKWebView | Push nativo vía el canal del host |
| Modelo de puente | Privado, por super-app, ingobernable | Estandarizado, revisado, por permisos |
| Auditabilidad | Casi nula en el catálogo | Una ruta auditada por capacidad |
El hilo conductor de esta serie es el control. Un WebView te deja dibujar una pantalla pero no alcanzar el dispositivo detrás; un runtime te deja alcanzar el dispositivo a través de un límite que defines. Para una app de tráfico cuyo valor son exactamente las cosas que un teléfono puede hacer —pagar, emparejar, tocar, notificar— ese límite es el producto.
Fuentes
- MDN: Web Bluetooth API — matriz de soporte: Chrome/Edge sí, Safari y WebViews iOS/Android no.
- MDN: Web NFC API — solo Chrome en Android y Android WebView; sin Safari en iOS.
- Apple Developer Forums: Web Push no disponible en WKWebView — confirmación DTS de que Web Push no funciona dentro de un WKWebView.
- WebKit: Web Push en iOS requiere Add to Home Screen (iOS 16.4+) — push limitado a web apps instaladas en la pantalla de inicio, no a WebViews dentro de apps.
- MDN/OpenPWA: uso de Web NFC (~35% global, StatCounter 2026) — contexto de uso global de Web NFC.
