App nativo, híbrido ou PWA: qual escolher na empresa

A discussão sobre nativo, híbrido ou PWA costuma começar pela tecnologia que o fornecedor domina ou pela que está em alta. Ela deveria começar por outra pergunta: o que esse app precisa fazer no aparelho, para quem, e por quanto tempo alguém vai mantê-lo.

As três abordagens resolvem bem problemas diferentes. Escolher errado raramente aparece no lançamento; aparece meses depois, quando o app precisa ler um coletor Bluetooth no iPhone, enviar localização com a tela desligada ou passar pela revisão da loja com prazo apertado. Este texto organiza a decisão pelos critérios que pesam na prática.

A pergunta certa: o que o app precisa fazer no aparelho

Antes de falar em tecnologia, liste as capacidades que o app usa. Algumas são triviais em qualquer abordagem; outras decidem a escolha sozinhas.

A tabela é uma simplificação: navegadores e sistemas operacionais mudam, e cada item merece verificação na época do projeto. Mas ela mostra o padrão. Quanto mais o app depende do hardware e do segundo plano, mais ele se afasta do PWA.

App interno da equipe ou app para clientes

O público muda os critérios.

App interno (vendedores, técnicos, motoristas, operadores): a empresa controla quem instala e, às vezes, os aparelhos. Visual sofisticado importa menos; confiabilidade, offline e integração com hardware importam mais. A distribuição pode ser privada, sem passar pela vitrine pública das lojas.

App para clientes: o usuário escolhe se instala, compara com apps de grandes empresas e desinstala na primeira frustração. Presença nas lojas costuma importar para descoberta e confiança. Desempenho, acabamento e acessibilidade pesam mais.

Há também o caso em que não precisa de app. Se o cliente usa o serviço duas vezes por ano, pedir que ele instale algo é uma barreira. Um site bem feito, responsivo e rápido resolve, e um PWA pode ser o meio-termo.

O que um PWA faz bem, e onde esbarra no iOS

Um PWA (Progressive Web App) é um site que pode ser instalado na tela inicial, abre em tela cheia e funciona offline por meio de um componente chamado service worker, que intercepta as requisições e responde com dados guardados.

Onde o PWA brilha:

• Um só código para web, Android e iOS, publicado sem loja.
• Atualização instantânea: publicou no servidor, todos recebem.
• Sem barreira de instalação: o usuário abre um link e já usa.
• Custo de manutenção menor, porque não há versões antigas presas em aparelhos.

Onde ele esbarra:

• No iOS, a instalação é manual e pouco conhecida pelo usuário: é preciso usar a opção de adicionar à tela de início pelo navegador. Não há o convite de instalação que o Android oferece.
• Push no iOS funciona apenas para PWAs adicionados à tela de início, e depende de o usuário conceder a permissão depois disso.
• Segundo plano é limitado. Não há GPS contínuo com o app fechado, e a sincronização em segundo plano não é suportada em todos os navegadores. O app sincroniza quando está aberto.
• Hardware. Bluetooth e NFC pela web existem em alguns navegadores no Android, mas não no iOS. Impressora térmica, coletor e balança via Bluetooth, no iPhone, praticamente decidem contra o PWA.
• Armazenamento local pode ser limpo pelo sistema em certas condições, especialmente em sites não instalados. Para offline crítico, isso exige cuidado extra com sincronização e aviso ao usuário.

Um PWA é uma ótima escolha para portais de cliente, painéis, formulários e apps internos simples com uso majoritário em Android. É uma escolha arriscada quando o app vive de hardware, segundo plano ou offline prolongado em iPhones.

Nativo ou híbrido com React Native e Flutter

Nativo significa desenvolver separadamente para cada plataforma: Kotlin para Android e Swift para iOS. Acesso total e imediato a tudo que o sistema oferece, melhor desempenho possível, e dois códigos para manter, com duas equipes ou pessoas que dominem ambos.

Híbrido, aqui, significa frameworks multiplataforma como React Native e Flutter: um código só gera apps para Android e iOS. Não confunda com os antigos apps que eram só um site dentro de uma moldura; os frameworks atuais produzem interfaces com desempenho próximo ao nativo para a grande maioria dos apps de negócio.

Na prática, para apps corporativos:

• Híbrido é o ponto de partida mais comum. Um código, uma equipe, e acesso ao hardware por módulos nativos, prontos ou escritos sob medida quando necessário.
• React Native aproveita o ecossistema JavaScript e TypeScript, o que ajuda quando a empresa já tem web nessa linguagem e quer compartilhar regras e validações.
• Flutter tem renderização própria e consistência visual entre plataformas, com a linguagem Dart.
• Nativo se justifica quando o app é intensivo em um recurso específico da plataforma (processamento de câmera em tempo real, áudio, integrações de sistema profundas), quando o desempenho é o diferencial do produto, ou quando a empresa já tem equipes nativas.

