O que é a decisão da Shopify de voltar ao nativo

A Shopify, uma das maiores plataformas de e-commerce do mundo, anunciou que esta migrando partes importantes dos seus aplicativos moveis de volta para desenvolvimento nativo, deixando o React Native de lado nesses pontos. A empresa vinha usando o framework havia anos em produtos críticos do seu ecossistema.

React Native foi criado pelo Facebook (hoje Meta) e lançado em 2015 com a promessa de permitir que times escrevam código uma vez em JavaScript e rodem em iOS e Android com a mesma base. Ele se tornou uma das opcoes mais populares de desenvolvimento multiplataforma no mercado.

A decisão da Shopify não e isolada. Outras empresas grandes, como o Airbnb, já haviam anunciado publicamente no passado que abandonaram o React Native em favor de código nativo, geralmente citando dificuldades de manutenção, performance e integração profunda com as plataformas.

Como funciona a comparação entre nativo e React Native

Desenvolvimento nativo significa escrever o aplicativo diretamente nas linguagens e frameworks oficiais de cada plataforma: Swift ou Objective-C para iOS, Kotlin ou Java para Android. Cada app tem sua própria base de código, mas acesso total e direto aos recursos do sistema operacional.

Já o React Native usa uma camada de ponte (bridge) entre o JavaScript e o código nativo, traduzindo comandos da interface para componentes reais de cada plataforma. Essa camada e o que permite reaproveitar código, mas também é o principal ponto de atrito em cenários de alta performance.

⚠️
Atenção

A ponte entre JavaScript e nativo pode gerar gargalos em telas com muita animação, listas grandes ou lógica pesada rodando em tempo real, como e o caso de fluxos de checkout e pagamento.

Em apps de e-commerce como os da Shopify, telas de carrinho, checkout e catalogo de produtos costumam exigir respostas muito rápidas e integração fina com recursos do sistema, como carteiras digitais e leitores de código. Esses são justamente os pontos onde o overhead do React Native mais pesa.

Principais recursos e motivos por trás da troca

Entre os motivos mais citados por empresas que abandonam frameworks multiplataforma como o React Native estão a performance em cenários críticos, o controle total sobre a experiência do usuário e a redução de camadas de abstração que dificultam debugging.

  • Performance previsível: código nativo evita a sobrecarga da ponte JavaScript-nativo em operações pesadas.
  • Acesso direto a APIs novas: recursos recentes de iOS e Android costumam chegar primeiro as APIs nativas, exigindo espera por suporte no framework multiplataforma.
  • Debugging mais simples: menos camadas entre o código e o sistema operacional facilita encontrar a causa raiz de bugs.
  • Times especializados: empresas grandes conseguem manter equipes dedicadas a iOS e Android separadamente, o que reduz a vantagem de compartilhar código.

Por outro lado, isso significa manter duas bases de código distintas, o que aumenta o esforço de desenvolvimento e exige mais coordenação entre os times de plataforma.

Como avaliar essa troca no seu próprio projeto

Antes de trocar de framework, o primeiro passo e mapear onde estão os gargalos reais. Ferramentas de profiling de performance do próprio React Native ajudam a identificar se o problema esta na ponte JavaScript-nativo ou em outro ponto do app.

npx react-native run-android --variant=release
# gera build de produção para medir performance real, sem overhead do modo debug

Depois, vale medir o custo de manter duas bases nativas separadas: tempo de time, complexidade de CI/CD e velocidade de entrega de features. Em times pequenos, o compartilhamento de código do React Native costuma compensar mais do que em empresas do porte da Shopify.

Por fim, e importante avaliar se as telas mais críticas do seu app (as que mais impactam receita ou experiência do usuário) são justamente as que sofrem com limitações de performance multiplataforma. Se sim, uma migração parcial, só dessas telas, pode ser um meio termo razoável.

Exemplo prático de migração parcial

Uma estratégia comum, e a que a própria Shopify parece ter adotado, e a migração gradual. Em vez de reescrever o app inteiro de uma vez, a equipe identifica os módulos mais sensíveis a performance e os reescreve nativamente, mantendo o restante em React Native ou outra stack compartilhada.

💡
Dica

Comece a migração pelas telas com maior volume de interação do usuário, como checkout, busca e listagem de produtos. São elas que mais evidenciam diferenças de performance.

