Um app ou dois? O que a IA mudou na decisão do canal móvel

Imagine o comitê em que se aprova o novo app para os clientes da empresa. Duas propostas sobre a mesa. A primeira diz: «Uma única base de código para iPhone e Android; constrói-se uma vez e economiza-se quase metade». A segunda diz: «Dois apps nativos, um por plataforma; é a opção séria para um banco ou uma seguradora». Cada proposta traz um caso famoso. Uma cita a Shopify, que construiu os próprios apps com uma única base de código e deu certo. A outra cita a Airbnb, que abandonou essa mesma tecnologia em 2018.

Até pouco tempo atrás, o comitê teria escolhido pelo caso que soasse melhor. Mas em setembro de 2026 a Shopify, o exemplo da primeira proposta, anunciou que volta ao nativo [3]. Não saiu pelo mesmo motivo da Airbnb: o contexto dela era outro, e a razão tem a ver com a inteligência artificial.

Este artigo é para quem assina essa decisão: direção geral, de sistemas, comercial ou digital. Não é uma pergunta técnica. É uma decisão de custo total, velocidade, capacidades do telefone, equipe e risco, e os pressupostos dela caducam.

Primeiro, três palavras

Antes de comparar, convém que todos na mesa entendam a mesma coisa.

• Nativo: constrói-se um app para iPhone, com a linguagem e as ferramentas da Apple (Swift), e outro para Android, normalmente em Kotlin, a linguagem que o Google recomenda para Android. São dois códigos e certa duplicação. Em troca, cada app adota diretamente as capacidades do telefone quando estão disponíveis.
• Multiplataforma: escreve-se um único app e uma camada intermediária o faz funcionar nos dois sistemas. Os exemplos mais conhecidos são React Native (nascido no Facebook, programa-se com JavaScript, a linguagem da web) e Flutter (do Google). Uma base de código, uma equipe, mas uma camada a mais entre o app e o telefone.
• Lógica compartilhada, telas nativas: o ponto intermediário. Compartilha-se o que não se vê (regras de negócio, cálculos, conexão com os sistemas) e cada plataforma desenha as próprias telas. O exemplo mais visível é o Kotlin Multiplatform, da JetBrains, que o Google suporta oficialmente para compartilhar lógica entre Android e iOS [5].

E quatro termos que vão aparecer. Framework: a plataforma de desenvolvimento sobre a qual o app é construído. Dependências: componentes de terceiros que o app usa e que é preciso atualizar e vigiar. Ponte ou camada: o código que faz a tradução entre a parte compartilhada e as funções do telefone. Nova Arquitetura: a forma refeita com que o React Native faz essa tradução.

Duas empresas, contextos distintos, resultado parecido

Airbnb, 2018: não deu certo

A Airbnb integrou o React Native dentro dos próprios apps nativos, que já eram grandes e continuavam crescendo. Em junho de 2018 publicou que deixava de usá-lo [1]. As razões, em linguagem de negócio:

• Não compartilhou tanto quanto esperava. Apenas uma parte pequena do app estava em React Native, e conectá-la ao restante exigia muita infraestrutura de ponte. Acabou, diz o artigo, mantendo código em três plataformas em vez de duas [1].
• Corrigir falhas ficou mais difícil. Compilar era mais rápido; depurar, muito pior [1].
• Faltavam mãos especialistas, dentro e fora da empresa, para resolver os problemas técnicos encontrados [1].

O matiz que quase ninguém cita: o próprio artigo diz que muitas dessas dificuldades vieram do modelo híbrido que escolheram, e que 63 % dos engenheiros da empresa voltariam a escolher o React Native (com o viés, que eles mesmos apontam, de que só pesquisaram quem o usou) [1]. E hoje o artigo traz um aviso no início: reflete a tecnologia do fim de 2017, e pede: «Se estes artigos forem citados exclusivamente como motivo para não usar o React Native, por favor, pesquise mais por conta própria antes de tomar uma decisão» [1].

A Airbnb não disse «o React Native não serve». Disse: «do nosso jeito de usá-lo, com a nossa equipe e o nosso app, não alcançamos o que buscávamos».

Shopify, 2020–2025: deu certo

A Shopify decidiu em 2020 que os novos apps móveis da empresa seriam em React Native. Em janeiro de 2025, um diretor de engenharia da Shopify publicou o balanço de cinco anos [2]: «Não ter que construir as mesmas funções duas vezes nos deu um salto de produtividade». Relatou telas que carregam em menos de meio segundo e mais de 999 de cada 1.000 sessões sem falhas, e que nativo não significa rápido automaticamente, nem o React Native, lento automaticamente [2].