Mesmo num app híbrido, algumas partes serão nativas: um driver de impressora, um serviço de localização em segundo plano. Isso é normal e deve estar previsto.

Os apps de campo que descrevemos no blog são bons exemplos do critério: o app de força de vendas offline e o app de ordem de serviço para técnicos de campo dependem de banco local robusto, câmera e, às vezes, impressora, o que costuma apontar para híbrido. O app de entregas com comprovante digital adiciona localização em segundo plano, o que reforça a mesma direção.

Lojas de aplicativos: publicação, revisão e distribuição privada

Publicar na Google Play e na App Store tem implicações que entram no cronograma e na operação:

• Contas de desenvolvedor em nome da empresa, não do fornecedor. O app é um ativo seu.
• Revisão. Toda versão passa por revisão, mais rigorosa na Apple. Rejeições acontecem por detalhes de política, textos de permissão, conta de teste ausente ou funcionalidade considerada incompleta.
• Políticas de privacidade declaradas nas lojas, coerentes com o que o app coleta e com a LGPD.
• Justificativa de permissões sensíveis, como localização em segundo plano, que exigem explicação e às vezes demonstração em vídeo.

Para apps internos, há caminhos de distribuição privada: publicação restrita à organização pela Google Play gerenciada, distribuição de apps personalizados pelo programa empresarial da Apple ou instalação por gestão de dispositivos móveis quando a empresa fornece os aparelhos. Cada caminho tem requisitos de elegibilidade e processo próprios, e a escolha deve ser feita no início, não na véspera do lançamento.

Atualizações, versões antigas e manutenção de longo prazo

O custo de um app não termina no lançamento. Três fatores pesam na manutenção:

Versões antigas em campo. Com apps de loja, nem todo mundo atualiza. O servidor precisa conviver com várias versões e ter um mecanismo para exigir atualização quando uma versão antiga deixa de ser compatível. No PWA, esse problema praticamente não existe.

Atualização dos sistemas operacionais. Android e iOS lançam versões novas todo ano, com mudanças de permissão, de API e de requisitos das lojas. As lojas exigem periodicamente que os apps sejam recompilados com versões recentes das ferramentas. Um app sem manutenção acaba removido ou bloqueado para novas instalações.

Dependências do framework. React Native e Flutter evoluem rápido, e bibliotecas de terceiros acompanham em ritmos diferentes. Atualizar com regularidade é mais barato do que pular várias versões de uma vez.

Alguns frameworks permitem atualizar partes do app sem nova publicação na loja, dentro das regras das lojas. Isso ajuda em correções rápidas, mas não substitui o ciclo normal de versões.

Um roteiro de decisão em cinco perguntas

1. O app precisa de hardware ou segundo plano? Bluetooth, NFC, GPS com a tela desligada, sincronização com o app fechado. Se sim, descarte o PWA, especialmente se houver iPhones.
2. O público é interno ou externo? Interno tolera distribuição privada e visual simples; externo pede loja, acabamento e presença.
3. Com que frequência o usuário usa? Uso esporádico favorece web e PWA; uso diário justifica app instalado.
4. Quanto offline ele precisa? Algumas telas em cache cabem num PWA; um dia inteiro de trabalho sem sinal pede banco local num app instalado.
5. Quem mantém nos próximos anos? Um código multiplataforma é mais fácil de manter com uma equipe pequena. Dois códigos nativos exigem mais gente.

Para boa parte dos apps de negócio, a resposta tende a cair em híbrido para apps instalados e web responsiva ou PWA para portais e uso esporádico. Nativo puro fica para casos específicos. Mas o roteiro vale mais que a regra geral, e o caso do app offline para registro de campo no agro mostra como a conectividade sozinha pode definir a escolha.

Erros comuns

• Escolher pela tecnologia que o fornecedor domina, não pelo que o app precisa fazer.
• Prometer PWA com Bluetooth ou GPS em segundo plano no iPhone.
• Publicar nas contas do fornecedor em vez das contas da empresa.
• Ignorar a revisão da loja no cronograma.
• Não prever convivência de versões entre app e servidor.
• Tratar o lançamento como fim, sem orçamento de manutenção para as mudanças anuais dos sistemas.

A escolha certa começa pelo uso

A Pervian Tech desenvolve apps nativos, híbridos e PWAs no nosso trabalho de desenvolvimento mobile, e a escolha da abordagem é consequência do que o app precisa fazer, não uma preferência nossa. Cada projeto é sob medida, com a integração aos sistemas que a empresa já usa.

Começamos por um diagnóstico inicial gratuito: quem vai usar, em que aparelhos, com que conectividade e quais capacidades do dispositivo entram no fluxo. Dali saem a recomendação de abordagem, as fases do projeto e o investimento, que é sob consulta. Se você está nessa decisão, descreva o app que precisa.