App nativa, multiplataforma ou PWA: qual escolher?

Quem vai desenvolver uma aplicação móvel enfrenta cedo uma decisão técnica que parece detalhe de programadores mas condiciona orçamento, prazo e futuro do produto: app nativa (Kotlin no Android, Swift no iOS), app multiplataforma (Flutter ou React Native) ou PWA (uma aplicação web instalável). Não existe uma resposta universal. Existe a resposta certa para o seu caso, que se encontra com meia dúzia de perguntas.

Neste artigo explicamos o que cada abordagem é, onde cada uma se destaca, onde falha, e damos um critério de decisão prático. Falamos de experiência com projetos reais, mas sem promessas de ganhos que não possamos demonstrar.

As três abordagens em resumo

App nativa (Kotlin e Swift)

Escreve-se uma aplicação para Android (normalmente em Kotlin, com Jetpack Compose para a interface) e outra para iOS (em Swift, com SwiftUI). Cada uma usa diretamente as ferramentas e interfaces do sistema operativo. É a abordagem com acesso mais direto e imediato às novidades de cada plataforma.

Exemplo do nosso portefólio: o Park France é uma aplicação de estacionamento em Kotlin e Jetpack Compose, construída sobre dados abertos públicos.

Multiplataforma (Flutter e React Native)

Escreve-se uma base de código principal que gera aplicações para Android e iOS.

• O Flutter, da Google, é de código aberto, usa a linguagem Dart e permite, a partir de uma só base de código, apps para Android, iOS, web e desktop. Em vez de usar os componentes do sistema, desenha a interface com o seu próprio motor gráfico (o Impeller), o que garante aparência e comportamento consistentes entre plataformas. Quando é necessário um componente nativo, como um mapa, pode ser incorporado.
• O React Native, mantido pela Meta, usa JavaScript e React, e cada componente (View, Text, Image) corresponde a um elemento de interface nativo da plataforma. O site oficial recomenda usar uma framework como o Expo para novos projetos.

Exemplos nossos em Flutter: a PDF Nova para Android (digitalizador, OCR, edição, assinaturas e proteção AES-256), a Flash-Destock (marketplace de ofertas locais) e o Cachet (faturas e orçamentos offline).

PWA (Progressive Web App)

É um site (ou aplicação web) que pode ser instalado no ecrã inicial, funcionar parcialmente sem ligação e enviar notificações. Não passa pelas lojas e funciona com a mesma base de código em qualquer navegador moderno.

A documentação web.dev descreve as limitações práticas: no iOS e iPadOS não existe um pedido de instalação do navegador, o utilizador tem de usar manualmente "Adicionar ao ecrã principal" no menu Partilhar; só o modo "standalone" é suportado, e funcionalidades como badges e atalhos não estão disponíveis. No Android, a experiência varia consoante o dispositivo e o navegador. No Safari em macOS, a instalação não é suportada.

Comparação direta

A coluna de custo é qualitativa de propósito. Os custos concretos dependem do âmbito, e discutimo-los em quanto custa desenvolver uma aplicação móvel em Portugal.

Quando uma app nativa faz sentido

• Precisa de funções muito específicas do sistema: processamento de áudio ou vídeo em tempo real, realidade aumentada, integração profunda com Bluetooth, widgets, relógios, carros.
• O desempenho gráfico é crítico e quer o máximo controlo.
• O produto é só para uma plataforma, por exemplo, uma ferramenta interna para equipas com dispositivos Android.
• Quer adotar as novidades do iOS ou Android no dia em que saem, sem esperar pelo suporte de uma framework.

O custo: se precisar de iOS e Android, mantém duas bases de código, duas equipas ou competências, e cada funcionalidade é implementada duas vezes. Para equipas pequenas, é um peso considerável.

Quando o multiplataforma é a melhor escolha

Na maioria dos projetos de negócio (marketplaces, aplicações de faturação, portais de cliente, apps de serviços), as funcionalidades são ecrãs, listas, formulários, pagamentos, notificações e câmara. Tudo isso está bem coberto por Flutter e React Native. As vantagens:

• Uma só implementação das regras de negócio e dos ecrãs.
• Lançamento nas duas plataformas ao mesmo tempo, com comportamento consistente.
• Menor custo de manutenção: uma correção chega aos dois sistemas.

Flutter ou React Native?

Não há vencedor absoluto. Critérios práticos:

• A equipa já domina JavaScript e React? O React Native reaproveita competências e, por vezes, código de uma aplicação web em React.
• Quer uma interface idêntica nas duas plataformas, com muito controlo visual? O Flutter desenha tudo ele próprio, o que dá consistência e facilita animações personalizadas.
• Precisa de componentes nativos do sistema com a sua aparência exata? O React Native mapeia para elementos nativos.
• Planeia a mesma base de código para web e desktop? O Flutter suporta essas plataformas, ainda que a maturidade varie por alvo.

