TL;DR — o essencial em 60 segundos
- A Shopify anunciou (10/09/2026) que está migrando seus apps mobile de React Native para código nativo — Swift (iOS) e Kotlin/Jetpack Compose (Android) — usando coding agents para absorver o custo de construir para duas plataformas.
- Não é “React Native falhou”. Os apps RN da própria Shopify eram rápidos e estáveis — como mostraram em janeiro de 2025. O que mudou foi a economia: agentes baratearam a tradução entre plataformas, o ramp-up cross-stack e a manutenção de paridade. A premissa central de 2020 (“construir duas vezes custa o dobro”) deixou de valer.
- O Shop app foi do proof of concept à publicação nas lojas em 12 semanas, com um core de 6 engenheiros. O app Shopify (300+ telas, widgets, Apple Watch, Siri Shortcuts) está em migração.
- Resultados medidos vs. React Native: startup −50% (Android) e −23% (iOS); app Android −37% (−109 MB); build Android ~−75%; estabilidade de 99,5% → 99,95% (10× menos sessões com crash); 120 FPS no Android com pouca otimização.
- One-shot não funciona. Apontar um LLM direto para o codebase produz “slop” não manutenível. A Shopify construiu o Helix: um loop de checkpoints com gates — testes, revisão visual contra o app rodando, 2 revisores adversariais e aprovação humana — antes de cada commit.
- A lição central: com agentes, arquitetura (modularidade, lógica de negócio desacoplada da UI, testável sem simulador) virou o fator decisivo — para humanos e para máquinas. O caminho mais rápido para agentes úteis não é um modelo melhor: é uma arquitetura que o agente consegue dirigir em milissegundos.
O que aconteceu
Em 10 de setembro de 2026, a Shopify Engineering publicou o artigo “Native is now the future of mobile at Shopify”, assinado por Mustafa Ali (Head of Mobile). O texto reverte publicamente a aposta que a empresa tinha feito em 2020 no React Native — uma decisão que, por seis anos, foi o maior estudo de caso de sucesso de framework multiplataforma em uma empresa de grande porte.
A notícia correu o mundo (InfoQ, The New Stack, Hacker News, Reddit) e reacendeu um debate antigo com um argumento novo: a justificativa da Shopify não é performance — é a mudança de custo causada por agentes de IA.
“Não mantemos uma decisão só porque ela foi bem-sucedida na época. Quando uma premissa central muda, estamos dispostos a voltar e perguntar se ainda é a decisão certa. Os LLMs mudaram uma das premissas centrais por trás da nossa decisão de 2020, então reavaliamos nossa stack mobile a partir dos primeiros princípios.”
Mustafa Ali, Native is now the future of mobile at ShopifyO vídeo brasileiro que originou este estudo (transcrição fornecida) analisa exatamente esse movimento, e o apresentador resume bem a postura correta diante da notícia: “Esse canal não é o canal do profeta do apocalipse (…) mas eu acho que é uma perspectiva muito legal você pensar na possibilidade que você tem de ter mais liberdade de escolha de tecnologias.”
A primeira metade documenta a decisão e o método (fontes primárias: dois artigos oficiais da Shopify). A segunda metade traz os contrapontos (incluindo críticas dos comentários do vídeo, do Reddit e do Hacker News) e as lições transferíveis para qualquer time — mesmo quem nunca vai migrar um app mobile.
2020 → 2026: como a premissa mudou
A aposta: “React Native is the future of mobile at Shopify”
A Shopify foi all-in no React Native por três motivos: (1) parar de construir a mesma feature duas vezes; (2) permitir que devs sem background mobile contribuíssem nos apps; (3) gastar menos tempo caçando paridade de features e mais tempo entregando valor.
LLMs na Shopify — um ano antes do ChatGPT
A empresa começou a usar LLMs para implementar features, investigar e corrigir bugs e revisar código. Conforme os modelos melhoraram, a complexidade do trabalho confiado a eles cresceu junto.
“Five years of React Native” — futuro brilhante… com ressalvas
A retrospectiva era positiva (loads abaixo de 500 ms no P75, mais de 99,9% de sessões sem crash). Mas o texto já dizia: nativo continua sendo a melhor escolha para features que exploram hardware (scanners 2D/3D, IA on-device), widgets, Apple Watch, App Intents, Siri Shortcuts e jobs em background. A frase-chave: “Em vez de pensar em nativo ou React Native, pense em nativo e React Native.”
O ponto de virada
Os modelos de código melhoram dramaticamente. Os agentes passam a: implementar uma feature no Android usando a versão iOS como referência (e vice-versa), ajudar devs a contribuir fora da stack primária e reduzir o custo de manter paridade via specs, testes e checkpoints compartilhados. Nas palavras da Shopify: agentes “não estavam mais apenas nos ajudando a escrever código mais rápido. Eram capazes de nos fazer questionar se construir software duas vezes ainda significava fazer o dobro do trabalho.”
O anúncio e a migração em curso
“Native is now the future of mobile at Shopify.” O Shop app já foi reconstruído e publicado como app nativo. O app Shopify (o maior, com 300+ telas) está em migração; Point of Sale e Inbox vêm na sequência. Dois catalisadores internos: a adoção da New Architecture do React Native exigiria um grande refactor (módulos nativos, renderização, fronteiras de código) — o momento perfeito para reavaliar tudo.
Por que voltar ao nativo
A Shopify estruturou a decisão em cima das três premissas originais de 2020. Repare que nenhuma delas “quebrou” — todas foram enfraquecidas pelos agentes:
1 · “Não construir duas vezes”
A tradução entre plataformas deixou de ser o gargalo econômico. Agentes implementam uma feature no Android usando o iOS como referência — e o inverso — respeitando os padrões de cada plataforma.
2 · “Devs em toda a stack”
Agentes ajudam desenvolvedores a contribuir efetivamente fora da stack primária. Seu melhor engenheiro iOS consegue conduzir uma migração Kotlin, porque o agente cobre boa parte do trabalho específico de plataforma.
3 · “Menos tempo caçando paridade”
Specs compartilhadas, testes e checkpoints de review deixam os agentes carregarem a maior parte da carga de paridade que uma codebase única absorvia.
“Nativo ainda significa construir e manter software em duas plataformas — esse custo não desapareceu. O que mudou é que os agentes agora conseguem fazer trabalho suficiente de implementação, tradução, teste e revisão para que ele deixe de ser o fator decisivo que era em 2020.”
Mustafa Ali, Native is now the future of mobile at ShopifyE a Shopify é explícita para não transformar isso numa guerra de frameworks:
“Apps React Native podem ser rápidos. Os nossos são. Estamos fazendo essa mudança porque os agentes reduziram as vantagens de compartilhar a implementação, enquanto as vantagens de construir para cada plataforma continuam.”
Mustafa AliDo outro lado da balança: os custos que ficaram
Mesmo antes da IA, a Shopify gastava recursos significativos otimizando performance no React Native, melhorando áreas fundamentais do framework e acompanhando atualizações e dependências externas. Nativo mantém o código mais perto das capacidades da plataforma e do tooling first-party, com menos camadas entre o código e o sistema operacional.
Não segure uma decisão por orgulho nem a troque por hype. Identifique a premissa em que sua escolha de stack se apoia (custo de duplicação? disponibilidade de talento? ecossistema?) e monitore quando ela muda. A Shopify levou 6 anos — e teve coragem de re-perguntar.
Os números do Shop app: React Native × nativo
O primeiro app migrado foi o Shop — um dos apps de compras mais baixados do mundo, com centenas de milhões de clientes. Antes de decidir, a Shopify rodou um proof of concept de 1 semana com 1 engenheiro: usando o app React Native como referência, os agentes portaram a maior parte do app para um app iOS nativo em SwiftUI. Não ficou production-ready, mas provou que uma migração fiel, feature a feature, era viável.
Depois disso, um core de 6 engenheiros construiu as fundações nativas e os principais fluxos; os feature teams entraram no meio do caminho para validar suas áreas. Prioridades: comportamento idêntico, eventos de analytics preservados, usuários logados mantidos e push notifications funcionando — a migração tinha que parecer uma atualização normal de app.
| Métrica | Nativo | React Native | Diferença |
|---|---|---|---|
| Startup iOS (cold start) | 2.466 ms | 3.200 ms | −23% |
| Startup Android (cold start) | 2.233 ms | 4.433 ms | −50% |
| Tamanho do app iOS (release) | 68 MB | 67 MB | +1 MB (+1,5%) |
| Tamanho do app Android (release) | 184 MB | 293 MB | −109 MB (−37,2%) |
| Build time Android (release) | Aprox. −75% | Baseline | ~4× mais rápido |
| Build time iOS (release) | Aprox. igual | Baseline | ≈ |
| Estabilidade de sessão | 99,95%+ | 99,5%+ | 10× menos crashes |
O iOS ficou essencialmente igual em tamanho (+1,5%) — o ganho de tamanho é um fenômeno Android (o runtime do RN + dependências pesam). E a própria Shopify diz que a primeira versão nativa “elevou o teto” de performance: ela é a baseline, não o destino final. Note também: os comparativos foram feitos contra o React Native na arquitetura antiga — um ponto central do debate (veja a seção 10).
“Apontar o LLM e rezar” produz slop
A parte mais valiosa do relato da Shopify é o que não funcionou. A tentação óbvia — apontar um LLM para o codebase React Native e pedir a versão nativa das mesmas features de uma vez — foi testada e rejeitada:
“É tentador simplesmente apontar um LLM para o codebase React Native e tentar replicar as mesmas funcionalidades nativas de uma vez, mas isso não funciona. Mesmo que você peça para ele coletar o máximo de informações antecipadamente, congelá-las em especificações e arquivos de tarefas e depois implementá-las, você termina com uma quantidade enorme de código não manutenível que não pode ser entregue.”
Mustafa Ali, Native is now the future of mobile at ShopifyVale dizer o mesmo sem rodeios, como o próprio vídeo destaca: isso não é vibecoding. É engenharia séria — com especificação, testes, revisão e arquitetura — usando agentes como capacidade de execução. A máquina que constrói o prédio precisa ser tão inteligente quanto o prédio.
Helix: o loop anti-slop da Shopify
Para resolver o problema do slop, a Shopify construiu um sistema interno chamado Helix. A filosofia central dele cabe em uma frase:
“A primeira saída não é esperada como correta. Uma tentativa imperfeita simplesmente não pode avançar até se tornar um bom resultado.”
Paráfrase do artigo Native is now the future of mobile at ShopifyNa prática, o fluxo funciona assim:
Apontar
O desenvolvedor aponta o Helix para uma tela. Ele lê o código React Native de origem.
Fatiar em checkpoints
O Helix propõe uma sequência de checkpoints — pequenas fatias ordenadas de trabalho, revisáveis em minutos (não um “big bang” de migração).
Provar comportamento com testes
Cada checkpoint precisa demonstrar seu comportamento com testes antes de seguir.
Revisão visual contra o app rodando
O resultado precisa bater com o app em execução (comparação visual lado a lado).
Sobreviver a 2 revisores adversariais
Dois agentes revisores “adversariais” tentam encontrar problemas no código gerado.
Aprovação humana
Só com o “ok” de um humano o checkpoint é commitado — e aí o próximo começa.
Memória de feedback
O feedback de cada review é memorizado, então o loop fica mais autônomo conforme a migração avança.
O ferramental ao redor do Helix
- Extensão para o coding agent Pi + subagentes especializados: agentes inspecionam o código RN, documentam comportamento (UI, estado, navegação, analytics, acessibilidade, dados), preparam planos por plataforma, implementam features e revisam paridade.
- Aprovação de plano amarrada a hash: a aceitação de um plano é vinculada ao hash do seu conteúdo — se o plano mudar, a aprovação anterior é invalidada. O humano aprova exatamente o que foi executado.
- Tardis (debug para agentes): acesso estruturado a eventos, logs e estado do app nativo ao vivo, além de envio de comandos. Ganhou um modo que captura screenshots e janelas de eventos do app RN e do nativo em checkpoints nomeados, permitindo comparar nomes, contagens e payloads de eventos — ignorando diferenças naturais entre execuções (timestamps, UUIDs de página) e checando as relações entre eventos e seus contextos.
- Expertise nativa continua essencial: a própria Shopify alerta que código gerado pode satisfazer requisitos e ainda assim introduzir duplicação, architectural drift e problemas de performance. Guidance no repositório, lint, testes, análise estática, checagens de performance e code review seguem no caminho crítico.
O padrão do Helix — fatiar em checkpoints pequenos + gates de qualidade + memória de review + aceitação humana — é o formato que funciona para qualquer refatoração/migração conduzida por agentes, em qualquer stack. É o oposto do one-shot: em vez de confiar no acerto de primeira, o sistema impede que a imperfeição avance.
Arquitetura para agentes: feedback em milissegundos
O gargalo que a Shopify encontrou não era a qualidade dos modelos. Era o ciclo de feedback: agentes editam código em segundos, mas testar o resultado em um simulador mobile levava minutos — porque para “enxergar” o app, os agentes dependiam da accessibility tree ou de screenshots. Nas palavras deles:
“Não importa quão bom seja o modelo se ele não consegue testar seu trabalho rapidamente — o que é especialmente difícil em mobile.”
A solução foi arquitetural, não relacionada a modelo. O princípio central: lógica de negócio completamente desacoplada da UI, capaz de rodar headless no desktop. Isso é então exposto aos agentes via uma CLI que permite:
- Inspecionar o estado do app, navegar entre seções e executar ações sem tocar na UI — iterações em milissegundos em vez de minutos.
- Modo remoto: quando interação real com a UI é necessária, a CLI se conecta aos simuladores e dirige a interface por comandos — sem inspecionar layout nem accessibility tree, com performance muito superior para E2E.
- Resultado: agentes capazes de trabalhar de forma autônoma por horas a fio.
O caminho mais rápido para agentes úteis não é um modelo melhor — é uma arquitetura que o agente consegue dirigir com latência de milissegundos. Aproxime a lógica de negócio dos testes rápidos (headless, CLI, desktop) e deixe a UI para validação final. Isso ecoa a reflexão do vídeo que originou este estudo: código modular, com responsabilidades claras, é mais fácil para humanos e para agentes.
O que acontece com o ecossistema React Native da Shopify
A Shopify construiu bibliotecas open source que se tornaram padrão de mercado no React Native. O plano de saída foi desenhado para não deixar a comunidade na mão:
React Native Skia
A Shopify patrocina o projeto até o fim de 2026. William Candillon continuará trabalhando nele além disso: fará um fork do repositório e passará a publicar a biblioteca sob um novo nome. O repo original será arquivado ao final da transição. Usuários são encorajados a patrocinar.
FlashList
~2 milhões de downloads/semana — a forma padrão de renderizar listas performáticas em RN. A Shopify continuará corrigindo problemas críticos de compatibilidade e está em conversas com várias empresas para assumir a stewardship de longo prazo. É o item mais crítico para o ecossistema.
Restyle
Base de usuários menor. Continuará funcionando até o fim de 2026 e depois deixará de ser mantido. Forks são bem-vindos e a Shopify oferece ajuda no handover.
Para times com produção rodando em FlashList, acompanhar as negociações de stewardship é o item mais acionável dessa história.
Nem todo mundo comprou a narrativa
O anúncio gerou discussão intensa — nos comentários do vídeo-fonte, no Reddit (r/reactnative), no Hacker News e na imprensa técnica. Um estudo honesto precisa registrar os contrapontos:
1 · A comparação é com a arquitetura antiga do React Native
Na InfoQ e no Reddit, o ponto mais citado: a migração aconteceu exatamente no momento em que a Shopify avaliaria adotar a New Architecture do React Native. Os resultados publicados medem o RN na arquitetura antiga — se a New Architecture tivesse sido adotada, parte da diferença de startup/perf poderia encolher. A própria Shopify admite o contexto: o refactor da New Architecture foi um dos gatilhos para reavaliar tudo.
2 · Custo de tokens: viável para quem?
“No momento isso só é viável para empresas que podem pagar por tokens quase que infinitos, ou que tenham sua própria LLM. Até para grandes empresas como a que eu trabalho tá tendo que economizar tokens.”
@inaciojunior117 — comentário no vídeoO subsídio atual dos modelos é tratado como temporário por vários desenvolvedores. Se a conta de tokens mudar, a equação de “construir duas vezes com agentes” muda junto. “No dia em que as LLMs forem inviáveis financeiramente, voltamos para as abstrações”, resumiu um dos comentaristas — com respostas discordando veementemente nos dois sentidos.
3 · Atualizações OTA (over-the-air)
Em nativo, atualizar o app significa passar pelo review das lojas. Em React Native, updates over-the-air faziam parte do fluxo de entrega. No Hacker News, desenvolvedores apontaram essa perda operacional — e um deles ofereceu a leitura cultural interessante:
“Com nativo, você sabe que cada release é mais difícil de reverter, então tende a construir mais ferramentas em volta de releases, pensar com mais cuidado e testar mais antes de shippar. Você opta por um release maior e mais estável a cada poucas semanas.”
Desenvolvedor no Hacker News (citado pela InfoQ)4 · Dois sistemas = dois débitos
“Ter um sistema para cada plataforma implica em ter sistemas a mais para você revisar, e se as coisas diferirem, as histórias dos sistemas diferirem, quem pega essas nuances?”
@sonsoriak — comentário no vídeoÉ o custo que a Shopify reconhece não ter desaparecido — apenas deixado de ser decisivo. Código gerado que “atende requisitos” mas introduz duplicação e drift arquitetural é um risco explícito no próprio artigo oficial. Manter paridade de comportamento para sempre entre duas codebases nativas vai continuar exigindo processo e gente boa.
5 · Ceticismo sobre incentivos
“Essas empresas são muito irresponsáveis ao divulgar esses números dessa forma (…) com certeza, as fornecedoras de IA estão por trás dessas empresas para divulgar esses números.”
@marcelosantanna6007 — comentário no vídeoNão é preciso concordar com a teoria da conspiração para aproveitar o lembrete: todo estudo de caso corporativo tem incentivos próprios, e números de contexto específico (app gigante, time sênior, infraestrutura de agentes, poder de compra de tokens) não se transferem automaticamente para contextos menores.
6 · “A maior vantagem ainda não foi superada”
“90% dos apps podem ser multiplataforma (…) a maioria [é] login → consumir API → listar dados → formulário → câmera/GPS → push → pagamento (…). Nada muito robusto para ter a necessidade de manter dois codebases. Então calma lá, a maior vantagem ainda não foi superada.”
@canal32983 — comentário no vídeoE há o argumento simétrico que muita cobertura ignorou: a IA também acelera o React Native. “A vantagem do RN era 1 codebase para 2 plataformas. A IA deixou mais rápido desenvolver dois apps nativos, e deixou ainda mais rápido desenvolver React Native” (@gabrielnbds). A decisão da Shopify não é a decisão da sua empresa.
Do outro lado da balança
- Experiências independentes confirmam o padrão: um desenvolvedor relatou ter construído o mesmo app (controle de túneis SSH, com criptografia e chaves) em três plataformas — Windows, Linux e Android — cada uma na linguagem mais nativa, em questão de horas, mantendo funcionalidades idênticas: “se fosse sem IA, levaria meses” (@DhenysonJhean).
- O padrão é maior que mobile: Jarred Sumner (criador do Bun) usou 64 instâncias paralelas de Claude para portar o runtime de Zig para Rust — cerca de 1 milhão de linhas em 11 dias, custo estimado de ~US$ 165 mil, com a suíte de testes passando nas seis plataformas suportadas antes do merge (The New Stack).
- E não é via de mão única: em maio de 2026, Simon Willison relatou o caso inverso — uma empresa consolidando seus apps iOS + Android em um único React Native com agentes. Conclusão: cada direção depende do contexto; não existe “sentido da história”.
Lições transferíveis
- Reavalie premissas, não conclusões. A Shopify não anunciou “React Native é ruim”; ela identificou a premissa central de 2020 (“construir duas vezes custa o dobro”) e verificou se ela ainda valia. Faça o mesmo com as decisões da sua stack — especialmente as que “deram certo”.
- “Build once” deixou de ser fosso. Quando agentes traduzem Swift ↔ Kotlin (ou qualquer par de stacks), a codebase única vira uma restrição menos necessária — e as vantagens de estar perto da plataforma voltam a pesar.
- Arquitetura importa mais, não menos. Código modular e com responsabilidades claras é mais fácil para agentes: o custo de mudança cai de “mexer em 200 arquivos” para “mexer em 5”. Código acoplado e macarrônico penaliza a IA muito mais do que penaliza o humano — porque o agente paga esse custo em tokens, contexto e erro.
- Projete para agentes: desacople a lógica da UI. O maior ganho da Shopify não veio de um modelo melhor — veio de tornar a lógica de negócio executável e testável sem simulador, via CLI headless. Feedback em milissegundos > minutos.
- Nada de one-shot. A primeira saída é assumida como imperfeita. Gates sequenciais (testes → revisão visual → revisão adversarial → humano) transformam geração de código em software entregável.
- Memorize o feedback dos reviews. O loop do Helix fica mais autônomo a cada checkpoint porque aprende com as revisões — um design que qualquer pipeline de agentes pode copiar.
- Fundamentos > frameworks. Quanto mais liberdade de escolha de tecnologia a IA oferece, mais quem entende arquitetura, modularização e princípios decide melhor — e dirige a IA melhor. Como diz o vídeo-fonte: “cada vez menos pensar em termos de tecnologia e cada vez mais pensar na solução, pensar no cliente, pensar em entregar valor.”
- Custos e maturidade entram na conta. Tokens, estabilidade dos modelos, infraestrutura de agentes, review gates e expertise nativa — a equação funciona nas condições da Shopify. Antes de copiar a conclusão, verifique se você tem as mesmas condições.
Não é “React Native morreu” nem “nativo venceu”. É: quando o custo de construir duas vezes cai, a decisão de stack muda de eixo — de economia de duplicação para qualidade de execução. E a qualidade de execução, na era dos agentes, se compra com arquitetura: modularidade, separação de camadas, testabilidade fora da UI e loops de feedback rápidos.
Fontes
- Primária Native is now the future of mobile at Shopify Shopify Engineering (Mustafa Ali) — o anúncio da migração, motivos, Helix, arquitetura para agentes e o futuro das bibliotecas open source.
- Primária Migrating Shop app from React Native to native Shopify Engineering (Max Da Silva, Jason Kim, Quique Fagoaga) — o relato completo da migração do Shop app: POC, números comparativos, Pi extension, Tardis e aprendizados.
- Primária Vídeo: “A IA acabou com a maior vantagem do React Native” Canal brasileiro de arquitetura — análise do anúncio da Shopify; transcrição e 49 threads de comentários usadas como ponto de partida e fonte das reações da comunidade.
- Cobertura Shopify Drops React Native for Swift and Kotlin as AI Changes Cross-Platform Development Tradeoffs InfoQ — análise do anúncio, contexto da New Architecture, o debate sobre OTA updates e a cultura de releases nativa.
- Cobertura Shopify spent years on React Native — then rebuilt everything in 12 weeks The New Stack — inclui o paralelo com o port do Bun (64 instâncias de Claude, ~1M linhas, 11 dias) e o caso inverso relatado por Simon Willison.
- Cobertura Shopify Is Moving Its Mobile Apps Back to Native. Coding Agents Made It Cheaper to Build Twice Than to Share One Codebase. DEV Community — a melhor explicação da virada econômica: “‘construir só uma vez’ deixa de ser um fosso quando agentes traduzem entre plataformas”.
- Discussão Reddit — r/reactnative: discussão do anúncio Contraponto da “arquitetura antiga”: os números podem ser outros sob a New Architecture.
- Discussão Hacker News — thread do anúncio Debate sobre OTA updates, cultura de releases nativa e trade-offs de velocidade de entrega.
Estudo compilado em 27/09/2026. Citações traduzidas livremente do inglês; trechos de comentários preservam a redação original dos autores.