O mesmo artigo traz as advertências que um diretor deve ler [2]:

• Ter o app 100 % em React Native devia ser um antiobjetivo: continuavam precisando de código nativo para o que há de mais novo em hardware (escaneamento em 2D e 3D, modelos de IA que rodam no telefone), para os widgets da tela inicial, o relógio e os atalhos de voz, e para tarefas longas em segundo plano, como a sincronização que permite ao ponto de venda cobrar sem conexão.
• Atualizar o app a cada nova versão do framework custa um trabalho considerável, e as dependências precisam ser mantidas em dia.
• Depurar continuava instável.

Ou seja: deu certo, com uma equipe que, além disso, contribuiu ativamente com o ecossistema do React Native.

Shopify, 2026: deu certo, e mesmo assim volta

Em 10 de setembro de 2026, o mesmo autor publicou «Native is now the future of mobile at Shopify» [3]. A razão central cabe em uma frase: «Os LLMs mudaram um dos pressupostos centrais por trás da nossa decisão de 2020» [3]. Um LLM é um modelo de linguagem, a tecnologia por trás dos assistentes de IA que hoje escrevem código.

O pressuposto era que construir cada função duas vezes, em Swift e em Kotlin, era caro demais. A Shopify diz que, com os agentes de IA (assistentes que executam tarefas de programação por encomenda) fazendo o trabalho de implementação, tradução, testes e revisão, esse custo deixou de ser o fator que decide [3]. O que permanece são as vantagens do nativo: estar mais perto das capacidades de cada plataforma e das ferramentas do fabricante, com menos camadas de framework e dependências no meio [3]. E esclarece: não sai porque o React Native seja lento; os apps dela, diz, são rápidos [3].

O resultado que relata: o app de compras (Shop) passou de prova de conceito a publicado em nativo em 12 semanas; o dos comerciantes sairia antes do fim de 2026 [3].

A lição não é «vamos para o nativo»

Ponha os dois casos lado a lado:

Contextos distintos, resultado parecido. Se o comitê copiar a escolha de qualquer uma das duas, copia uma conclusão cujo pressuposto talvez não se aplique à empresa. O que se copia é o método: revisar de tempos em tempos o pressuposto econômico sobre o qual a decisão foi tomada.

O que mudou com a IA, e o que não

A Shopify declara que, para os próprios apps e a própria equipe, a IA reduziu o custo de escrever a mesma função duas vezes, e esclarece que manter duas plataformas continua custando [3]. Fora da Shopify, isso se valida com um teste delimitado antes de dar por certo. E mesmo onde o custo cai, todo o resto não cai, ou cai muito menos:

• Desenhar a experiência, decidir o que o app faz e o que não faz.
• Testar em dezenas de modelos de telefone e versões de sistema operacional.
• Revisar se o que foi gerado é manutenível. A Shopify diz sem rodeios: apontar um modelo de linguagem para todo o código dela para «traduzi-lo» produzia uma enorme quantidade de código impossível de manter [3]. Para evitar isso, construiu um sistema próprio por etapas, com testes, revisão visual, dois revisores automáticos e aprovação humana [3].
• Publicar nas lojas da Apple e do Google e atender às regras de cada uma.
• Conectar o app aos sistemas que de fato atendem o cliente. Falaremos disso mais adiante, porque costuma ser o mais caro.

Em outras palavras: a IA não tornou gratuito ter dois apps. Fez com que o custo de escrever duas vezes deixasse de ser, para a Shopify, o fator que decide. Se isso vale para a empresa depende de quanto controle de qualidade ela pode impor ao código gerado.

Tampouco há um vencedor universal em desempenho. Um estudo publicado em setembro de 2026 (um preprint, isto é, ainda sem revisão por pares) construiu o mesmo app cinco vezes: nativo em iOS, nativo em Android, Flutter, React Native e Kotlin Multiplatform, e mediu cada variante 2.000 vezes [4]. O nativo registrou os menores tempos na parte que não é de interface; o Kotlin Multiplatform foi a opção compartilhada mais próxima; nessas implementações, as compartilhadas tiveram menos código que as duas nativas somadas, o que não equivale ao esforço de qualquer produto. A conclusão do estudo: não há uma tecnologia superior em tudo; a vantagem depende do atributo medido, da carga de trabalho e da plataforma [4].

Cinco critérios para decidir

1. O que do roadmap toca o telefone por dentro?

Faça a lista do que o app fará nos próximos dois ou três anos e marque o que depende do hardware ou do sistema operacional:

