Shopify está migrando de React Native de volta para Swift e Kotlin
A Shopify está reescrevendo seus apps móveis de React Native de volta para Swift e Kotlin nativos, argumentando que os agentes de codificação modernos de IA eliminaram grande parte do custo histórico de manter duas bases de código. Os comentaristas veem isso como parte de uma mudança mais ampla: se LLMs conseguem lidar com o trabalho repetitivo entre plataformas, grandes empresas podem preferir desempenho nativo, integração mais estreita com a plataforma e menos sobrecarga de framework, mesmo ao custo de perder uma stack única compartilhada. Outros alertam que paridade, testes e manutenção de longo prazo entre plataformas continuam sendo problemas difíceis, e que, para equipes menores, a economia de React Native, Flutter ou abordagens baseadas na web ainda pode ser mais convincente.
Racional percebido para a mudança da Shopify
- Muitos veem a mudança principalmente como uma forma de escapar do “imposto” do React Native: upgrades dolorosos, rotatividade de dependências e instabilidade do framework upstream.
- Outros argumentam que o verdadeiro motor é preferência e política internas, não apenas IA ou custo objetivo.
- Vários observam que a Shopify já estava sendo forçada a fazer uma grande refatoração no RN (“New Architecture”), então reavaliar a stack foi oportuno.
IA/LLMs e a economia do nativo
- Há amplo consenso de que agentes de código reduzem dramaticamente o custo de construir e portar apps nativos; vários comentaristas relatam ports rápidos, da noite para o dia, de apps pequenos a médios de RN → Swift/Kotlin.
- Defensores afirmam que “um app RN vs dois apps nativos” agora é um falso trade-off: a IA pode manter ambos, especialmente se especificações e testes forem compartilhados.
- Céticos contrapõem que a IA também torna o RN mais barato; o custo de paridade/manutenção ao longo dos anos ainda é incerto e não comprovado.
React Native, Flutter e alternativas
- O RN é descrito como funcional, porém frágil: mudanças que quebram com frequência, upgrades complicados, qualidade desigual das bibliotecas e penalidades de desempenho/UX, especialmente no Android.
- Flutter recebe tanto elogios (“ainda amo”) quanto rejeição (“beco sem saída”), com alguns dizendo que sua stack baseada em Skia é inerentemente pesada.
- Kotlin Multiplatform, Rust+UniFFI e .NET nativo são mencionados como formas melhores de compartilhar a lógica central mantendo UIs nativas.
App Store review, OTA e deployment
- Há forte discordância sobre os tempos atuais de revisão no iOS: alguns relatam menos de 24h, outros 2–7+ dias e alta variância.
- Atualizações over-the-air (OTA) do RN são vistas como uma enorme vantagem prática para correções rápidas e mudanças motivadas por compliance; críticos da mudança temem que a Shopify esteja abrindo mão disso.
Paridade, complexidade e custo organizacional
- Vários comentaristas dizem que a parte mais difícil não é a reescrita inicial, mas manter o comportamento de iOS/Android alinhado ao longo dos anos: experimentos, analytics, acessibilidade, casos de borda.
- Especificações e testes compartilhados são vistos como necessários, mas sua eficácia de longo prazo é “incerta”; as pessoas querem números concretos (horas, taxas de defeitos, incidentes de divergência, gasto com modelos).
IA, qualidade e preocupações de segurança
- Alguns abraçam o desenvolvimento “agentic” e mal leem a saída em Swift/Kotlin, confiando em testes e em revisores adicionais baseados em modelos.
- Outros alertam que isso leva a apps nativos “vibe-coded” de difícil manutenção, com bugs ocultos, problemas de segurança (segredos, OAuth, WebViews) e código frágil que os humanos não entendem de verdade.
Tendência maior
- Muitos esperam que organizações grandes e bem financiadas voltem ao nativo, enquanto equipes menores e MVPs ficarão com RN/Flutter/web.
- Vários preveem um movimento mais amplo para longe do Electron e de stacks cross-platform pesadas, à medida que o código se torna “barato”, mas a complexidade e o inchaço em runtime continuam caros.