Aplicação móvel nativa ou multiplataforma?

Segundo a Mesterséges Intelligencia Központ Kft., empresa de desenvolvimento de software de Budapeste, é necessária uma app nativa quando a aplicação usa a fundo o dispositivo; se as duas plataformas têm as mesmas funcionalidades, uma base de código comum é mais simples de manter.

Em resumo: a decisão depende das funcionalidades, não da moda: até que ponto a app tem de aceder ao dispositivo, quanto desempenho exige e quem a vai manter durante anos. Se a presença nas lojas e o acesso profundo ao dispositivo não forem importantes, pode bastar uma aplicação web (PWA). Seja qual for o caminho escolhido, o backend, as regras das lojas e as atualizações regulares dos sistemas operativos representam uma parte significativa do trabalho.

O que significa uma aplicação nativa, multiplataforma e web?

Uma aplicação móvel pode ser desenvolvida de três formas: separadamente para cada plataforma, com as ferramentas próprias da plataforma; a partir de uma base de código comum, compilada para as duas plataformas; ou com tecnologia web, a correr no navegador. Os três caminhos produzem uma aplicação funcional; a diferença está no acesso, na manutenção e em saber de quem são as regras que a app tem de acompanhar nas atualizações.

Aplicação nativa

Numa aplicação nativa, as versões iOS e Android são desenvolvidas separadamente, na linguagem e com as ferramentas de interface próprias de cada plataforma. No iOS, isto significa hoje normalmente a linguagem Swift e o SwiftUI: segundo a Apple, o SwiftUI permite, com uma sintaxe declarativa e com base na linguagem Swift, construir a interface em todas as plataformas da Apple (Apple: SwiftUI). No Android, significa Kotlin e Jetpack Compose: a Google designa o Jetpack Compose como o conjunto de ferramentas moderno recomendado pelo Android para construir interfaces nativas (Android Developers: Jetpack Compose) e recomenda começar as novas aplicações Android com Kotlin (Android Developers: Kotlin-first). A vantagem do caminho nativo é que todas as novas possibilidades da plataforma ficam diretamente disponíveis desde o primeiro dia; a desvantagem é que é preciso desenvolver e manter duas bases de código.

Frameworks multiplataforma

Com os frameworks multiplataforma, a aplicação iOS e a aplicação Android são construídas a partir de uma base de código comum. Quatro abordagens comuns:

Flutter: framework na linguagem Dart. Segundo a documentação, o Flutter implementa ele próprio todos os elementos de interface, em vez de usar os elementos do sistema, e desenha com o motor chamado Impeller; o código próprio da plataforma pode ser chamado através do chamado canal de plataforma (platform channel) (Flutter: Architectural overview).
React Native: baseado em React e JavaScript; nas palavras do próprio projeto, é escrito em JavaScript mas apresentado com código nativo, porque os seus componentes básicos correspondem aos elementos de interface nativos da plataforma (React Native). A partir da versão 0.76, a chamada nova arquitetura (New Architecture) é a predefinida, e substitui a ponte assíncrona pela JavaScript Interface (JSI) (React Native: New Architecture).
Kotlin Multiplatform: tecnologia de código aberto da JetBrains que permite partilhar código entre destinos Android, iOS, desktop, web e servidor. Pode partilhar-se apenas a lógica de negócio, com interface nativa, ou também a interface, com o Compose Multiplatform (Kotlin: Kotlin Multiplatform). Segundo a documentação do Kotlin, o Compose Multiplatform tem o nível estável (Stable) também no iOS (Kotlin: estabilidade das plataformas suportadas, verificado em 17 de outubro de 2026).
.NET MAUI: framework da Microsoft em C# e XAML, com o qual se podem desenvolver aplicações para Android, iOS, macOS e Windows a partir de uma única base de código comum; é a evolução do Xamarin.Forms. Para compilar aplicações iOS e macOS é necessário um Mac (Microsoft Learn: What is .NET MAUI?).

Aplicação web progressiva (PWA)

