O que um PWA pode fazer hoje
As Progressive Web Apps (PWAs) agora expõem uma ampla gama de capacidades do dispositivo — notificações push, uso offline, acesso à câmera e a códigos de barras, APIs de arquivos e mais — tornando-as uma alternativa plausível aos apps móveis nativos para muitos casos de uso. Os comentários ponderam esses benefícios contra grandes desvantagens: suporte desigual dos navegadores (especialmente no iOS e em engines não baseadas em Chromium), APIs específicas do Google que não são padrões da web, preocupações de segurança e privacidade, e falhas frequentes de UX e problemas de desempenho. O resultado é uma visão dividida das PWAs como uma forma promissora de contornar o controle das lojas de apps e simplificar o desenvolvimento multiplataforma, ou como uma camada frágil, dependente do navegador, que muitas vezes não consegue igualar apps nativos ou sites tradicionais simples.
Sentimento geral sobre PWAs
- A discussão está fortemente dividida: alguns veem PWAs como a direção certa para apps multiplataforma e uma forma de contornar o controle das lojas de apps; outros as veem como supervalorizadas, frágeis e muitas vezes piores do que apps nativos ou websites simples.
- Os apoiadores destacam menor custo de desenvolvimento (uma base de código, habilidades web), alcance global instantâneo, implantações em quiosques/internas e UX “boa o suficiente” para muitos apps de negócios.
- Os críticos enfatizam comportamento pouco confiável, má UX, inchaço de JS e que muitas PWAs são apenas SPAs superengenheiradas, quando um site simples bastaria.
Suporte de plataforma e política de padrões
- Tema recorrente: muitas das capacidades mostradas dependem de APIs exclusivas do Blink (Web Bluetooth, WebUSB, Shape Detection, Web Share Target, alguns fluxos de Digital Goods).
- Mozilla e Apple rejeitaram explicitamente várias dessas APIs por motivos de segurança, privacidade ou fingerprinting; alguns consideram isso justificado, outros veem como protecionismo em favor das lojas de apps.
- Há a preocupação de que o Google esteja, na prática, definindo “a web” via Chromium, arriscando um monopólio de fato do Chrome; o contra-argumento é que o Chromium é open source e ainda assim limitado por processos de padronização.
- O Firefox abandonou o suporte a PWA/SSB no desktop, o que alguns veem como uma ferida autoimposta.
Capacidades, casos de uso e limitações
- Sucessos concretos: PWAs internas implantadas via MDM/Intune; apps corporativos com uso intensivo de câmera; reprodutores de mídia; configurações no estilo quiosque; leitura de código de barras (com ressalvas).
- Áreas ausentes ou fracas: não há uma API padronizada de calendário (há gambiarras via iCal/CalDAV), acesso ao sistema de arquivos ainda imaturo (especialmente no mobile), Bluetooth/USB/serial limitados ou inconsistentes, e Web Push historicamente ruim no iOS.
- Algumas APIs existem, mas são bugadas ou apenas parcialmente implementadas (por exemplo, vibração no Firefox Android, sistema de arquivos e acesso à câmera em tela cheia no mobile).
Instalação, UX e descobribilidade
- No iOS, o “Add to Home Screen” via a folha de compartilhamento é visto como nada óbvio e escondido; os prompts de instalação do Android são mais fáceis, mas em teoria podem ser abusivos.
- PWAs instaladas por navegador, comportamento inconsistente de ícones (por exemplo, badges do navegador) e falta de suporte a share target no iOS são reclamações recorrentes.
- Muitos usuários preferem abas do navegador a “apps” separados; outros gostam de PWAs como janelas independentes com entradas na barra de tarefas e notificações.
Confiança, monetização e ângulo de negócios
- Argumenta-se que as lojas de apps fornecem uma camada de confiança e pagamento à qual os usuários respondem (especialmente no iOS); PWAs precisam de outros padrões (assinaturas, pagamentos web, APIs de Digital Goods).
- Alguns temem que PWAs sejam um caminho para “ChromeOS em todo lugar”; outros dizem que o problema maior é escapar da taxa de pedágio e do gatekeeping das lojas de apps.