Existe uma classe de decepção difícil de nomear. Um usuário abre seu app, toca uma entrada de «recarga», «corrida» ou «seguro», e cai em uma página que claramente não foi feita pela sua equipe. A fonte não encaixa. O scroll trava. Um botão não faz nada por um segundo e a página recarrega. Ele tem que logar de novo, num serviço que não reconhece. Nada falha. Nada dá erro. Mas algo próximo à confiança acabou de quebrar, e você nunca verá nos logs de erro.
Vejo esse padrão há quase uma década, em fintech, mobilidade e apps de conteúdo. As equipes polêm a casca nativa e então entregam o serviço real — o que gera dinheiro — a uma página web embebida. O resultado se lê como «o produto de outra pessoa», e o usuário muitas vezes não distingue onde seu app termina e a outra parte começa. O custo cai em conversão e retenção, não em disponibilidade.
A fenda não é uma. São três, e se empilham.
Onde a costura aparece
Render. Uma página H5 dentro de um webview desenha com seu próprio CSS, suas fontes, sua grade — uma segunda linguagem de design vivendo dentro da primeira. O usuário sente a costura mesmo sem nomeá-la. Um webview é um motor de navegador; não herda seu sistema de componentes nativos, sua tipografia, nem seu movimento. A página está certa, e também é obviamente não sua.
Carregamento. O primeiro paint do H5 depende da rede. Não há pré-carga, não há empacotamento e montagem de ativos antes do toque como faz um runtime. Isso importa porque velocidade não é métrica de conveniência — é um funil. O próprio benchmark do Google descobriu que 53% das visitas móveis são abandonadas quando a página leva mais de três segundos, e as Core Web Vitals (LCP para pintura, INP para resposta) se tornaram a definição compartilhada do «usável». Uma página em webview costuma medir pior que uma aba real: sem cache de isolamento de site, sem as otimizações que o host aplicou ao seu próprio chrome, e um cold start que é pura rede.
Capacidade. Quando o serviço precisa da câmera, localização ou biométrico, o H5 cruza uma ponte JS para um modelo de segurança de navegador que nunca foi desenhado para isso. Algumas chamadas são pouco confiáveis; muitas disparam um diálogo de permissão extra que se lê como aviso. O fluxo se quebra sozinho. Um runtime próprio do host expõe essas capacidades via APIs graduadas e auditadas, então a mesma ação é uma chamada nativa, não uma negociação.
Frente a frente
| Dimensão | H5 embebido (WebView) | Runtime de mini-programa (do host) |
|---|---|---|
| Consistência de render | Seus próprios estilos, visivelmente à parte | Componentes nativos, uma linguagem |
| Primeiro paint | Amarrado à rede, gira seguido | Pré-carregado, quase nativo |
| Capacidade nativa | Bridge limitado, diálogos extras | APIs auditadas, nativas |
| Login | Re-logar em terceiro | Um login do host |
| Sinal de confiança | Lê-se como link externo | Sandbox, aval do host |
| Propriedade de marca | Sente-se «deles» | Sente-se «sua» |
O dano é em parte reputacional. Quando a página embebida trava ou pede re-login, o usuário raramente culpa o terceiro. Culpa seu app. A reseña de uma estrela diz «este app é bugado», não «este serviço embebido é bugado». Você carrega o risco de marca por uma experiência que não construiu e não pode consertar por completo.
Um runtime fecha a costura pelo outro lado. Os serviços renderizam com componentes nativos e uma linguagem de design compartilhada, então parecem — e se comportam — como parte do seu produto. Os ativos são montados antes do toque, então o primeiro paint não espera a rede. As capacidades vêm do host, então a câmera abre como no resto do seu app. E como o runtime é sandbox e avalado pelo host, o instinto do usuário é «isso é parte do app», que é exatamente o instinto que você quer.
Dou a ressalva honesta. Um runtime não é a cura milagrosa para um mau produto. Seus componentes nativos traem restrições — você não joga qualquer biblioteca web arbitrária — e o sandbox que compra confiança é, por definição, um conjunto de limites. O que o runtime realmente faz é tirar o imposto de experiência que você pagava na porta: evita que você perca o usuário no momento do toque, antes do seu serviço ter a chance de se provar.
Esse é o argumento mais quieto a favor do runtime. Não «construa um super-app». Só: não deixe a tela mais importante do seu app parecer de outra pessoa.
