Shopify abandona React Native: qué significa para usted

Shopify se está alejando de React Native. El 10 de septiembre de 2026, el responsable de móvil de la empresa, Mustafa Ali, publicó dos artículos de ingeniería en los que explicaba que las aplicaciones de Shopify se están reconstruyendo en Swift y Kotlin, con una base de código por plataforma de nuevo. La aplicación Shop ya se lanzó como una versión completamente nativa. La aplicación principal de Shopify, con más de 300 pantallas, una app para Apple Watch y widgets de pantalla de bloqueo, es la siguiente, y está prevista para este año.

Lo que hace que esto merezca la pena leer es el momento. En enero de 2025, esa misma persona escribió un artículo llamado «Cinco años de React Native en Shopify» y le dijo al sector que si no habían probado React Native en un tiempo, ahora era un buen momento para volver a mirarlo. Veinte meses después está migrando fuera de él. No es una empresa que dejó de querer un framework. Es una empresa que vio cómo una de sus suposiciones fundamentales cambiaba y tuvo el valor de decirlo en público.

La suposición era el coste. Shopify se pasó a React Native en 2020 para dejar de construir cada funcionalidad dos veces. Ali es directo: «Las aplicaciones de React Native pueden ser rápidas. Las nuestras lo son.» El motivo para abandonarlo no es el rendimiento. Es que los agentes de codificación con IA llegaron a ser suficientemente buenos como para que escribir la misma funcionalidad en Swift y Kotlin ya no cueste lo que costaba antes. Una vez que un agente puede encargarse de gran parte de la segunda implementación, el argumento principal para una base de código compartida se debilita, mientras que las ventajas de ir a nativo, más cerca de la plataforma y con menos capas de dependencias, siguen exactamente donde estaban.

Los números son reales. Reconstruida en nativo, la aplicación Shop redujo el tiempo de arranque en frío un 23% en iOS y un 50% en Android. Las sesiones con fallos cayeron aproximadamente diez veces, pasando de una estabilidad de sesión del 99,5% al 99,95%. Las compilaciones de lanzamiento de Android son un 75% más rápidas, el binario de Android se redujo en 109 MB y el feed mantiene 120 FPS mientras se desplaza. Seis ingenieros la llevaron del concepto a la App Store en 12 semanas, tras que un único ingeniero pasara una semana demostrando que la idea podía funcionar.

Dónde le frenamos nosotros

El titular que todo el mundo compartió es «la IA mató el cross-platform». El detalle más útil está enterrado en el informe de migración: la mayor ganancia de velocidad de Shopify vino de desacoplar la lógica de negocio de la interfaz para que se ejecute de forma headless, impulsada por una herramienta de línea de comandos en lugar de un simulador. Sus agentes podían entonces iterar en milisegundos en vez de vigilar un simulador durante minutos por cada cambio. Ese truco no tiene nada que ver con Swift ni con Kotlin. Puede hacerse con React Native hoy mismo. Mueva su lógica a módulos simples sin importaciones de interfaz, ejecútelos bajo Node detrás de una CLI ligera, y sus agentes, y sus pruebas, obtienen el mismo bucle rápido. En nuestros proyectos nativos de iOS y Android, y en las aplicaciones de salud e IoT que hemos construido donde la corrección importa más que los píxeles, esa separación es el único cambio que da frutos independientemente de si un agente toca el código alguna vez.

La segunda cosa que vale la pena decir en voz alta: Shopify seguía necesitando expertos en nativo. Su propio artículo admite que el código generado introdujo duplicaciones, deriva arquitectónica y problemas de rendimiento, y que la experiencia en nativo siguió siendo esencial. El coste de dos bases de código no desapareció. Se trasladó de escribir código a revisarlo. Revisar código Swift que uno no escribió, y saber si es realmente bueno, es la parte costosa, y no se paraleliza como lo hace la generación. Una startup de cinco personas no tiene el banco de revisores de Shopify. Copie la decisión sin copiar la capacidad de revisión y acabará con dos bases de código y la mitad de la confianza.

Así que el consejo concreto es: no lea esto como una señal para reescribir nada. Léalo como un empujón para hacer un experimento. Elija una pantalla, extraiga su lógica de la interfaz hacia un módulo headless con sus propias pruebas, y mida cuánto más rápido se mueven sus ingenieros y sus agentes con eso. Es un día de refactorización, es reversible, y le dice más sobre su propia base de código que cualquier métrica de Shopify.

También hay una lección de seguridad más discreta en el artículo de Ali de 2025. Señalaba que la dependencia de React Native de bibliotecas de terceros amplía la superficie de ataque de la cadena de suministro. Sigue siendo verdad, y no es exclusivo de React Native. Todo proyecto nativo también se apoya en paquetes. Durante nuestros trabajos de pentesting, el árbol de dependencias es uno de los primeros lugares donde miramos, porque un paquete transitivo comprometido es una forma de entrada mucho más común que un fallo en el propio código. Menos capas de framework pueden significar menos componentes que auditar, pero solo si realmente se hace un seguimiento de lo que se incorpora.

Nada de esto significa que React Native haya terminado. Shopify es un caso muy específico: aplicaciones enormes, presupuesto para inferencia de IA y revisores nativos, y una migración a New Architecture que estaba a la vuelta de la esquina, lo que hizo que una reconstrucción desde cero fuera competitiva frente a actualizar en su lugar. La mayoría de los equipos no están en esa posición. El stack correcto sigue dependiendo de su equipo, sus aplicaciones y de cuánto de la segunda compilación puede confiar honestamente en que un agente se encargue.

Si decidir entre nativo, cross-platform o una refactorización headless para su próxima versión móvil le suena familiar, hablemos. Hemos lanzado aplicaciones tanto nativas como cross-platform, y le diremos claramente cuándo una reescritura es la decisión equivocada.