Escolhemos o Flutter nos nossos projetos móveis porque a combinação de uma base de código, interface consistente e bom desempenho se adequa ao tipo de produto que construímos. Isso não faz dele a escolha certa para todos. Uma equipa web experiente em React pode justificadamente preferir o React Native.

O que o multiplataforma não resolve

Não elimina o trabalho de design para cada plataforma, os testes em dispositivos reais, o processo de publicação em duas lojas nem a manutenção. Também não remove a dependência da framework: se mudar de rumo, a migração é custosa. Vale a pena confirmar que a tecnologia é mantida por uma organização com compromisso de longo prazo (neste caso, a Google no Flutter e a Meta no React Native, com apoio de um ecossistema de empresas).

Quando uma PWA basta

Uma PWA é muitas vezes a resposta certa, e subestimada. Considere-a se:

• O produto é sobretudo conteúdo ou formulários (catálogo, reservas, portal de cliente).
• Não precisa de estar nas lojas, ou os seus utilizadores chegam por link, e-mail ou pesquisa.
• Precisa de atualizar rapidamente, sem esperar por revisões das lojas.
• O orçamento é limitado e quer validar a procura.
• A parte iOS não depende de funcionalidades que a PWA não suporta.

Atenção às limitações já referidas: no iOS a instalação é manual, e a experiência "como app" é mais limitada. Se parte importante dos seus clientes usa iPhone e depende de notificações, atalhos ou integração profunda, teste antes de decidir.

Um exemplo de aplicação web de alto desempenho que não passa pelas lojas: a PDF Nova tem 45 ferramentas de PDF em que as principais correm no navegador, com WebAssembly, sem enviar ficheiros para um servidor. Mostra o que a plataforma web consegue quando o problema se adequa. Falamos de projetos assim na nossa página de desenvolvimento de aplicações web.

Um critério de decisão em cinco perguntas

1. Precisa de uma função do telemóvel que a web não oferece bem? (Bluetooth avançado, processamento em segundo plano, widgets, ligação a sensores.) Se sim, descarte a PWA.
2. Precisa das duas plataformas, e o orçamento é limitado? Se sim, favoreça o multiplataforma.
3. A experiência tem requisitos gráficos ou de integração extremos? Se sim, considere nativo, pelo menos nessa parte.
4. A equipa e a manutenção futura: quem vai manter o código daqui a dois anos? Escolha uma tecnologia com talento disponível.
5. Qual é o risco de a ideia não funcionar? Se for alto, valide primeiro com uma PWA ou um MVP em multiplataforma, e só depois invista mais.

Pode também combinar: uma aplicação multiplataforma com módulos nativos para as peças que o exigem, ou uma PWA como primeira versão e uma app em lojas na fase seguinte.

Erros frequentes na decisão

• Escolher pela moda. A tecnologia certa depende do produto, não da popularidade.
• Ignorar a manutenção. Qualquer abordagem exige atualizações regulares do sistema operativo e das bibliotecas.
• Prometer "um código para tudo" sem custos. O ganho é real, mas não é de 100%.
• Esquecer a conta de programador. Para publicar nas lojas, precisa de contas de programador (a Apple cobra 99 USD por ano e a Google, 25 USD uma única vez), e deve estar em nome da sua empresa.
• Não testar em dispositivos reais. Emuladores não substituem telemóveis antigos, ecrãs pequenos e ligações fracas.

Perguntas frequentes

O Flutter é mais rápido do que o React Native?

Não conseguimos citar uma comparação independente que sustente uma resposta universal, e o desempenho depende muito de como cada aplicação é construída. Ambos são usados em produção em aplicações de grande escala. Para a maioria das aplicações de negócio, a diferença não é o fator decisivo; a qualidade da implementação conta mais.

Uma app multiplataforma é "menos nativa"?

Depende da definição. O Flutter desenha a sua própria interface; o React Native usa componentes nativos. Em ambos os casos, o utilizador final raramente nota a diferença se o trabalho for bem feito.

Posso começar por uma PWA e migrar para app mais tarde?

Sim, e é uma estratégia sensata. A lógica de negócio e o servidor reaproveitam-se. A interface terá de ser refeita ou adaptada.

Qual é mais barato?

Em regra, PWA, depois multiplataforma, depois nativo para duas plataformas. Mas só um orçamento com âmbito definido o confirma.

A App Store e a Google Play aceitam qualquer uma destas?

Sim, aplicações nativas e multiplataforma são publicadas nas lojas, sujeitas às regras de cada uma. Uma PWA, em geral, não é distribuída por esse canal.

Conclusão

A melhor abordagem é a que serve o seu produto e o seu orçamento: nativa quando o sistema operativo é o centro do produto, multiplataforma quando quer chegar a Android e iOS com uma equipa e uma base de código, PWA quando a web basta e a rapidez conta. Em dúvida, comece pequeno e valide. Se quiser ajuda a decidir, veja o nosso serviço de desenvolvimento de aplicações móveis ou fale com a equipa.