Desenvolvimento mobile cross-platform em 2026: um único código para iOS e Android

Desenvolvimento mobile cross-platform significa escrever um único código que corre em iOS e Android, e muitas vezes também na web, em vez de uma app em Swift para iPhone e outra em Kotlin para Android. Em 2026 já não é um compromisso reservado a protótipos: os dois frameworks mais usados, Flutter e React Native, fazem funcionar apps da Google, da Meta, da Microsoft e da Shopify, e uma terceira abordagem, Kotlin Multiplatform, é agora suficientemente estável para que a Google a recomende às equipas Android.

A verdadeira pergunta mudou de sítio. Já não é «cross-platform ou nativo?» mas «que cross-platform, para que equipa?». As quatro famílias desenham o ecrã de quatro formas diferentes, e esse único facto decide o aspeto, o desempenho, a bolsa de recrutamento e a manutenção que assina. Este guia põe-nas lado a lado, com números onde existem números, e depois dá-lhe um caminho de decisão.

O que cross-platform significa em 2026

Os dados de adoção mais fiáveis vêm do Stack Overflow Developer Survey, que pergunta a cerca de 45 000 programadores que frameworks usaram no último ano. Os frameworks mobile são uma pequena fatia de todos os programadores, mas a classificação dentro dessa fatia é estável.

Kotlin Multiplatform não está nessa lista, porque o inquérito não o oferecia como opção. Conta na mesma: a JetBrains lançou o Compose Multiplatform 1.8 em maio de 2025, que tornou estável a sua interface partilhada para iOS, e a Google apoiou a abordagem para partilhar lógica de negócio entre Android e iOS.

Três coisas mudaram desde a última vez que talvez tenha olhado para isto. React Native removeu o velho bridge assíncrono com a New Architecture, que passou a ser a predefinição de todo o ecossistema com a versão 0.85, em abril de 2026. Flutter substituiu o motor de renderização pelo Impeller. E a abordagem da web encapsulada dividiu-se em duas: progressive web apps que dispensam as lojas por completo, e invólucros como o Capacitor que colocam uma app web numa ficha de loja. Se a sua lista já está reduzida aos dois líderes, o nosso frente a frente React Native ou Flutter aprofunda essa escolha específica.

Quatro famílias, quatro formas de desenhar um píxel

Os nomes escondem a diferença importante, que é aquilo em que o seu código se transforma no dispositivo.

React Native, com Expo

Os seus componentes React tornam-se verdadeiras views nativas: um controlo UIKit no iOS, uma View Android no Android. A app tem o aspeto e o comportamento da plataforma porque está a usar a plataforma. A bolsa de talento é a maior das quatro, já que qualquer programador JavaScript ou TypeScript pode contribuir, e a própria equipa do React Native recomenda agora começar com o framework Expo, que acrescenta navegação, uma biblioteca padrão de APIs do dispositivo e builds na cloud. Explicamos essa camada em O que é o Expo?.

Flutter

Flutter faz a aposta contrária. Não usa widgets nativos de todo: o seu motor Impeller desenha cada píxel por conta própria, por isso a app fica idêntica nas duas plataformas e um design à medida é barato de construir. O preço é o Dart, uma linguagem que a sua equipa provavelmente terá de aprender, e uma interface que só segue as convenções da plataforma na medida em que a biblioteca de widgets do Flutter as imita. A Google reportou mais de um milhão de apps lançadas com Flutter já em 2023.

Kotlin Multiplatform

O KMP partilha as partes que os utilizadores nunca veem: rede, modelos de dados, regras de negócio, escritas uma vez em Kotlin e compiladas para as duas plataformas. Os ecrãs continuam nativos (SwiftUI no iOS, Jetpack Compose no Android), ou também podem ser partilhados com o Compose Multiplatform, estável no iOS desde o Compose Multiplatform 1.8. É o caminho natural para uma empresa que já tem programadores Android e quer uma app iOS sem uma segunda camada de lógica.

Capacitor e Ionic: a web num invólucro

