Native vs cross-platform: a decisão de build que o fundador não técnico realmente assume

Você nunca vai escrever uma linha de Swift ou Flutter. Então pare de tentar responder a essa pergunta no terreno técnico. Native vs cross-platform é uma decisão de orçamento e prazo fantasiada de questão de desenvolvedor, e aqui está o teste de quatro perguntas que a resolve.

Um fundador com quem a gente trabalha estava numa reunião com fornecedor no ano passado e ouviu, sem rodeio: “Nativo ou cross-platform?” Ele não sabia. Tinha levantado uma rodada seed para construir um produto de agendamento para clínicas, descrevia o fluxo do paciente de olhos fechados, e não fazia ideia se a resposta certa envolvia Kotlin, Flutter ou algo que ele nunca tinha ouvido falar. Então fez o que uma pessoa de finanças faz quando encurralada: perguntou quanto cada opção custava. O fornecedor deu uma resposta direta, e a questão técnica se dissolveu numa questão de negócio. É esse o truque inteiro.

Se você pesquisar native vs cross-platform, todo resultado da primeira página é escrito por ou para desenvolvedores. CircleCI, Microsoft, Kotlin, uma thread no Reddit, dois canais de YouTube, algumas fábricas de software. Discutem taxa de quadros, maturidade de framework e se Swift ganha do Flutter. Tudo isso é real, e quase nada é decisão sua. Você não está escolhendo uma linguagem. Está escolhendo uma restrição, e o estúdio escolhe a linguagem que cabe nela.

Aqui está a definição sem o jargão. Um app nativo é construído separadamente para cada plataforma: um código nas ferramentas da Apple para iPhone, um segundo código nas ferramentas do Google para Android. Um app cross-platform é construído uma vez, a partir de um único código, e roda nos dois. O desenvolvimento cross-platform usa frameworks como Flutter (Google) ou React Native (Meta) para escrever o app uma única vez e publicá-lo nas duas lojas. Nativo significa dois builds. Cross-platform significa um. Esse único fato governa a maior parte do que vem a seguir, inclusive a parte da conta que de fato te interessa.

Por que isso é uma decisão de dinheiro, não de tecnologia

Dois códigos custam mais que um. Não num sentido abstrato de “dívida técnica”. No sentido literal de que você está pagando gente para construir, testar e manter o mesmo produto duas vezes, em duas linguagens, em dois ciclos de release. Um build nativo para iOS e Android normalmente sai entre 1,5x e 2x o custo e o calendário de um único build cross-platform que cobre os dois. O múltiplo exato depende de quanto do app é lógica compartilhada versus superfície específica de cada plataforma, mas a direção nunca muda: nativo é o caminho mais caro, por construção.

Esse prêmio compra alguma coisa. A pergunta é se você precisa do que ele compra. Para um app de agendamento de clínica, um marketplace, um dashboard de fintech, uma ferramenta interna de operações, um SaaS em estágio inicial com um companion mobile, a resposta honesta costuma ser não. Esses produtos são telas, formulários, listas e chamadas de API. Um framework cross-platform renderiza tudo isso com qualidade e publica nas duas lojas a partir de um time só. Você chega ao mercado mais rápido, gasta menos, e tem um código para manter em vez de dois quando seu único desenvolvedor fica doente ou, pior, pede demissão. Isso se conecta direto à decisão anterior na mesma cadeia, construir ou comprar: as duas perguntas são respondidas mal quando é a alocação do fornecedor, e não o seu produto, que conduz a recomendação.

As quatro perguntas que de fato decidem

Você não consegue avaliar o Flutter. Consegue responder a estas quatro. Cada uma move a decisão, e juntas elas a resolvem sem um único argumento técnico.

1. De quantas plataformas você genuinamente precisa no dia um? Se seus usuários estão tanto no iPhone quanto no Android (a maioria dos produtos de consumo e PME no Brasil e nos EUA está), você precisa dos dois, e a economia de um-código-só do cross-platform fica muito atraente. Se você está construindo uma ferramenta interna para um time comercial que é 100% iPhone corporativo, talvez precise só de iOS, e a questão nativo-vs-cross-platform em parte evapora. Uma plataforma muda a conta.

