Disseram que um WebView é «grátis» e «sempre está lá». Então você construiu seu checkout, seu cadastro, seu catálogo sobre ele: telas carregadas como documentos do seu servidor, que por sua vez dependem de um SDK de mapas, um serviço de deep link, um SDK de pagamentos, um fornecedor de analítica. Cada um é infraestrutura de outro, e a decisão de preço, disponibilidade e política é de outro. O padrão é anterior ao mobile: quando uma plataforma controla uma capacidade da qual você depende, cedo ou tarde reajusta preços, restringe ou retira. A única pergunta é quando.

O roteiro do rug pull é a norma, não a exceção

Em 2018, o Google reescreveu o preço da Maps API da noite para o dia; apps de entrega e logística que tinham construído toda a pilha de geolocalização sobre ela acordaram com contas 1.400% mais altas, com algumas empresas de corrida saltando de cerca de $30.000 para $450.000 por mês. Em 2016, o Facebook anunciou que o Parse encerraria em um ano, forçando a migração de 600.000+ apps — muitas não se recuperaram. Em 2023, o X (Twitter) encerrou o acesso gratuito à API e todo um ecossistema de empresas construídas sobre ela teve de pivotar ou morrer. Em agosto de 2025, o Firebase Dynamic Links foi descontinuado; todo link clicado desde então retorna 404. Nenhum desses fornecedores era pequeno. Essa é a questão: o tamanho não garante estabilidade, apenas um raio de explosão maior quando a estratégia muda.

Seu WebView multiplica a exposição

Uma função nativa vive dentro do seu binário compilado e assinado — você decide quando ela entra e se continua funcionando. Uma tela WebView é um documento obtido de um servidor a cada sessão, e esse documento só vive enquanto vivem todas as dependências atrás. Se o SDK de mapas reajusta preços, o serviço de links desaparece ou o fornecedor de analítica muda sua API, a tela que o usuário vê pode quebrar ou degradar em silêncio. E você talvez nem saiba qual «grátis» falhou, porque a falha aparece como um azulejo em branco ou um botão morto, não como um alerta vermelho.

A loja é o último ponto único de falha

Mesmo com sua própria pilha perfeita, o canal que entrega seu app é de outro. Em 2025, a aplicação da DSA da UE pela Apple removeu 135.000+ apps em dias por falta de informação de comerciante; no mesmo período, as proibições de conta sob a cláusula 3.2(f) subiram 300% ano a ano, e um app social perdeu seus 200.000 usuários acumulados da noite para o dia ao ser removido. Você não consegue apelar de uma mudança de política rápido o suficiente para salvar um trimestre.

A saída de emergência é um runtime que você controla

Um runtime próprio do host executa seu mini-programa como um componente de primeira parte, assinado e em sandbox. A lógica é entregue em um pacote que você assina e versiona — não em um documento que outro serve. Quando um serviço de terceiros reajusta preços ou desaparece, você troca a integração dentro do seu próprio componente e republica no seu ritmo; o app continua rodando. Você não é refém do roadmap de um fornecedor, porque os fluxos que o usuário mais toca são seus: versionados, auditáveis, recuperáveis.

O trade-off num relance

DimensãoWebView + serviços de terceirosRuntime próprio do host
Onde vive a lógica centralDocumento obtido do servidor por sessãoPacote assinado e versionado que você controla
Exposição a reajuste de preçosAlta — mapas, links, SDK mudam de preço da noite para o diaContida — troca a integração internamente
Exposição a encerramento de serviçoAlta — encerramentos tipo Parse ou FDL quebram fluxosBaixa — o fluxo central roda sem o serviço externo
Tempo de recuperaçãoEsperar o fornecedor, migrar, reenviarMinutos — republica seu próprio componente
Risco de canalA política da loja pode remover o appO app continua rodando; você controla o runtime

Fontes