A sua app web existente corre dentro de uma WebView, e plugins expõem-lhe a câmara, as notificações ou o sistema de ficheiros. É o caminho mais rápido de um site para uma ficha de loja, e o mais fraco na sensação de uso: o scroll, os gestos e as transições são os do browser, não os da plataforma. A Apple também rejeita apps que são «essencialmente um site encapsulado» sem valor nativo, por isso o invólucro tem de merecer o seu lugar com funcionalidades reais do dispositivo.

Os compromissos que decidem de facto

Custo: uma só equipa, mas a taxa de plataforma fica

A poupança é real e é sobretudo organizacional: uma equipa, um backlog, um lançamento em vez de dois que se afastam. O que o cross-platform não elimina é tudo o que as plataformas cobram do lado delas. Continua a precisar de uma adesão ao Apple Developer Program, de uma conta Google Play Console, de um Mac algures para assinar os builds iOS (o seu ou um na cloud), e continua a passar pelas duas revisões de loja com as mesmas regras de uma app nativa.

Desempenho: suficiente para produtos, nativo para os extremos

Para a esmagadora maioria das apps, formulários, listas, mapas, chat, pagamentos, câmara e notificações, as quatro famílias são suficientemente rápidas para que os utilizadores não notem. O nativo continua a ganhar nos extremos: 3D e realidade aumentada, processamento de áudio e vídeo em tempo real, widgets de ecrã inicial e integrações profundas com o sistema operativo, e jogos. Se o seu produto é um destes, a decisão está tomada por si.

Manutenção: a atualização anual que ninguém planeia

Todos os anos em setembro, a Apple e a Google lançam novos sistemas operativos, e cada framework lança atualizações para acompanhar. O Expo publica três versões do SDK por ano, o Flutter lança trimestralmente, o Kotlin Multiplatform segue a cadência do Kotlin, e uma app web encapsulada atualiza-se com a web. Nada disto é difícil se acompanhar; tudo isto é penoso se deixar passar dois anos. Ponha uma atualização por trimestre no roadmap e o custo mantém-se pequeno.

Como escolher: um guia de decisão

Parta da equipa que tem, não dos benchmarks. O framework que uma equipa consegue contratar e manter bate o framework que ganha um teste sintético.

Depois, percorra um checklist curto antes de se comprometer:

• 1. Liste as funcionalidades do dispositivo de que precisa. Câmara, notificações push, localização em segundo plano, Bluetooth, pagamentos. Confirme que cada uma tem um módulo mantido no framework que está a considerar.
• 2. Conte as pessoas que o vão manter. Uma pessoa consegue manter viva uma app Expo; uma configuração KMP com ecrãs nativos precisa de pelo menos uma mão iOS e uma mão Android.
• 3. Estime o tempo de vida. Uma app de campanha de três meses e um produto de cinco anos não merecem a mesma arquitetura.
• 4. Prototipe numa semana. Construa os dois ecrãs mais difíceis no seu candidato principal e ponha-os num telemóvel real. A maioria das dúvidas desaparece nesse momento.
• 5. Planeie o pipeline de lançamento. Assinatura, builds na cloud, TestFlight e faixas de teste interno. Decida-o agora, não na semana do lançamento.

E se não tiver equipa mobile nenhuma

O caso mais comum para um fundador ou uma pequena empresa não é «que framework?» mas «quem vai escrever isto?». Um AI app builder responde a essa pergunta com uma verdadeira stack cross-platform em vez de um modelo fixo. Na Cadrant, um projeto mobile nativo é uma aplicação Expo e React Native: descreve a app em linguagem natural, pré-visualiza-a numa moldura de telemóvel, testa-a no seu próprio dispositivo com o Expo Go e depois publica na App Store através das suas próprias contas Expo e Apple. Se não precisar de ficha de loja, o mesmo builder entrega uma progressive web app ou uma app WebView em alternativa. A página do criador de apps móveis detalha as três opções.

Cross-platform em 2026 é uma família de escolhas maduras, não um atalho. Escolha a que a sua equipa consegue dominar, orçamente os custos de plataforma que nenhum framework elimina e ponha a atualização anual no calendário. O resto é construir o produto.