Shopify deixa o React Native: o que isso ensina

Em 2020, a Shopify publicou um texto dizendo que React Native era o futuro do mobile na empresa. Seis anos depois, o time de engenharia publicou outro, com um título bem menos festivo: estão voltando para Swift e Kotlin. Se você trabalha com React Native, essa notícia pesa. A Shopify não era só mais uma usuária do framework. Era uma das vitrines dele.

Eu uso React Native no dia a dia e não vou fingir que li isso com indiferença. Mas antes de sair declarando a morte de alguma coisa, vale entender o que mudou e o que isso quer dizer para quem está decidindo a stack de um app hoje.

O que a Shopify fez com o React Native

Pra dimensionar a notícia, lembre do tamanho da aposta. A Shopify levou apps importantes para React Native: o app de lojista, o Point of Sale e o Shop, que é o app de compras voltado ao consumidor. Não foi um experimento num app interno esquecido. Foi produto que fatura.

E a empresa não ficou só consumindo. Ela devolveu muita coisa para o ecossistema:

• FlashList, a lista que virou padrão para quem sofria com FlatList travando.
• react-native-skia, feita em parceria com a comunidade, para desenho e animação de alta performance.
• Contratou gente do core e patrocinou trabalho na nova arquitetura.

Então, quando uma empresa com esse histórico diz "vamos voltar pro nativo", ninguém pode acusar o time de não saber usar a ferramenta. Esse é o ponto que torna a notícia interessante.

Por que a Shopify está voltando para Swift e Kotlin

O post detalha os motivos e vale a leitura completa, direto na fonte. Não vou reproduzir o texto aqui. O que me interessa é o padrão por trás, porque ele aparece em quase todo app cross-platform que cresce muito.

A promessa do React Native sempre foi: um time, um código, duas plataformas. No começo isso é verdade. Você escreve a tela uma vez, roda no iOS e no Android, e o time anda rápido.

Com o tempo, o app amadurece e começa a pedir coisas que moram fora do JavaScript. Widget na tela inicial. Live Activities. Integração com pagamento por aproximação. Acessibilidade fina. Animação que precisa rodar a 120 Hz sem soluço. Cada uma dessas coisas vira um módulo nativo. E o código começa a ficar assim:

const CheckoutButton = Platform.select({
  ios: () => <ApplePayButton onPress={pay} />,
  android: () => <GooglePayButton onPress={pay} />,
})!

Um Platform.select isolado não é problema. Duzentos espalhados pelo app são. Chega um ponto em que você mantém três bases de código: o JS compartilhado, o Swift dos módulos de iOS e o Kotlin dos módulos de Android. E ainda precisa de gente que entenda a ponte entre os três.

Código compartilhado só economiza quando o problema também é compartilhado.

Esse é o custo que ninguém coloca na planilha quando escolhe cross-platform no primeiro dia.

React Native morreu? Não, e explico o motivo

Toda vez que uma empresa grande troca de stack, aparece alguém no X dizendo que a tecnologia acabou. Já vimos esse filme com o Airbnb em 2018, que também saiu do React Native. O framework não morreu. Pelo contrário: ganhou a nova arquitetura, o Hermes ficou muito melhor, e o Expo virou uma plataforma séria de verdade.

A decisão da Shopify diz mais sobre a Shopify do que sobre o React Native. Pense no cenário dela:

• Tem dinheiro para manter times separados de iOS e Android.
• Tem apps enormes, com anos de funcionalidades acumuladas.
• Compete em experiência. Um checkout 200 ms mais lento custa venda.
• Precisa adotar recurso novo da Apple e do Google no dia do lançamento, não três meses depois quando a lib da comunidade atualizar.

Agora compare com o cenário da maioria dos projetos que eu vejo: um time pequeno, prazo apertado, app que é basicamente formulário, lista e chamada de API. Nesse caso, contratar um dev Swift e um dev Kotlin para fazer a mesma tela duas vezes é jogar dinheiro fora.

