Um web app guarda dados de usuário, catálogos offline e rascunhos em localStorage e IndexedDB, tratando o navegador como banco de dados de registro. Dentro de um WebView esse pressuposto quebra: o armazenamento é best-effort, nunca garantido. Sob pressão de armazenamento o navegador purga uma origem inteira de uma vez (LRU); o Safari apaga o armazenamento gravável por script após sete dias sem interação; atualizações e reinstalações do app esvaziam o diretório de dados do WebView; e o conteúdo embutido no WKWebView de outro app fica limitado a cerca de 15 por cento do disco total. Um runtime próprio do host oferece persistência controlada — um armazenamento sincronizado com o servidor, migrações versionadas e uma garantia de durabilidade em que a página pode confiar.
Pressão de armazenamento: a purga de tudo ou nada
Segundo a especificação de armazenamento web, quando um dispositivo fica sem espaço o navegador aplica uma política de menos usado recentemente (LRU) e apaga todos os dados de uma origem de uma vez — IndexedDB e a Cache API somem juntos, não chave por chave. Só são ignoradas as origens com armazenamento persistente via navigator.storage.persist(), e essa concessão depende de sinais de engajamento e frequentemente é um falso silencioso. Para um WebView dentro do app é pior: números medidos mostram que o conteúdo web embutido no WKWebView de outro app recebe apenas cerca de 15 por cento do disco total, contra aproximadamente 60 por cento de um app de navegador autônomo. Um PWA que funciona silenciosamente no Safari quebra dentro da visão embutida.
O apagamento silencioso de sete dias e a armadilha da memória
O Safari purga proativamente o armazenamento gravável por script — localStorage e sessionStorage incluídos — de qualquer site sem interação do usuário nos últimos sete dias de uso do Safari, a menos que esteja instalado na tela inicial. À parte, alguns apps contêiner no iOS deixam o armazenamento de dados do WKWebView na configuração não persistente (em memória), então o localStorage some no instante em que o processo termina ou o app vai para segundo plano. A escrita parece ter sucesso durante a sessão e depois os dados simplesmente não estão lá. Equipes híbridas descobrem rotineiramente tokens e preferências perdidos após uma troca para segundo plano ou uma atualização.
O que você perde quando o armazenamento evapora
- Catálogos offline desaparecem. Listas de produtos e artigos em cache são purgados sob pressão e o app cai em carregamentos.
- Rascunhos perdidos. Formulários pela metade e edições não sincronizadas somem sem aviso.
- Logout silencioso. Tokens guardados em localStorage são apagados, forçando reautenticação no pior momento.
- Migrações quebradas. Uma atualização que esvazia o diretório de dados ou recria o WebView pode prender o usuário entre versões de esquema.
- Sem contrato de durabilidade. O localStorage é síncrono, limitado a cerca de 5 MB por origem, e lança QuotaExceededError — nunca foi banco de dados de registro.
A correção do runtime
Um runtime próprio do host deixa de tratar o WebView como fonte da verdade. Ele oferece um armazenamento sincronizado com o servidor abaixo da página: o estado crítico é persistido nativamente (sobrevive a atualizações, reinstalações e limpezas do SO), espelhado na página ao carregar e migrado com versionamento explícito quando o esquema muda. O H5 mantém a conhecida API com forma de localStorage, mas o runtime garante a durabilidade que o WebView não pode.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Garantia de persistência | Best-effort, nenhuma | Durável, nativa |
| Pressão de armazenamento | Purga de origem inteira | Sincronizada com servidor, segura |
| Atualização / reinstalação | Esvazia dir. de dados | Sobrevive |
| Regra de 7 dias iOS | Apaga armazenamento | Armazenamento nativo isento |
| Cota dentro do app | ~15% do disco | Controlada pelo host |
| Segurança de migração | Frágil | Versionada |
A API de armazenamento de um navegador promete conveniência, não durabilidade. Um WebView padrão tira silenciosamente até essa conveniência. Um runtime transforma a Caixa Amnésica em um armazenamento real — um em que a página pode confiar após atualizações, reinstalações e dias de disco cheio.
Fontes
- MDN — Cotas de armazenamento e critérios de evicção — evicção LRU e a purga de tudo ou nada.
- web.dev — Armazenamento para a web — armazenamento persistente, cotas e boas práticas.
- MDN — Window.localStorage — a API síncrona de 5 MB que nunca foi um banco de dados.
- Apple — WKWebsiteDataStore — a decisão de armazenamento persistente vs não persistente no iOS.
- Android — Mudanças de comportamento no Android 9 (diretório de dados do WebView por processo) — por que o armazenamento é fragmentado e apagado entre processos e reinstalações.