A PWA é uma aplicação web que corre no navegador, pode ser instalada no ecrã inicial e, graças a funcionalidades que se alargam progressivamente (progressive enhancement), oferece uma experiência mais fiável. Segundo o resumo do web.dev, as aplicações de plataforma são as mais fortes em capacidades e as aplicações web em alcance: uma única base de código chega a qualquer pessoa, em qualquer dispositivo (web.dev: Progressive Web Apps). No iOS e no iPadOS, desde a versão 16.4, uma aplicação web adicionada ao ecrã inicial também pode pedir autorização para notificações push (WebKit: Web Push for Web Apps). Uma limitação importante: segundo o ponto 4.2 das diretrizes da App Store, a aplicação tem de oferecer mais do que um site reembalado, pelo que não vale a pena levar para a loja um site simplesmente embrulhado numa app (Apple: App Store Review Guidelines).

Comparação numa tabela

Critério	Nativa (Swift, Kotlin)	Multiplataforma (Flutter, React Native, KMP, .NET MAUI)	PWA
Desempenho	otimizável diretamente com as ferramentas da plataforma	as partes com muito cálculo podem passar para código nativo	determinado pelo navegador e pela tecnologia web
Acesso ao dispositivo	todas as funcionalidades da plataforma, desde o primeiro dia	através do framework ou de um plugin; uma funcionalidade nova chega mais tarde ou exige código nativo adicional	limitado às interfaces web suportadas pelo navegador
Aspeto e sensação	exatamente os elementos próprios da plataforma	no Flutter, elementos desenhados pelo próprio framework; no React Native, elementos nativos	semelhante a um site, depende do navegador
Partilha de código	nenhuma, duas bases de código separadas	a lógica e, geralmente, também a interface são comuns	uma base de código para todos os dispositivos
Equipa	competências separadas em iOS e em Android	uma equipa, mas também é preciso conhecimento das camadas nativas	uma equipa de desenvolvimento web
Manutenção	duas bases de código acompanham as alterações regulares das plataformas	uma base de código, mais as atualizações próprias do framework	sem publicações na loja; é preciso acompanhar as alterações dos navegadores
Tamanho da aplicação	assenta nas bibliotecas próprias do sistema	o motor do framework também vai dentro da aplicação	sem pacote de instalação; o navegador guarda em cache
Presença nas lojas	sim	sim	não é necessária; se for embrulhada para a loja, aplica-se o limite do ponto 4.2