2. Quão pesado de dispositivo é o produto? Seja específico sobre o que o app faz com o celular. Um app de agendamento lê um calendário e chama uma API. Um editor de vídeo força a GPU, um app de fitness lê sensores em alta frequência, um app social camera-first vive e morre no pipeline nativo da câmera. Quanto mais fundo seu produto alcança o hardware do aparelho, e quanto mais perto do metal precisa rodar, mais o nativo justifica seu prêmio. Produtos de telas-e-formulários quase nunca alcançam essa profundidade.

3. Por quanto tempo esse produto vai viver? Um MVP descartável que você pretende validar e possivelmente jogar fora em seis meses deveria ser cross-platform sempre. Você está comprando velocidade e opcionalidade, não uma arquitetura de 10 anos. Um produto que você já sabe que é a empresa, que vai manter e estender por anos, merece uma conversa mais deliberada, porque a diferença de custo se acumula ao longo de uma vida de manutenção mais longa, nos dois sentidos.

4. Uma experiência específica de plataforma é o produto de verdade? Às vezes o feel nativo é o ponto. Se sua diferenciação é uma interação macia, a 120fps, profundamente idiomática do iOS que um usuário de Android nunca veria, nativo é defensável. Mas seja implacável aqui. “Tem que parecer premium” não é o mesmo que “o feel nativo premium é o motivo pelo qual o cliente nos escolhe em vez da alternativa”. A maioria dos fundadores se convence de que está no segundo grupo quando está confortavelmente no primeiro.

Se você respondeu “as duas plataformas, não é pesado de dispositivo, vida incerta ou curta, nenhuma experiência específica de plataforma como produto”, você tem sua resposta, e ela é cross-platform. Isso cobre a grande maioria dos produtos em estágio inicial. A regra de bolso que vale anotar: assuma cross-platform por padrão, e faça o nativo merecer o upgrade com um motivo específico, nomeado, que você consiga defender numa reunião de conselho.

O que o nativo de fato te custa (as desvantagens que ninguém na busca coloca primeiro)

As páginas de fábrica de software listam as desvantagens do nativo numa coluninha arrumada de bullets e seguem em frente. As que mordem um fundador não técnico são estas. Dois códigos significam dois de cada decisão futura: duas revisões de release em duas lojas, dois conjuntos de bugs, dois lugares onde uma feature precisa ser construída antes de sair. Sua velocidade cai pela metade em qualquer coisa que toque as duas plataformas, ou seu custo dobra para manter dois desenvolvedores ocupados. Seu problema de contratação também dobra, porque agora você precisa de competência em iOS e Android, não de um único skill cross-platform. E seu risco de um único desenvolvedor fica mais afiado: com dois códigos nativos, perder a pessoa errada pode deixar metade do seu produto órfã. Nada disso aparece num benchmark de framework. Tudo isso aparece no seu runway.

Onde o nativo ainda ganha

Este não é um artigo anti-nativo. Existe um ~20% real de produtos em que nativo é a decisão certa e adulta, e fingir o contrário seria exatamente o tipo de conselho tamanho-único que o resto da internet já fornece. Nativo justifica seu prêmio quando o produto é genuinamente pesado de dispositivo: jogos de alta taxa de quadros, apps sérios de câmera ou AR, ferramentas de áudio, qualquer coisa que force sensores ou a GPU. Ganha quando uma UX específica de plataforma é o diferencial, não o enfeite. E ganha numa escala em que a maioria de quem lê isto ainda não está, onde você tem times separados de iOS e Android, os códigos divergiram de propósito, e a abstração cross-platform passou a custar mais do que poupa.

“O Netflix é um app nativo?” é a pergunta que a busca insiste em fazer, e a resposta é instrutiva. Os apps mobile do Netflix são em boa parte nativos, e essa é a escolha certa para o Netflix: uma empresa naquela escala, com tanto em jogo na performance de vídeo e na reprodução específica de cada plataforma, pode bancar dois times de altíssimo nível e precisa do que o nativo compra. Você, com todo o respeito, ainda não é o Netflix. A lição não é “faça o que o Netflix faz”. É “nativo é a decisão certa quando suas restrições ficam parecidas com as do Netflix, e nem um dia antes”.