• Biometria: impressão digital ou rosto para entrar ou autorizar uma operação.
• NFC: pagar aproximando o telefone, ou ler uma credencial ou cartão.
• Câmera avançada: ler identidades, documentos ou códigos; escanear um dano para um sinistro.
• Trabalho em segundo plano: sincronizar, cobrar sem conexão, rastrear uma entrega.
• Widgets, relógio, atalhos de voz, notificações enriquecidas.

Se a lista for curta, um app multiplataforma a resolve bem e usa peças nativas pontuais onde for preciso. Se a lista for longa e for o coração da proposta de valor, o nativo permite adotar cada nova função da Apple ou do Google com menos camadas. A Shopify, mesmo nos melhores anos com o React Native, mantinha código nativo justamente para isso [2].

2. Que equipe a empresa tem, e que equipe consegue reter?

Uma equipe forte em desenvolvimento web se move rápido no React Native. Uma equipe com especialistas em iPhone e Android aproveita melhor o nativo. A Airbnb mencionou a falta de mãos especialistas como parte do problema [1]; a Shopify, com uma equipe madura, fez as duas opções funcionarem. A pergunta não é qual tecnologia é melhor, mas qual a equipe consegue sustentar durante cinco anos, incluídas as vagas que terá de preencher.

3. O que o cliente prioriza?

Chegar primeiro ao mercado e com a mesma experiência nos dois telefones, ou a sensação mais refinada, a resposta mais imediata e o menor tamanho do app. Para um app de conteúdo ou de catálogo, o primeiro costuma pesar mais. Para um app em que o cliente movimenta dinheiro várias vezes ao dia, o segundo pesa mais do que parece.

4. Quanto custa mantê-lo, e não construí-lo?

O custo de construir é visível na proposta; o de manter aparece depois. Com multiplataforma é preciso acompanhar o ritmo do framework e das dependências dele. Um exemplo recente: o React Native tornou padrão a Nova Arquitetura na versão 0.76, em 2024, e desde a 0.82, em outubro de 2025, ela já não pode ser desativada [6]. Um app que atualize para a 0.82 sem tê-la validado pode exigir trabalho de compatibilidade e testes: preveja-o no orçamento. Com o nativo é preciso sustentar dois códigos e mantê-los iguais. A IA muda o peso desse segundo custo; não elimina o primeiro.

5. Com que frequência a decisão é revista?

A Shopify tomou uma boa decisão em 2020 e outra boa decisão, diferente, em 2026, porque um pressuposto mudou. Ponha data na ata: que pressuposto sustenta a escolha (por exemplo, «construir duas vezes custa quase o dobro»), como ele é medido e quando será revisto.

O ponto intermediário: compartilhar lógica, não telas

Entre «um app» e «dois apps» há uma terceira via que muitas vezes convém a empresas reguladas: compartilhar o que não se vê e construir em nativo o que se vê.

Pense no que deve ser idêntico no iPhone e no Android: como se calcula um prêmio ou uma comissão, que validações se aplicam a uma transferência, como a informação é guardada e criptografada, como se fala com os sistemas. Se essas regras vivem em dois códigos, cresce o risco de dizerem coisas diferentes. Com o Kotlin Multiplatform, por exemplo, essas regras são escritas uma vez, e cada plataforma desenha as telas com as próprias ferramentas. O Google o suporta oficialmente para compartilhar lógica de negócio entre Android e iOS, e permite escolher quanto compartilhar: desde apenas a lógica até o aplicativo completo [5]. No estudo citado, foi a opção compartilhada mais próxima do nativo em desempenho [4].

O custo: a equipe precisa dominar as duas plataformas e, além disso, a camada compartilhada. Não é a opção mais barata; é a que costuma dar paridade de regras sem abrir mão da experiência nativa.

Situação e opção que costuma convir

Guia de conversa, não receita.

Cenário (cifras ilustrativas, sem cliente). Uma seguradora planeja o app para três anos: 24 funções. Ao marcá-las, 5 dependem do telefone por dentro (câmera para sinistros, biometria, notificações enriquecidas, trabalho sem conexão do regulador e um widget de apólice). As outras 19 são telas de consulta e trâmite que chamam os sistemas dela. O 5 de 24 é um inventário, não um veredito: cada uma das 5 é ponderada por criticidade, dependência de um SDK (o kit de um terceiro, como um antifraude), obrigação regulatória e desempenho. Uma única função crítica pode decidir: se o trabalho sem conexão do regulador é a aposta do negócio, pesa mais que as 19 e a balança pende para o nativo ou para a lógica compartilhada. De qualquer modo, as 19 telas dependem de que os sistemas de trás respondam: ali está a maior parte do risco.

Os riscos, em linguagem de negócio

Qualquer das três opções tem riscos. Cinco para a mesa.