Esse tipo de arquitetura híbrida permite medir o impacto real da mudança em produção antes de investir na reescrita completa do app, reduzindo o risco do projeto e permitindo ajustes de rota no meio do caminho.

Times que adotam essa abordagem costumam criar uma camada de navegação compartilhada, que decide se uma tela será renderizada em código nativo ou no framework multiplataforma, de forma transparente para o usuário final.

Comparação com alternativas de desenvolvimento mobile

Além do React Native, o mercado tem outras opcoes de desenvolvimento multiplataforma, como Flutter, do Google, que usa uma engine de renderização própria em vez de depender de componentes nativos, e Kotlin Multiplatform, que compartilha lógica de negócio mas deixa a interface nativa em cada plataforma.

O Flutter tende a ter performance mais previsível que o React Native por não depender de uma ponte com o código nativo, mas ainda assim não alcança o mesmo nível de controle que o desenvolvimento totalmente nativo oferece.

Já o Kotlin Multiplatform e uma abordagem intermediaria interessante: compartilha regras de negócio, validações e chamadas de API entre iOS e Android, mas deixa a construção da interface totalmente nativa, o que evita boa parte dos problemas de performance visual.

Pontos positivos e limitações de cada abordagem

O desenvolvimento nativo oferece o melhor desempenho possível e acesso imediato a qualquer recurso novo das plataformas, mas exige duas equipes especializadas e duplica boa parte do esforço de desenvolvimento.

O React Native, por sua vez, acelera a entrega inicial e reduz custo de time em produtos menores, mas pode se tornar um gargalo conforme o app cresce em complexidade e volume de usuários, especialmente em fluxos críticos como pagamento.

🔴
Cuidado

Trocar de framework no meio de um produto em produção e um projeto de alto risco. Faca isso de forma gradual e sempre com métricas de performance acompanhando cada etapa.

Não existe uma resposta única e definitiva. A escolha certa depende do tamanho do time, da complexidade do produto e de quanto a performance impacta diretamente a receita do negócio.

Casos de uso reais para cada tipo de desenvolvimento

Startups em fase inicial, com times pequenos e prioridade em velocidade de lançamento, costumam se beneficiar mais do React Native ou do Flutter, já que conseguem validar o produto rápido sem duplicar esforço entre iOS e Android.

Empresas de e-commerce de grande porte, como a Shopify, tendem a atingir um ponto em que a escala de usuários torna cada milissegundo de performance relevante para conversão e receita, o que justifica o investimento em código nativo nos fluxos mais críticos.

Apps de conteúdo e consumo, com telas mais estáticas e menos interação em tempo real, tendem a sofrer menos com as limitações do React Native e podem manter a stack multiplataforma por muito mais tempo sem sentir necessidade de trocar.

Já produtos com uso intenso de animações, camera, geolocalização em tempo real ou pagamentos embutidos costumam ser os primeiros candidatos a migração para nativo, exatamente como aconteceu no caso da Shopify.

Dicas e boas práticas para quem decide entre nativo e multiplataforma

💡
Dica

Meca performance real em produção, não só em ambiente de desenvolvimento. O overhead de frameworks multiplataforma costuma ficar mais evidente em dispositivos mais antigos e conexões lentas.

🚀
Pro tip

Use uma arquitetura modular desde o inicio, separando lógica de negócio da camada de interface. Isso facilita migrar telas específicas para nativo no futuro, sem reescrever o app inteiro.

Erros comuns de times que começam com React Native incluem não medir performance até ser tarde demais, ignorar o custo de manutenção de dependências de terceiros e não planejar desde cedo uma possível saída gradual do framework.

Times experientes costumam manter um dashboard de métricas de performance por tela, acompanhando tempo de carregamento e taxa de erro, para identificar cedo quais partes do app merecem atenção especial.

Vale a pena seguir o exemplo da Shopify?

Para a maioria dos times pequenos e médios, o React Native ainda faz sentido: a velocidade de desenvolvimento e o compartilhamento de código compensam o overhead de performance na grande maioria dos casos de uso comuns.

Para empresas de grande escala, com fluxos críticos de pagamento e checkout, o caminho seguido pela Shopify mostra que investir em nativo nos pontos certos pode valer a pena, mesmo com o custo adicional de manter duas bases de código.

O próximo passo, se você esta decidindo entre as duas abordagens, e medir performance real do seu app hoje e mapear quais telas mais impactam a experiência do usuário antes de decidir por qualquer migração.