Shopify troca React Native por Swift e Kotlin: o que muda

Em 2020, a Shopify publicou um texto com um título que virou bandeira: React Native is the future of mobile at Shopify. Seis anos depois, o mesmo blog de engenharia anuncia o caminho inverso: a empresa está tirando os apps do React Native e voltando para Swift e Kotlin. Se você tem um app em React Native em produção, ou está escolhendo a stack de um projeto novo, essa notícia merece mais do que um print com legenda irônica.

Eu trabalho com React Native todo dia. Então vou ser direto sobre o que essa decisão significa e sobre o que ela não significa.

O que a Shopify anunciou

A Shopify foi, por anos, o case mais citado do React Native fora da Meta. Migrou apps grandes, contratou gente do core, contribuiu com a New Architecture e escreveu bastante sobre o processo. Quando alguém perguntava "mas React Native aguenta app sério?", a resposta padrão era: "a Shopify usa".

Agora a empresa diz que vai voltar para nativo: Swift no iOS, Kotlin no Android. Duas bases de código, dois times de plataforma, o modelo que ela mesma tinha abandonado.

Vale ler o post original inteiro. Aqui eu quero focar no que isso significa para quem não é a Shopify, que é o caso de quase todo mundo que está lendo isto.

Por que essa decisão pesa mais que um caso isolado

Empresa trocar de stack acontece toda semana. O Airbnb saiu do React Native em 2018 e a comunidade sobreviveu. O que torna este caso diferente é o histórico.

A Shopify não usou React Native de forma superficial. Ela investiu pesado, conhecia as entranhas do framework e ajudou a melhorar o próprio React Native. Quando um time com esse nível de domínio decide sair, o motivo dificilmente é "não soubemos usar".

Isso deixa uma pergunta incômoda: se nem quem dominava a ferramenta quis ficar, o que isso diz para o resto de nós?

Minha resposta: diz muito sobre a escala da Shopify e pouco sobre o seu app.

Isso significa que o React Native morreu?

Não. E quem disser isso no LinkedIn esta semana está vendendo curso de outra coisa. (O pessoal do Flutter já está aquecendo os dedos para comentar "eu avisei", e, bem, eles também usam uma camada entre o código e a plataforma.)

O React Native resolve um problema específico: entregar um app decente nas duas plataformas com um time pequeno, reaproveitando conhecimento de React e TypeScript. Esse problema continua existindo. Uma startup com três devs não ganha nada mantendo dois apps nativos.

O que muda de figura é o ponto de equilíbrio. Em um app gigante, com dezenas de times mexendo na mesma base, o custo da camada intermediária cresce:

• Cada feature nova de iOS ou Android chega atrasada ou precisa de módulo nativo próprio.
• Bug de performance vira investigação em três camadas: JS, ponte (ou JSI) e plataforma.
• Upgrade de versão do React Native vira projeto de trimestre.
• Você acaba contratando gente de Swift e Kotlin de qualquer jeito.

Esse último ponto é o que pouca gente admite. App grande em React Native não elimina o código nativo. Ele só esconde parte dele.

O custo que aparece quando o app cresce

Quem já mantém app em produção conhece este caminho. Começa tudo em TypeScript. Aí vem um requisito de câmera customizada, widget na tela inicial, Live Activity no iOS, integração com algum SDK de pagamento. Você abre a pasta ios/ pela primeira vez em meses.

Um módulo simples com Expo Modules fica mais ou menos assim:

import ExpoModulesCore

public class ReceiptPrinterModule: Module {
  public func definition() -> ModuleDefinition {
    Name("ReceiptPrinter")

    AsyncFunction("print") { (payload: String) -> Bool in
      return PrinterSDK.shared.send(payload)
    }
  }
}

E do lado do JavaScript:

import { requireNativeModule } from 'expo-modules-core'

const ReceiptPrinter = requireNativeModule('ReceiptPrinter')

export const printReceipt = (payload: string): Promise<boolean> =>
  ReceiptPrinter.print(payload)