A documentação do Flutter di-lo explicitamente: o pacote de uma aplicação Flutter é autónomo e contém todo o código e todos os recursos necessários à execução, pelo que o seu tamanho pode ser um fator a considerar (Flutter: Measuring your app's size). Na prática, a diferença raramente é decisiva, mas convém conhecê-la se o público-alvo usar a app em dispositivos mais antigos ou com ligações fracas.

Quando convém cada uma?

Nativa, se

a aplicação usa a fundo o dispositivo: câmara, sensores, Bluetooth, tarefas em segundo plano;
tem grandes exigências de desempenho, por exemplo processamento de imagem ou de som em tempo real, animações complexas;
é preciso tirar partido de imediato das possibilidades mais recentes da plataforma;
só é necessária uma aplicação para uma das plataformas, ou as duas versões diferem substancialmente.

Multiplataforma, se

as duas plataformas têm as mesmas funcionalidades, e é importante que as alterações surjam ao mesmo tempo;
a aplicação é composta sobretudo por formulários, listas, apresentação de dados e notificações, como a maioria das apps empresariais;
uma única equipa mantém a aplicação a longo prazo;
a empresa já usa a linguagem do framework, por exemplo conhecimentos de React na web apontam para o React Native, e uma experiência em .NET para o .NET MAUI.

PWA ou aplicação web, se

os utilizadores não procuram a aplicação na loja, mas chegam a partir de uma ligação ou do site;
não é necessário um acesso profundo ao dispositivo;
a aplicação tem de funcionar da mesma forma no computador e no telemóvel;
as atualizações rápidas, sem revisão da loja, são mais importantes do que as funcionalidades da plataforma.

Também aqui as fronteiras não são nítidas. Com o Kotlin Multiplatform, por exemplo, a lógica de negócio pode ser comum e a interface continuar nativa; no Flutter e no React Native, uma parte crítica pode também ser escrita em código nativo. O jogo do nosso próprio site funciona como aplicação web: corre no navegador sem instalação, da mesma forma no computador e no telemóvel. Do caminho web falamos na página Criação de sites e desenvolvimento de aplicações web.

O backend e o painel de administração

Uma aplicação móvel raramente existe isolada. Assim que tem contas de utilizador, dados partilhados ou notificações, precisa de um servidor por trás: é aí que residem as contas, os dados e as permissões, e é daí que partem as notificações. O backend envia normalmente as notificações push através de um serviço próprio para o efeito; o Firebase Cloud Messaging, por exemplo, é uma solução de mensagens multiplataforma em que um ambiente de servidor de confiança compõe e envia as mensagens para aplicações Apple, Android e web (Firebase: Cloud Messaging).

O painel de administração é a consola de gestão do backend: no navegador, editam-se os conteúdos e gerem-se os utilizadores e as definições, para que as alterações do dia a dia não precisem de um programador. É também aí que ligamos os sistemas existentes da empresa, como um sistema de gestão de clientes, um registo de armazém ou um programa de faturação, para que a aplicação trabalhe com os mesmos dados que o resto da empresa. Se ainda não existir um sistema desses, também o construímos, como software à medida. A decisão entre nativa e multiplataforma não afeta o backend: o mesmo servidor pode servir uma aplicação nativa e uma aplicação feita com Flutter.

Publicação nas lojas: a que prestar atenção em outubro de 2026?

As regras das lojas mudam com frequência, por isso indicamos a data dos pontos abaixo (verificado em 17 de outubro de 2026).

App Store (Apple)

Diretrizes de revisão: as App Store Review Guidelines foram atualizadas pela última vez em 16 de outubro de 2026. Segundo o ponto 2.1, deve ser submetida uma versão completa e pronta para revisão; se a app tiver início de sessão, é preciso fornecer uma conta de demonstração, e o backend tem de estar a funcionar durante a revisão. Segundo o ponto 5.1.1, todas as aplicações têm de incluir uma ligação para a sua política de privacidade e, se a app permitir criar uma conta, tem também de oferecer a eliminação da conta dentro da própria aplicação (Apple: App Store Review Guidelines).
Detalhes de privacidade: no App Store Connect, é preciso declarar as práticas de tratamento de dados da aplicação, incluindo as dos componentes de terceiros integrados (por exemplo, SDK de análise); isto é necessário para submeter tanto aplicações novas como atualizações (Apple: App privacy details).
Requisito de ferramentas de desenvolvimento: desde 28 de abril de 2026, as aplicações carregadas no App Store Connect têm de ser compiladas com o Xcode 26 ou posterior, com o SDK do iOS 26, e desde 9 de setembro de 2026 as aplicações iOS e iPadOS têm de ter como destino, no mínimo, o iOS 13 (Apple: Upcoming requirements).
Conta empresarial: para a inscrição como organização, a empresa tem de ser uma pessoa coletiva e ter um número D-U-N-S, e quem faz a inscrição tem de ter autoridade para vincular juridicamente a empresa (Apple: Enrollment).
Estatuto de comerciante na UE: a Apple pede ao programador que declare se é considerado comerciante nos termos do direito da UE; os contactos dos comerciantes aparecem, na UE, na página da aplicação na loja (Apple: Digital Services Act trader requirements).

Google Play

Nível de API de destino: desde 31 de agosto de 2026, as novas aplicações e as atualizações para telemóvel têm de ter como destino, no mínimo, o Android 16 (nível de API 36); as aplicações existentes têm de ter como destino, no mínimo, o Android 15 (nível de API 35) para continuarem disponíveis para novos utilizadores em dispositivos com versões mais recentes do Android. Com uma prorrogação pedida na Play Console, o prazo é 1 de novembro de 2026 (Android Developers: Target API level).
Testes nas contas pessoais: nas contas de programador pessoais criadas após 13 de novembro de 2023, antes da publicação em produção é obrigatório realizar um teste fechado com, pelo menos, 12 testadores que nele participem continuamente há, pelo menos, 14 dias (Play Console Help: testing requirements).
Conta de organização: não é possível criar uma conta de programador de organização sem um número D-U-N-S (Play Console Help: creating an account).
Formulário de segurança dos dados: tem de ser preenchido para todas as aplicações publicadas no Google Play, mesmo que a app não recolha dados de utilizadores (Play Console Help: Data safety).
Eliminação da conta: se for possível criar uma conta na aplicação, tem de ser possível pedir a eliminação da conta e dos dados associados tanto dentro da aplicação como através de uma ligação web (Play Console Help: account deletion requirements).

Estas regras aplicam-se independentemente da tecnologia: uma aplicação feita com Flutter ou React Native tem de cumprir os mesmos requisitos de API de destino e de SDK que uma nativa, e as atualizações do framework têm de os acompanhar. Recomendamos que a conta de programador pertença à empresa do cliente: assim, a aplicação aparece com o nome da sua empresa, e a ficha na loja também fica com a empresa.

Acessibilidade

Ambas as plataformas funcionam com um leitor de ecrã integrado (o VoiceOver no iOS e o TalkBack no Android) e oferecem interfaces para que as aplicações colaborem com estas tecnologias de apoio (React Native: Accessibility). A documentação do Flutter, por exemplo, recomenda que o leitor de ecrã descreva cada controlo de forma compreensível, que a relação de contraste entre o texto e o fundo seja de, pelo menos, 4,5:1 e que cada elemento tocável tenha, pelo menos, 48×48 píxeis (Flutter: Accessibility). A documentação do Android recomenda as diretrizes do Material Design, a ferramenta Accessibility Scanner e verificações automáticas para detetar problemas (Android Developers: Accessibility).

Isto não é apenas uma boa prática: nos termos da Diretiva (UE) 2019/882, os Estados-Membros têm de aplicar, a partir de 28 de junho de 2025, os requisitos de acessibilidade relativos aos serviços de comércio eletrónico prestados aos consumidores, incluindo os prestados através de aplicações móveis (as regras húngaras assentam na transposição da diretiva); as microempresas que prestam serviços devem ser isentadas (EUR-Lex: Diretiva (UE) 2019/882). Os pormenores relativos às lojas online são tratados no artigo Loja online: plataforma por subscrição ou desenvolvimento à medida?.

Inteligência artificial: no dispositivo ou na nuvem?

Numa aplicação móvel, uma funcionalidade de IA pode correr em dois sítios: no próprio telemóvel ou num grande modelo de linguagem na nuvem, através do backend.

No dispositivo (Apple): a partir do iOS 26, o framework Foundation Models da Apple dá acesso aos modelos concebidos para o Apple Intelligence, que correm no dispositivo e no Private Cloud Compute; pode ser usado para geração de texto, saída estruturada e chamada de ferramentas próprias, mas apenas nos dispositivos compatíveis com o Apple Intelligence (Apple: Foundation Models).
No dispositivo (Android): o Gemini Nano corre no serviço de sistema AICore do Android e está disponível através das interfaces ML Kit GenAI, por exemplo para resumos, revisão de texto, reformulação e descrição de imagens. Segundo a Google, funciona sem ligação à rede e os dados sensíveis permanecem no dispositivo, mas o modelo é limitado pelo limite de tokens e pelo hardware do dispositivo (Android Developers: Gemini Nano).
Na nuvem: os grandes modelos de linguagem da OpenAI (ChatGPT), da Anthropic (Claude) e da Google (Gemini), para tarefas mais complexas (um assistente baseado nos materiais próprios da empresa, processamento de documentos e imagens, resumos). A chave de acesso ao serviço de IA fica no backend, não no telemóvel: assim, não pode ser extraída da aplicação, e a utilização pode ser controlada no servidor.

O modelo que corre no dispositivo é atraente pela proteção de dados e pelo funcionamento offline, mas não está disponível no dispositivo de todos os utilizadores, pelo que convém normalmente concebê-lo em conjunto com uma alternativa na nuvem. A ligação dos modelos é tratada na página Integração de IA.

De que depende a manutenção?

Uma aplicação móvel não fica concluída com a entrega: o seu ambiente está em constante mudança. O trabalho de manutenção é determinado sobretudo por:

Os requisitos dos sistemas operativos e das lojas: a Apple exige versões mais recentes do Xcode e do SDK para os carregamentos, e o Google Play um nível de API de destino mais recente. As datas acima mostram que estes requisitos sobem regularmente.
As alterações às diretrizes das lojas: novas declarações de privacidade, regras de eliminação de contas ou de testes.
As atualizações do framework: numa app multiplataforma, uma mudança de versão principal do Flutter, do React Native ou do .NET MAUI pode implicar trabalho no próprio código e nos plugins utilizados.
Os componentes de terceiros: SDK de pagamento, de mapas e de análise, que também têm os seus requisitos de atualização.
O backend e as integrações: as alterações nas interfaces dos sistemas empresariais ligados e dos serviços de IA.
O número de bases de código: duas aplicações nativas exigem alterações em dois sítios.

Erros comuns

A tecnologia é decidida pelos hábitos da equipa, e não pelas funcionalidades da aplicação.
Não se conta com o backend e o painel de administração, apenas com os ecrãs.
Um site é simplesmente embrulhado numa app, e a loja rejeita-o.
A conta de programador está em nome da empresa de desenvolvimento, e a ficha na loja não pode ser transferida mais tarde.
A eliminação da conta, os detalhes de privacidade ou a conta de demonstração são acrescentados no dia da submissão.
Ninguém é responsável pelas atualizações após a entrega e, depois de uma alteração das regras, a app deixa de estar visível para novos utilizadores.

Perguntas frequentes

Nativa ou Flutter/React Native?

Se a aplicação usar a fundo o dispositivo (câmara, sensores, processos em segundo plano) ou tiver grandes exigências de desempenho, o desenvolvimento nativo é o caminho mais seguro. Se as duas plataformas tiverem as mesmas funcionalidades, uma aplicação com base de código comum, feita com Flutter ou React Native, é mais simples de manter. Com o Kotlin Multiplatform, também é possível uma solução intermédia: lógica de negócio comum, interface nativa. Na primeira consulta, fazemos uma recomendação com base nas funcionalidades concretas.

Quando basta uma aplicação web (PWA)?

Quando os utilizadores chegam a partir de uma ligação ou do site, não é necessário um acesso profundo ao dispositivo, e é importante que a aplicação funcione da mesma forma no computador e no telemóvel. Pode ser instalada no ecrã inicial e também pode enviar notificações push no iOS, mas não dá presença nas lojas, e o leque de funcionalidades do dispositivo depende do navegador.

É preciso um backend?

Quase sempre: assim que a aplicação tem contas de utilizador, dados partilhados ou notificações, precisa de um servidor por trás. A exceção é a aplicação que só guarda dados no dispositivo. Construímos também o backend e o painel de administração, e ligamo-los aos sistemas existentes da empresa.

Quem publica a aplicação nas lojas?

Tratamos nós da publicação: preparamos os materiais da ficha na loja e as declarações de privacidade, submetemos a aplicação e acompanhamos a revisão até ao fim. Recomendamos que a conta de programador pertença à sua empresa; para uma conta de organização, ambas as lojas pedem um número D-U-N-S, pelo que convém obtê-lo atempadamente.

De que depende o custo da manutenção?

Do número de bases de código a manter, da frequência com que mudam os sistemas operativos e os requisitos das lojas, de quantos componentes de terceiros e integrações a app utiliza e de quanta evolução se prevê. O preço do desenvolvimento é calculado a partir do tamanho funcional; o método está descrito na página Preços.

Como podemos ajudar?

Desenvolvemos aplicações iOS e Android: construímos o backend e o painel de administração por trás delas, ligamos a inteligência artificial e acompanhamos o processo até à publicação nas lojas. A decisão entre nativa e multiplataforma é tomada em conjunto, com base nas funcionalidades. Os pormenores do serviço estão descritos na página Desenvolvimento de aplicações móveis.

Medimos o tamanho funcional do desenvolvimento em pontos de função COSMIC (ISO/IEC 19761), e daí resultam a proposta e o calendário. A primeira consulta é gratuita, a pedido assinamos um acordo de confidencialidade (NDA) e, após a entrega, asseguramos também a operação e a manutenção. O código-fonte e os direitos de utilização regem-se pelo contrato. Descreva a sua ideia em poucas frases e entre em contacto connosco.