Construir um aplicativo instalável e resiliente

Instalar o site como aplicativo e fazer o site funcionar sem rede são duas conquistas separadas, e quase todo pedido confunde as duas. O manifesto, que é o cartão de identidade do site, diz o nome, o ícone e o modo como a tela abre. Ele coloca o atalho na tela do celular e para por aí.

Quem decide isso é quem conversa com o agente, ou seja, o assistente de código que executa o pedido escrito. A ordem em que as peças entram, o que fica guardado no aparelho e os ajustes contra o botão cortado saem todos dessa primeira escolha.

PWA quer dizer aplicativo web progressivo: o mesmo site que abre no navegador, com recursos que o aproximam de um aplicativo de loja. Ele exige publicação em endereço seguro, o HTTPS. Um arquivo aberto direto do disco não conta como publicação.

O service worker, que é um porteiro instalado entre a tela e a rede, guarda cópias das páginas e decide o que entregar quando o sinal cai. Ele funciona numa aba comum, sem instalação. Teste visitando conectado e reabrindo sem rede: quem chega pela primeira vez já sem sinal não vê nada, porque nada foi guardado ainda.

Ir para a loja de aplicativos só compensa com um de dois gatilhos. Ou o site precisa de câmera, sensores e biometria, ou a sua venda depende da vitrine da loja. Fora disso, instalar pela web mantém um código só para web, Android e iPhone, e publica correção em segundos, sem esperar a aprovação de terceiro.

A instalação não acontece do mesmo jeito nos dois sistemas, e isso muda o texto da sua tela. No Chrome para Android o próprio navegador oferece a instalação, e o site pode montar o convite dentro da página.

No iPhone e no iPad não existe convite automático. A pessoa precisa abrir o menu de compartilhamento e tocar em Adicionar à Tela de Início, então o site precisa ensinar isso por escrito.

A notificação, que é a mensagem que aparece na tela do celular sem o site estar aberto, segue a mesma regra. No iPhone e no iPad ela só chega depois que a pessoa adicionou o aplicativo à Tela de Início. Quem conta com aviso de pedido pronto precisa pedir essa instalação primeiro.

Cache é a cópia que o aparelho guarda para mostrar sem pedir de novo ao servidor, e a escolha de cache muda por tipo de arquivo. O Workbox, um pacote pronto que monta o service worker para você, traz as três estratégias já escritas, e está em 54% dos sites feitos para celular.

Em Cache First, o aparelho entrega primeiro a cópia guardada. Serve fonte, ícone e imagem que quase nunca mudam: a tela aparece na hora, com o risco de mostrar versão antiga. Network First pergunta ao servidor antes. Serve preço, login e pagamento, porque ali o dado velho custa caro.

A terceira, Stale-While-Revalidate, entrega a cópia guardada e busca a versão nova por trás, para a próxima visita. Serve a foto de perfil e o texto institucional, que aguentam estar um dia atrasados.

O erro mais comum do service worker escrito por agente é aplicar uma estratégia só ao site inteiro. O segundo é guardar o arquivo pelo endereço: você publica a correção, o endereço continua igual, e o cliente segue vendo a tela de ontem. A saída é identificar o arquivo pelo conteúdo, porque conteúdo novo gera identificador novo.

Instalado, o site abre dentro da moldura do celular, e três ajustes de CSS separam um aplicativo de um site encolhido. A altura medida em vh ignora a barra de endereço e faz o bloco de abertura estourar; a unidade dvh acompanha a barra conforme ela some.

O recorte da câmera e a barra de gestos pedem dois passos na ordem. Primeiro escreva viewport-fit=cover na linha de configuração de tela; depois some o recuo que o sistema informa a um espaçamento mínimo seu no botão fixo. Sem o primeiro passo, o segundo devolve zero.

Falta o gesto de arrastar. A regra touch-action: pan-y deixa o carrossel deslizar de lado sem brigar com a rolagem, e overscroll-behavior: contain impede que a lista puxe a tela de trás. O botão cortado aparece no celular do cliente, nunca no seu, então teste num aparelho de verdade.

Cache resolve ler sem rede; gravar sem rede é outro problema, e a resposta chama-se local-first. O dado nasce e mora no aparelho, e sobe para o servidor quando o sinal volta, como um caderno que se copia sozinho ao chegar na loja.

O motor dessa ideia é o CRDT, uma estrutura que funde a edição de duas pessoas sem perguntar qual delas venceu. O Yjs é o mais usado e move editores conhecidos, então é a escolha para quem edita texto a quatro mãos.

Já o Automerge guarda o histórico de quem mudou o quê, e vale quando a auditoria pesa mais que o tempo real.

Quando o aplicativo tem tabelas e regra de negócio, ElectricSQL, Zero e TinyBase colocam um banco de dados dentro do aparelho e cuidam da sincronização. Já o relatório que abre sem rede pede o banco dentro do próprio navegador, e o SQLite Wasm é o padrão leve.

O critério que separa os dois é simples: cache resolve ver, local-first resolve gravar. Numa distribuidora de bebidas, o vendedor que entra em bairro sem sinal consegue mostrar o catálogo de ontem com cache, mas só registra o pedido com local-first. A última caixa vendida duas vezes continua sendo decisão de regra de negócio no servidor.

Antes de pedir o service worker ao agente, escreva qual estratégia vale para cada tipo de arquivo. Cópia primeiro para fonte e ícone, servidor primeiro para dados e pagamento, cópia com atualização por trás para o resto.

Depois publique uma correção pequena e recarregue a página no celular. Se o texto antigo continuar na tela, o cache está preso ao endereço, e não ao conteúdo, e é esse o ajuste a pedir em seguida.

Guia prático: o que uma tela de autoatendimento ensina ao app instalável

Totem de pedido em restaurante é o caso extremo de tela de toque: a pessoa está em pé, com pressa, sem teclado e sem paciência para errar. O template de totem estudado em 07/10/2026 cabe em duas telas e 205 linhas de código, e mostra os acertos e os tropeços que valem para qualquer app instalável.

Os acertos: a tela inicial inteira é o alvo de toque; a barra de ação ocupa de 140 a 160 px de altura; o botão de pagar fica fixo embaixo, perto do polegar, com cerca de 60 px de altura; o cartão encolhe a 95% no instante do toque, o que confirma o gesto sem esperar a rede; a altura usa a unidade que acompanha a barra do navegador; e o fluxo é curto: tocar, escolher categoria, escolher item, pagar.

Os tropeços: o código bloqueia o zoom, o que um totem pode fazer e um site público não deve, porque tira o recurso de quem enxerga pouco. Os rótulos das categorias têm 10 px. A tela inicial é um bloco clicável sem botão, que o teclado e o leitor de tela não alcançam. Os efeitos de passar o mouse não existem no toque. As imagens dos produtos vêm de dois serviços externos, então sem rede a vitrine some, e não há aviso de estado offline. O template ainda usa nome e logo de uma rede real de lanchonetes, o que não se publica com a marca de outro.

A WCAG 2.2 pede alvo de pelo menos 24 por 24 px; para dedo em pé, mire perto do dobro.

Guia prático: botão de instalar nativo, rotas que dispensam o service worker e o manifesto deste portal

O convite para instalar deixou de depender de script próprio: o Chrome testa o elemento <install> e a função navigator.install(), e o Safari 27 passou a aceitar rotas estáticas no service worker. O guia mostra o que cada recurso faz, como o manifesto e o service worker deste portal resolvem atalhos, retomada e páginas sem rede, e o pedido que leva isso a um app de campanha.

Aplicar os recursos ao projeto