A pergunta certa nunca foi "React Native ou nativo?". É "em que fase o meu app está e onde está o gargalo?".

A IA entra nessa conta

Tem um detalhe que mudou desde 2020 e que eu acho que pesa mais do que parece. O custo de escrever código caiu. Com agentes de IA gerando boa parte do boilerplate, portar uma tela de SwiftUI para Jetpack Compose ficou muito mais barato do que era.

Antes, o grande argumento do cross-platform era "escrever duas vezes é caro". Se a escrita ficou barata, o gargalo passa a ser outro: revisar, testar, manter e entender o código. E aí um app nativo, que usa as ferramentas oficiais da plataforma sem camada extra no meio, pode sair mais simples de manter do que um app híbrido cheio de ponte.

Não estou dizendo que foi esse o motivo da Shopify. Estou dizendo que essa conta mudou para todo mundo, e quem escolhe stack em 2026 com a cabeça de 2020 corre o risco de otimizar o custo errado.

O que muda na prática para quem usa React Native

Se você tem um app React Native em produção, não precisa entrar em pânico nem abrir uma issue de migração amanhã. Mas dá pra tirar umas lições bem concretas:

1. Conte seus módulos nativos. Rode um levantamento simples no projeto:

grep -rl "Platform.OS\|Platform.select" src | wc -l
ls ios/*/*.swift android/app/src/main/java/**/*.kt 2>/dev/null | wc -l

Se esses números crescem a cada sprint, o app está pedindo nativo e você está pagando imposto de ponte.

2. Separe o que é produto do que é plataforma. Regra de negócio, validação, estado e chamadas de API podem ficar em TypeScript puro, fora dos componentes. Se um dia você migrar, essa parte vai junto ou vira backend. Quem mistura tudo dentro de tela vai reescrever tudo.

3. Não brigue com a plataforma. Se a feature é muito específica do iOS, escreva em Swift e exponha um módulo pequeno. Tentar reproduzir em JS algo que a Apple já entrega pronto é o jeito mais caro de ficar parecido com o original.

4. Mantenha o Expo e a nova arquitetura em dia. Boa parte da dor de React Native antigo vinha da ponte assíncrona e de upgrade atrasado. Quem ficou três versões para trás sente muito mais o peso do framework.

Minha opinião sobre a volta ao nativo

Eu continuo começando app com React Native e Expo. Para o tamanho de projeto que eu e a maioria dos devs que leem este blog tocamos, ainda é a forma mais rápida de colocar algo bom nas duas lojas com um time pequeno. Minha opinião forte é esta: escolher nativo puro no dia um, para um MVP com três telas, é vaidade técnica.

Mas a Shopify mostra uma coisa que todo mundo que ama uma ferramenta precisa ouvir: stack não é time de futebol. A mesma empresa que ajudou a construir o ecossistema olhou para os números, viu que o contexto mudou e trocou. Sem drama. Isso é engenharia. Torcer pro framework e defender ele em thread é outra coisa, e ninguém paga por isso.

Se você está na dúvida sobre qual caminho seguir no seu app, dá uma olhada nos projetos que eu já entreguei e em como escolhi a stack em cada um. Spoiler: a resposta quase sempre foi "depende", só que com números do lado.

Em 2020, a Shopify disse que React Native era o futuro. Em 2026, anunciou a volta para Swift e Kotlin.

Eu uso React Native todo dia e não li isso com indiferença. Mas o framework não morreu. A decisão diz mais sobre o momento da Shopify do que sobre a ferramenta.

Código compartilhado só economiza quando o problema também é compartilhado. Com duzentos Platform.select espalhados, você já mantém três bases de código.

E a IA mudou essa conta: escrever duas vezes ficou barato. Agora o caro é revisar, testar e manter.

Para um MVP com time pequeno, eu continuo com Expo. Stack não é time de futebol, é decisão com número do lado.

No blog eu conto como escolho a stack em cada projeto. Link nos comentários.

#ReactNative #DesenvolvimentoMobile #Shopify #EngenhariaDeSoftware #Expo