A web é um bom lugar para entregar uma tela. É um mau lugar para alcançar o dispositivo. Um checkout ou uma página de conteúdo vive feliz dentro de um WebView; no momento em que uma função precisa de um pedaço real de hardware —um periférico Bluetooth, uma etiqueta NFC, uma notificação que realmente acorde o telefone, uma tarefa que roda enquanto o app está fechado— a plataforma web fica sem espaço. Essa lacuna é o teto de capacidades, e é onde os mini-programas H5 silenciosamente deixam de poder competir com o nativo.
O dispositivo que a web não enxerga por inteiro
Os sistemas operacionais móveis expõem uma vasta superfície nativa: câmeras, sensores biométricos, Bluetooth, NFC, localização precisa, execução em segundo plano, notificações locais, compartilhamento do sistema, estruturas de saúde e carteira. A plataforma web alcança apenas uma fatia, e essa fatia é desigual. Padrões web como Web Bluetooth, Web NFC, WebUSB, WebHID e Web Serial são experimentos exclusivos do Chromium —não existem no Safari nem na maioria dos WebViews dentro de apps. Assim, a mesma tela H5 se comporta diferente conforme o motor que a renderiza, e a promessa de «escrever uma vez» quebra exatamente quando uma função precisa do dispositivo.
Um mapa de capacidades que segue o motor
As tabelas de compatibilidade tornam o teto concreto. O Web Bluetooth é totalmente suportado no Chrome e Edge (incluindo Chrome no Android), mas não tem suporte no Safari, no Safari no iOS, nem nos WebViews de Android ou iOS (MDN). O Web NFC consegue ler e escrever etiquetas no Chrome no Android (89+) e no Android WebView (89+), mas está ausente em todos os navegadores de desktop e no Safari no iOS (MDN). O Web Push é o caso mais cruel na plataforma da Apple: um engenheiro DTS da Apple confirmou que «as notificações Web Push não funcionam em apps com um WKWebView». No iOS, o Web Push existe apenas para web apps que o usuário adicionou à tela inicial (iOS 16.4+), nunca para conteúdo renderizado dentro do WebView de outro app. Um app de tráfego que embute H5 para seus comerciantes, portanto, não pode prometer pareamento Bluetooth, toque NFC nem push confiável a esses comerciantes —não no iOS, e não de forma consistente no Android.
O conserto frágil: uma ponte privada
A saída que as equipes buscam é uma ponte JavaScript —um canal privado, inventado por cada super-app, que deixa o H5 chamar código nativo. Funciona, até não funcionar. Cada host reinventa a roda: um formato de API diferente, uma história de permissões diferente, um modelo de segurança diferente, e uma nova superfície para os problemas de injeção e ataque que esta série já cobriu. As pontes são atualizadas no ritmo do host, não da web, então se desviam da plataforma web documentada e umas das outras. O resultado é uma capacidade que existe, mas fragmentada, ingovernável e impossível de auditar no catálogo de mini-programas que uma plataforma hospeda.
A solução do runtime
Um runtime de propriedade do host substitui a ponte ad hoc por uma API de capacidades padronizada e revisada. Em vez de cada mini-programa negociar um canal privado, o runtime expõe um conjunto consistente de capacidades do dispositivo —Bluetooth, NFC, push, tarefas em segundo plano, câmera, biometria, notificações locais, compartilhamento do sistema— por trás de uma interface única, versionada e com permissões por capacidade que funciona igual em cada plataforma que o host suporta. O host define o que um mini-programa pode solicitar, o usuário concede por capacidade, e a chamada passa por uma rota que a plataforma pode auditar. A capacidade deixa de ser um projeto científico por app e passa a ser um serviço governado.
| Dimensão | WebView | Runtime de propriedade do host |
|---|---|---|
| Alcance nativo | Uma fatia; depende do motor | Uma API de capacidades consistente |
| Bluetooth / NFC | Só Chromium; ausente no iOS WebView | Exposto uniformemente onde o dispositivo permite |
| Push no iOS | Indisponível dentro de um WKWebView | Push nativo via canal do host |
| Modelo de ponte | Privado, por super-app, ingovernável | Padronizado, revisado, por permissões |
| Auditabilidade | Quase nula no catálogo | Uma rota auditada por capacidade |
O fio condutor desta série é o controle. Um WebView deixa você desenhar uma tela, mas não alcançar o dispositivo atrás dela; um runtime deixa você alcançar o dispositivo através de um limite que você define. Para um app de tráfego cujo valor são exatamente as coisas que um telefone sabe fazer —pagar, parear, tocar, notificar— esse limite é o produto.
Fontes
- MDN: Web Bluetooth API — matriz de suporte: Chrome/Edge sim, Safari e WebViews iOS/Android não.
- MDN: Web NFC API — só Chrome no Android e Android WebView; sem Safari no iOS.
- Apple Developer Forums: Web Push indisponível em WKWebView — confirmação DTS de que Web Push não funciona dentro de um WKWebView.
- WebKit: Web Push no iOS exige Add to Home Screen (iOS 16.4+) — push restrito a web apps instalados na tela inicial, não a WebViews dentro de apps.
- MDN/OpenPWA: uso do Web NFC (~35% global, StatCounter 2026) — contexto de uso global do Web NFC.