Native vs cross-platform vs híbrido, e a confusão com web app

Dois termos turvam essa busca, então esclareça rápido. Híbrido normalmente significa um app embrulhando uma web view numa casca nativa (a abordagem mais antiga, tipo Cordova/Ionic). É uma terceira opção distinta e geralmente de menor fidelidade, e a maioria dos times modernos escolhe um framework cross-platform de verdade como Flutter ou React Native em vez de um wrapper híbrido, porque o resultado fica mais perto do nativo pelo mesmo preço de um-código-só. Quando alguém diz “cross-platform” hoje, assuma que é Flutter ou React Native, os dois frameworks que dominam o uso profissional cross-platform na pesquisa do Stack Overflow, não um wrapper de web.

Um app nativo versus um web app é uma bifurcação totalmente diferente: um web app roda no navegador, sem instalação na loja, enquanto tanto o nativo quanto o cross-platform produzem um app instalável. Se seus usuários não precisam estar nas lojas, essa é uma conversa que vale ter antes desta. Mas é uma decisão separada, e misturá-la com nativo-vs-cross-platform é como fundadores acabam confusos em reuniões com fornecedor.

O que de fato fazer na reunião

Entre tendo respondido as quatro perguntas, não tendo googlado comparações de framework. Diga ao estúdio quais plataformas você precisa, quão pesado de dispositivo é o produto, a vida que você espera, e se um feel específico de plataforma é central. Depois faça eles justificarem a recomendação contra as suas respostas, não a alocação deles. Um bom parceiro vai assumir cross-platform por padrão e te dizer com clareza o dia em que o nativo passa a valer o prêmio, do mesmo jeito que deveria ser transparente sobre quanto um app de fato custa para construir. Um fornecedor que começa com “nativo, óbvio” antes de ouvir suas restrições está respondendo a uma pergunta diferente daquela que você está pagando para ele responder.

A decisão técnica nunca foi sua. A restrição era. Acerte a restrição e o framework se escolhe sozinho.

FAQ

Quais são as desvantagens dos apps nativos?
Para um fundador, as desvantagens são quase todas econômicas, não técnicas. Você mantém dois códigos, publica por duas revisões de loja, constrói a maioria das features duas vezes, e precisa de skills de iOS e Android no time. Isso mais ou menos dobra o custo e o risco de um único desenvolvedor em comparação com um build cross-platform. O teto de performance é mais alto, mas a maioria dos produtos nunca chega perto dele.

Onde o nativo seria melhor que o cross-platform?
Quando o produto é pesado de dispositivo (jogos de alta taxa de quadros, câmera/AR séria, áudio, uso intenso de sensores), quando uma experiência específica de plataforma é o diferencial de fato, ou numa escala em que você já roda times separados de iOS e Android de propósito. Para produtos de telas-e-formulários em estágio inicial, cross-platform quase sempre ganha em custo e velocidade.

Apps nativos têm performance melhor?
Nos extremos, sim: o nativo tem um teto de performance mais alto porque fala direto com cada plataforma. Mas frameworks cross-platform modernos como Flutter e React Native são rápidos o suficiente para que a maioria dos usuários não note diferença num app de negócio típico. O gap de performance importa para uma minoria de produtos e é invisível no resto.

O Netflix é um app nativo?
Os apps mobile do Netflix são em boa parte nativos, o que é a decisão certa para uma empresa naquela escala, com demandas pesadas de performance de vídeo e orçamento para dois times de primeira linha. É um péssimo modelo para um produto em estágio inicial, onde o prêmio do nativo normalmente não compra nada que seus usuários notariam.

Desenvolvimento cross-platform é mais barato?
Em geral, sim. Um código cobrindo as duas plataformas normalmente custa bem menos para construir e manter do que dois códigos nativos, muitas vezes na ordem de 1,5x a 2x menos, porque você não está construindo e mantendo o mesmo produto duas vezes. A economia é maior ao longo da vida de manutenção do produto, não só no lançamento.