• «O framework mudou e é preciso migrar». Um app multiplataforma depende do ritmo de um terceiro e de muitas dependências. A Shopify descreve a atualização a cada versão como um trabalho considerável [2], e a Nova Arquitetura exige trabalho de compatibilidade de quem atualiza sem tê-la validado [6]. Orce a manutenção, e não só a construção.
• «Não sabemos por que falha». Mais camadas entre o código e o telefone significam falhas mais difíceis de encontrar. A Airbnb viveu isso [1] e a Shopify ainda o relatava em 2025 [2]. Em um app que movimenta dinheiro, o tempo para encontrar uma falha é tempo com clientes irritados.
• «A IA escreveu e ninguém revisou». Gerar dois apps com IA é mais barato; gerar dois apps impossíveis de manter também. O retorno da Shopify veio com controles em cada etapa [3]. Se o fornecedor propõe «dois apps nativos porque a IA os faz», pergunte-lhe como controla a qualidade do que a IA escreve.
• «No Android faz uma coisa e no iPhone outra». Com dois apps nativos, a paridade não é automática: cresce o risco de que uma regra mude em um e no outro não. Decida o que deve ser idêntico (regras, valores, mensagens legais), qual é a fonte que manda, e respalde isso com contratos e testes de paridade entre os dois apps. Deixe no telefone apenas o que a experiência ou a operação sem conexão exigirem.
• «O app ficou pronto, mas o core não». O risco mais frequente e o menos discutido. Vamos tratá-lo à parte.

O app é a cara; o difícil está atrás

No comitê, a discussão costuma ser um app ou dois. Mas o cliente não julga a tecnologia do app: julga se o pagamento foi aplicado, se a apólice aparece, se o saldo está correto. Tudo isso é decidido pelo sistema central (o core) e pelas integrações que o conectam ao app.

Um app impecável, nativo ou multiplataforma, que consulta um core lento ou que só recebe um «recebido» quando o cliente espera um «feito», é percebido como um mau app. Por isso a decisão do canal móvel vem acompanhada de outras:

• O que o app faz e o que os sistemas da empresa fazem. Convém que as regras que devem ser idênticas em todos os canais (app, web, agência, assessor) tenham a versão que manda atrás, uma única vez; no app, só o necessário.
• Como se integra ao core. Que consultas vão online e que operações vão com protocolo e acompanhamento. É o tema do artigo «Online ou assíncrono? Como escolher a forma de integrar os sistemas».
• O que acontece quando o sistema de trás não responde. O que o cliente vê, o que se guarda no telefone e como se tenta de novo sem duplicar um pagamento.

Se a integração estiver bem resolvida, trocar a tecnologia do app, como fez a Shopify, é um projeto de canal. Se não estiver, qualquer troca de app arrasta consigo o problema de trás.

Cinco perguntas para o próximo comitê

1. Que porcentagem do nosso roadmap móvel depende do telefone por dentro (biometria, NFC, câmera, segundo plano, widgets), e quanto é tela que consulta nossos sistemas?
2. Que equipe conseguimos sustentar durante cinco anos, incluídas as vagas, para a opção que escolhermos?
3. Que pressuposto econômico sustenta a nossa decisão atual, e quando foi a última vez que o medimos?
4. Se usarmos IA para construir, como controlamos a qualidade do que ela gera antes de chegar à produção?
5. Onde vive a única versão das regras que devem ser idênticas no iPhone, no Android e nos demais canais?

Se em duas ou mais a resposta for «não sei», ali pode estar o risco da empresa.

Por onde começar esta semana

Pegue o roadmap do app e marque cada função com uma de duas etiquetas: «toca o telefone por dentro» ou «é tela sobre os nossos sistemas». Conte quantas há de cada uma e assinale as críticas. Esse inventário, mais a equipe disponível, diz mais sobre a opção que convém do que qualquer caso famoso.

O que a Hábil faz

A Hábil é uma consultoria mexicana de engenharia, fundada em 2006, que projeta e constrói canais digitais (apps web, móveis e desktop) conectados aos sistemas que a empresa já tem. Não chegamos com a tecnologia escolhida: ajudamos a decidir entre nativo, multiplataforma ou lógica compartilhada conforme o roadmap, a equipe e os sistemas da empresa, e construímos com a opção que convier. Veja a página Canais digitais que o cliente realmente usa.

A primeira conversa é sem custo: parte do roadmap móvel da empresa e de como ele será conectado aos sistemas atuais. Escreva-nos pelo WhatsApp.

As afirmações de empresas refletem as publicações delas em 13 de outubro de 2026; são declarações de cada empresa, não medições próprias. As citações foram traduzidas do inglês.