Shopify abandona React Native y vuelve a Swift y Kotlin gracias a la IA
Shopify moves back to Native from React Native
Shopify había apostado fuerte por React Native desde 2020, pero los avances de los LLM cambiaron el cálculo. Ahora reconstruye sus apps móviles en Swift y Kotlin con agentes que traducen código, generan pruebas y revisan cambios. Con Helix, su sistema de checkpoints, la app Shop pasó de prototipo a versión nativa publicada en 12 semanas. La compañía también reorganiza sus librerías open source: Skia y FlashList seguirán, Restyle se archiva.
No nos aferramos a una decisión solo porque fue exitosa en su momento. Cuando una suposición central cambia, estamos dispuestos a volver atrás y preguntarnos si sigue siendo la decisión correcta.
- Waterluvian
Si colocas a todas las empresas que necesitan o tienen una app en un espectro, hay una línea en algún lugar que las divide más o menos en dos grupos: donde Electron/React Native/etc. tiene sentido o no. Es simplemente una decisión normal de ingeniería: resolver problemas con recursos limitados. Las empresas tienen problemas diferentes y recursos diferentes.
Creo que la gente en la comunidad tecnológica probablemente también ha notado que es bastante popular tener una opinión absoluta sobre lo bueno o malo de estas herramientas. Hay cierto pensamiento mágico nacido de la ignorancia de que todos deberían ir a nativo o que React Native es lo mejor que existe para usarse en todas partes o que la IA hace que esta línea desaparezca por completo.
Creo que estas opiniones aportan poco valor y distraen de lo interesante, y de lo que dice el subtítulo de este artículo: que esta línea se está moviendo debido a la IA. Y creo que eso es probablemente cierto.
- tonic_note
Los modelos han mejorado mucho generando apps nativas de iOS. El principal atractivo de RN era poder aprovechar a tus desarrolladores web para el desarrollo móvil. Eso es lo que hice en mi última empresa. Y está bien para una startup, pero eventualmente quieres ingenieros nativos dedicados porque cada plataforma realmente merece sus propios maestros técnicos que puedan optimizar para ella.
Pero ahora que todo el código se genera, hay poca ventaja en tener una app RN... simplemente empieza nativo. Tus desarrolladores apenas van a escribir código de todos modos.
- atonse
Hicimos lo mismo: tuvimos el 90% de la noche a la mañana. Luego pasamos unos días en segundo plano ajustando para pulir.
Nuestra app es más pequeña y tiene unas 15-20 pantallas. Empecé alrededor de las 12:30 a.m. dándole a codex un objetivo e inventarió cada pantalla basándose en el código de react native, luego creó directorios de android e iOS, usó maestro (ya había configurado esta herramienta para una compilación de app personal previa unas semanas antes), y tenía todo funcionando en android e iOS por la mañana. Le tomó unas 6 horas mientras dormía.
La app es mucho más pequeña, se lanza al instante, y la app de android es (supuestamente) de aspecto nativo. Digo supuestamente porque no uso teléfonos android. Pero usa Jetpack Compose y Kotlin.
Y no sé Swift ni Kotlin. Honestamente, ya no le veo el sentido a React Native. Sé que Expo está haciendo cosas agénticas muy cool, pero no estoy seguro de por qué necesitaría algo de eso cuando puedo escribir una app nativa.
- pkaler
Estoy sentado aquí en mi escritorio con vista a Cordova Street. La calle que le da nombre a Apache Cordova. He visto este debate durante casi dos décadas.
Los equipos se lanzan al último framework multiplataforma asumiendo que reducirá el costo de personal a expensas de tener una app de mínimo común denominador en cada plataforma.
Lo segundo es cierto pero lo primero es falso.
Lo que termina pasando es que los equipos empiezan con 20 ingenieros de iOS y 20 de Android. Adoptan algo como React Native. Y terminas con un equipo de 20 ingenieros de producto y 20 ingenieros de herramientas y frameworks.
He visto eso incontables veces en las últimas dos décadas.
- fnthawar2
No nos aferramos a una decisión solo porque fue exitosa en su momento. Cuando una suposición central cambia, estamos dispuestos a volver atrás y preguntarnos si sigue siendo la decisión correcta. Los LLM cambiaron una de las suposiciones centrales detrás de nuestra decisión de 2020, así que reevaluamos nuestro stack móvil desde primeros principios.
Lo que encontramos nos llevó de vuelta a nativo.
- netshade
Estoy de acuerdo con aconsejar a la gente que se aleje de React Native, aunque creo que la historia de que "los LLM permitieron una migración que de otro modo sería demasiado costosa de considerar" no es correcta.
Digo esto porque fui parte de una migración de una app React Native de tamaño mediano a una reescritura nativa en Swift/Kotlin. Hice la mayor parte del trabajo técnico. La mayor parte del trabajo ocurrió antes de enero de 2026 y sin asistencia de código de LLM, aunque las funciones posteriores de la app definitivamente usaron algo.
Para cualquiera que esté considerando esto, diría que la migración definitivamente vale la pena considerarla incluso sin tomar en cuenta la asistencia de LLM. El impuesto continuo de React Native de actualizaciones innecesariamente difíciles, desajuste de impedancia con los frameworks centrales subyacentes, y calidad de bibliotecas increíblemente desigual simplemente hacen que tu negocio realmente gaste mucho tiempo guiando la tecnología hasta la meta. Es bastante maravilloso estar de vuelta en el mundo de "construir, compilar, enviar, estar seguro". Una cosa como principio fundamental que creo que el artículo de Shopify 'capta' es la importancia del ciclo de retroalimentación: invertir tiempo en nuestra historia de pruebas de integración muy temprano ayudó tanto con mis tiempos de ciclo como, más tarde, a proporcionar barandillas para la asistencia de LLM.
En resumen, esta decisión vale la pena considerarla incluso sin tomar en cuenta la asistencia de LLM.
- lmf4lol
Ayer, justo antes de acostarme, apunté Astra a nuestra app de escritorio Electron y le pedí que me escribiera una app nativa en Swift para iOS.
La app de electron tiene 750 pruebas unitarias y 50 y algo pruebas de integración. También tenía acceso a la app de electron vía mcp y podía hacer clic e inspeccionarla. También le di a Astra acceso de solo lectura al código del backend.
Trabajó durante 3 horas y entregó un port casi completo en funcionalidad. Hoy, encontré en pruebas manuales 3 bugs y 1 problema de rendimiento, todos los cuales arregló después. Para arreglar el problema de rendimiento, hizo varias compilaciones diferentes y las perfiló con Xcode.
Alrededor de las 12:30 tenía un port completo de app nativa de nuestro producto en mi iPhone y iPad y podía mostrárselo a mi equipo. ¡Incluso hizo vertical y horizontal correctamente!
Ni que decir que me quedé estupefacto. Por un lado, me encanta, ahora puedo construir todas esas cosas geniales, pero por otro lado, es una devaluación completa de mi oficio. Me digo a mí mismo que todavía fui yo quien configuró un entorno adecuado para ello y que no todos pueden hacerlo. pero eso es autoengaño. Maldito autoengaño... y lo sé.
- underdeserver
Y yo aquí sentado mirando la app de escritorio de Codex para Mac preguntándome por qué una lista, una ventana de chat y una caja de texto requieren una descarga de 579 MB (comprimida) y 4 GB de RAM.
- jrochkind1
No estoy siguiendo del todo la parte sobre el/los simulador(es), probablemente porque nunca he hecho desarrollo móvil.
> Cuando se necesita interacción con el simulador, la CLI puede conectarse a ellos mediante un modo remoto y controlar la UI mediante comandos sin tener que inspeccionar el diseño o el árbol de accesibilidad. Esto permite un rendimiento ultrarrápido y pruebas E2E.
Creo que no lo entiendo. ¿No necesitas seguir probando el árbol de accesibilidad y el diseño en la capa real con la que el usuario interactuará?
- asimovDev
¿Dejar React y volver a JavaScript puro a continuación?
Todavía estoy de luto por el GitHub pre-React. Quizás gafas de color rosa, pero era tan agradable de usar.