Fica bonito. Agora multiplique por 40 módulos, duas plataformas, testes em cada uma e um time que precisa entender os três lados. Em algum momento a conta vira: você está mantendo um app nativo e um app em React Native ao mesmo tempo.

Uma base de código só é mais barata enquanto você não precisa brigar com ela.

O que mudou desde 2020

Aqui entra uma leitura minha, não necessariamente o argumento da Shopify.

Em 2020, o argumento mais forte do React Native era econômico: escrever a mesma tela duas vezes custa caro. Hoje, com agentes de código escrevendo boa parte do código repetitivo, esse custo caiu bastante. Pedir para um agente portar uma tela de SwiftUI para Jetpack Compose não é de graça, mas está longe de ser o dobro do trabalho.

Quando escrever código fica mais barato, o que pesa mais é o custo de manter e depurar. E nessas duas coisas o nativo tem vantagem: menos camadas, documentação oficial, ferramentas da própria Apple e do Google, nenhuma dependência esperando atualização da comunidade.

Isso não vale para todo mundo. Agente nenhum substitui alguém que entende de verdade o ciclo de vida de uma view no iOS. Mas o argumento "uma base de código porque código é caro" perdeu força, e acho que mais empresas vão refazer essa conta nos próximos anos.

Quando React Native ainda faz sentido no seu app

Minha regra prática, depois de alguns apps entregues:

• Time pequeno, produto validando mercado: React Native com Expo, sem pensar duas vezes. Velocidade importa mais que tudo.
• App que é basicamente formulário, lista e chamada de API: React Native. O ganho do nativo ali é quase invisível para o usuário.
• Você já tem time web forte em React: React Native aproveita esse conhecimento como nada mais faz.
• App que depende de hardware, gráficos pesados ou recursos novos da plataforma no dia do lançamento: comece a considerar nativo seriamente.
• Dezenas de devs mobile e orçamento para times por plataforma: aí sim você está no território da Shopify.

Se você está nos três primeiros grupos, a notícia da Shopify não muda nada no seu backlog de segunda-feira.

O que eu faria hoje

Se eu fosse começar um app amanhã, para a maioria dos clientes que atendo, continuaria no React Native com Expo. Para 90% dos apps que vejo, trocar por nativo hoje seria uma decisão cara para resolver um problema que eles não têm.

Mas eu levaria duas lições da Shopify. Primeiro: trate a pasta ios/ e a android/ como código de primeira classe, com gente no time que saiba mexer nelas. Segundo: escolha de stack não é casamento. A Shopify mudou de ideia duas vezes em seis anos, e está tudo bem. A decisão certa em 2020 pode ser a errada em 2026, porque o contexto mudou.

O erro é copiar a decisão de uma empresa com milhares de engenheiros achando que ela vale para um time de quatro pessoas. Olhe o seu tamanho, o seu produto e o seu time. Se quiser ver como eu tenho resolvido isso na prática, alguns apps estão nos meus projetos.

Em 2020 a Shopify disse que React Native era o futuro. Em 2026 ela está voltando para Swift e Kotlin.

Uso React Native todo dia, e minha leitura é simples: essa decisão diz muito sobre a escala da Shopify e pouco sobre o seu app.

Em app gigante, com dezenas de times, a camada intermediária cobra caro. Upgrade vira projeto de trimestre, bug vira investigação em três camadas e você acaba contratando dev Swift e Kotlin de qualquer jeito.

E tem um detalhe novo: com agentes escrevendo o código repetitivo, escrever a mesma tela duas vezes ficou bem mais barato. O que pesa agora é manter e depurar.

Para time pequeno, produto validando mercado ou app de formulário e API, React Native com Expo continua sendo a escolha certa. Stack não é casamento, mas copiar a decisão de uma empresa com milhares de engenheiros também não é estratégia.

Escrevi a análise completa no blog. Se você está nessa dúvida com o seu app, me conta como está pensando.

#ReactNative #MobileDevelopment #Swift #Kotlin #Expo