Você acha que um usuário logado é um usuário logado. Então ele toca em uma tela WebView e é pedido a fazer login de novo. Ou ele enche um carrinho dentro do WebView, volta para a carcaça nativa e o carrinho sumiu. A fronteira entre seu código nativo e o documento remoto não só deixa as coisas lentas — ela elimina silenciosamente identidade e estado.
A fronteira que esquece
Um WebView armazena seus cookies e armazenamento local na área de dados privada do app host, não no navegador do sistema. Um navegador externo não consegue ler esse armazenamento privado, então abrir um link significa um login novo. Mesmo dentro do app, um navegador in-app se comporta como uma janela de navegação anônima nova que esquece tudo ao fechar. Um usuário que fez login via Safari e chega à sua página pelo Instagram aparece como visitante anônimo, e a sessão criada lá não retorna. As consequências documentadas são diretas: paredes de login convertem muito pior em tráfego in-app, o conteúdo do carrinho e as preferências não transitam, e o analytics conta uma pessoa como várias.
Se você colocar o WebView em seu próprio processo — uma correção comum de estabilidade — o problema endurece. Cookies, estado de login e armazenamento local ficam no processo WebView; a carcaça nativa precisa sincronizá-los explicitamente ou simplesmente não são compartilhados.
O colapso dos cookies de terceiros piorou
A morte lenta do rastreamento entre sites elevou a aposta. O Safari começou a bloquear cookies de terceiros por padrão em 2017 com o Intelligent Tracking Prevention; o Firefox seguiu em 2019; o Chrome anunciou a eliminação em 2020, depois recuou e encerrou a maioria das APIs do Privacy Sandbox até outubro de 2025. Em 2025, cerca de 47% do tráfego web já estava sem cookies. Para um app que depende de WebView, isso significa que as frágeis pontes que antes costuravam a identidade entre contextos estão sendo puxadas de sob seus pés, e o analytics que dependia delas agora reporta visitantes novos fantasmas.
Uma superfície de fraude e risco que você não assinou
Navegadores embutidos que isolam cookies e armazenamento local fazem mais do que irritar usuários. A análise da Fingerprint mostra que fragmentam sessões e enfraquecem a atribuição, e abrem brechas para fraude: atacantes podem limpar estado, trocar de contexto ou usar dispositivos manipulados enquanto percorrem fluxos de onboarding, checkout ou promoções. A questão de governança deixa de ser conveniência do navegador e passa a ser se os controles de identidade e risco conseguem sobreviver à troca de contexto dentro do seu próprio app. A recomendação dessa análise é o instinto certo: persista o vínculo entre usuário, dispositivo e jornada em um sistema backend governado, não em cookies ou armazenamento local que uma fronteira WebView pode apagar.
O que um runtime de primeira parte muda
Um runtime próprio do host executa o mini-programa como um componente assinado e de primeira parte, com identidade e estado geridos pelo host em vez de abandonados na fronteira do documento. A carcaça nativa e o runtime compartilham uma única âncora de identidade governada, então um login feito uma vez é honrado em todos os lugares, e um carrinho ou progresso sobrevive à mudança entre telas. A continuidade de identidade deixa de ser uma aposta entre contextos e passa a ser uma propriedade da plataforma que você controla.
| Cruzamento de estado | WebView padrão | Runtime próprio do host |
|---|---|---|
| Login nativo → WebView | Reperguntado; armazenamento privado não compartilhado | Uma única âncora de identidade governada |
| Carrinho WebView → nativo | Perdido na fronteira | Sobrevive entre telas |
| Identidade entre contextos | Fragmentada, lacuna sem cookies | Persistida no backend, não em cookies |
| Resiliência a fraude | Limpeza de estado fácil, âncora fraca | Vínculo de identidade durável, ciente do risco |
