Publicar uma função via H5 em um WebView é como uma porta dos fundos: você muda o H5 no servidor e a função entra sem revisão da App Store. Essa «porta dos fundos» é uma mina. No momento em que o H5 muda o que o app faz —ou faz ponte para o nativo de um jeito que a loja nunca revisou— tanto a Apple quanto o Google podem remover o app, e reincidentes podem perder a conta de desenvolvedor. A velocidade que a equipe queria vira o risco que derruba todo o app.
A regra que ambas as lojas realmente aplicam
A diretriz 2.5.2 das App Store Review Guidelines da Apple é direta: os apps devem ser autocontidos e «não poderão baixar, instalar ou executar código que introduza ou altere funções ou funcionalidades». JavaScript interpretado só é permitido se for empacotado, não baixado. A própria orientação da Apple é que o React Native está ok porque seu JS conversa com um conjunto fixo de pontes nativas revisadas; o que não está ok é baixar novo código de ponte nativa após a aprovação. A política de Abuso de dispositivo e rede do Google Play diz que um app não pode baixar código executável (dex, JAR, .so) de fora do Google Play —com uma exceção para código interpretado em uma VM/interpretador como JavaScript em um WebView, mas só se esse código «não permitir violações potenciais» das políticas do Play.
A armadilha da hot-update H5
A armadilha é precisa. O H5 dentro de um WebView é a única saída sancionada para entregar JavaScript pelo ar —então as equipes o usam para lançar funções, corrigir bugs e experimentar sem revisão. Mas a concessão é estreita: o JS não pode mudar o propósito principal do app, não pode criar uma «loja dentro de uma loja», e não pode fazer ponte para capacidades nativas que a loja nunca revisou. Sair dessa linha —uma nova ponte nativa, um script remoto não confiável, uma função que muda materialmente o comportamento— e o mesmo WebView que te deu velocidade agora te expõe à diretriz 2.5.2 (Apple) e ao Abuso de dispositivo e rede (Google). Pior ainda, uma hot-update H5 pura não tem porta de versão nem segurança de rollback, então um envio errado fica ao vivo para todos até você consertar o servidor.
Por que isso é um risco real, não teórico
Não é hipotético. A linha dura da Apple contra injeção de código foi construída em grande parte em resposta ao JSPatch, um framework muito usado na comunidade de desenvolvedores chinesa para entregar mudanças de código nativo sem revisão; a Apple o proibiu e reforçou a varredura estática de frameworks de hot-patching após 2024 —a ponto de um SDK JSPatch não usado poder provocar rejeição. A escada de escalada é íngreme: rejeição, depois remoção do app da venda, depois perda da conta do Programa de Desenvolvedores. A política do Google deixa claro que um WebView que carrega conteúdo web não confiável via JavaScript Interface adicionado é um padrão marcado. Para um app de tráfego que hospeda centenas de mini-programas de comerciantes, o H5 de um único comerciante que cruza a linha pode arrastar todo o app —e a conta da plataforma.
A solução do runtime
Um runtime de propriedade do host oferece um canal de atualização controlado em vez de uma aposta de conformidade. A lógica e os recursos ainda são atualizados pelo ar e rápido, mas cada atualização passa por uma porta de revisão da plataforma, entra com lançamento gradativo e rollback instantâneo, e é assinada e verificada antes de executar. O negócio mantém a velocidade das hot-updates; a plataforma mantém a trilha de auditoria, o kill switch e o limite conforme à loja. Você ganha a velocidade sem apostar o app.
| Dimensão | Hot-update H5 em WebView | Runtime de propriedade do host |
|---|---|---|
| Revisão da loja | Contornada; risco de remoção | Porta de atualização dentro de limite conforme |
| Mudanças de ponte nativa | Não revisadas; violam 2.5.2 / Abuso de dispositivo e rede | API de capacidades revisada e versionada |
| Rollback | Nenhum; conserta o servidor para todos | Lançamento gradativo + rollback instantâneo |
| Raio de blast | Todo o app e a conta em risco | Isolado por mini-programa |
| Trilha de auditoria | Nenhuma | Assinada, verificada, registrada |
O fio condutor desta série é o controle. Um WebView deixa você atualizar rápido e sem vigilância; um runtime deixa você atualizar rápido e responsavelmente. Para uma plataforma cujo catálogo é código de terceiros, a velocidade responsável é a única que sobrevive a uma revisão da loja.
Fontes
- Apple App Store Review Guidelines — 2.5.2 — apps não podem baixar nem executar código que mude funções; código interpretado empacotado permitido.
- App Store Reject: diretriz 2.5.2 injeção de código / hot-patching — criada em grande parte por JSPatch; React Native aceitável, código de ponte nativa dinâmico não.
- Apple DTS / comunidade: JSPatch proibido; varredura estática reforçada após 2024 — até um SDK de hot-patching não usado pode provocar rejeição; escalada até perda de conta.
- Google Play: política de Abuso de dispositivo e rede — sem código executável fora do Play; JS em WebView permitido só se não violar políticas; WebView + JS Interface não confiável marcado.
- Axonbuild: reportagem de março de 2026 ligou a aplicação da 2.5.2 a produtos de construção de apps — HTML5/JS não embutido pode trazer a diretriz 4.7 à análise.
