Shopify deja React Native: lo que esto enseña

En 2020, Shopify publicó un texto diciendo que React Native era el futuro del mobile en la empresa. Seis años después, el equipo de ingeniería publicó otro, con un título mucho menos festivo: están volviendo a Swift y Kotlin. Si trabajas con React Native, esta noticia pesa. Shopify no era una usuaria más del framework. Era una de sus vitrinas.

Uso React Native en el día a día y no voy a fingir que lo leí con indiferencia. Pero antes de salir a declarar la muerte de algo, vale la pena entender qué cambió y qué significa para quien está decidiendo el stack de una app hoy.

Lo que Shopify hizo con React Native

Para dimensionar la noticia, recuerda el tamaño de la apuesta. Shopify llevó apps importantes a React Native: la app para comerciantes, el Point of Sale y Shop, que es la app de compras para el consumidor. No fue un experimento en una app interna olvidada. Fue producto que factura.

Y la empresa no se quedó solo consumiendo. Le devolvió mucho al ecosistema:

• FlashList, la lista que se volvió estándar para quien sufría con un FlatList que se trababa.
• react-native-skia, hecha junto con la comunidad, para dibujo y animación de alto rendimiento.
• Contrató gente del core y patrocinó trabajo en la nueva arquitectura.

Entonces, cuando una empresa con ese historial dice "vamos a volver a lo nativo", nadie puede acusar al equipo de no saber usar la herramienta. Eso es lo que hace interesante la noticia.

Por qué Shopify está volviendo a Swift y Kotlin

El post detalla los motivos y vale la pena leerlo completo, directo en la fuente. No voy a reproducir el texto aquí. Lo que me interesa es el patrón de fondo, porque aparece en casi toda app multiplataforma que crece mucho.

La promesa de React Native siempre fue: un equipo, un código, dos plataformas. Al principio es verdad. Escribes la pantalla una vez, corre en iOS y en Android, y el equipo avanza rápido.

Con el tiempo, la app madura y empieza a pedir cosas que viven fuera de JavaScript. Widget en la pantalla de inicio. Live Activities. Integración con pagos sin contacto. Accesibilidad fina. Animación que tiene que correr a 120 Hz sin tirones. Cada una de esas cosas se vuelve un módulo nativo. Y el código empieza a verse así:

const CheckoutButton = Platform.select({
  ios: () => <ApplePayButton onPress={pay} />,
  android: () => <GooglePayButton onPress={pay} />,
})!

Un Platform.select aislado no es problema. Doscientos repartidos por la app, sí. Llega un punto en que mantienes tres bases de código: el JS compartido, el Swift de los módulos de iOS y el Kotlin de los módulos de Android. Y además necesitas gente que entienda el puente entre los tres.

El código compartido solo ahorra cuando el problema también es compartido.

Ese es el costo que nadie pone en la planilla cuando elige multiplataforma el primer día.

¿React Native murió? No, y explico por qué

Cada vez que una empresa grande cambia de stack, aparece alguien en X diciendo que la tecnología se acabó. Ya vimos esa película con Airbnb en 2018, que también dejó React Native. El framework no murió. Al contrario: ganó la nueva arquitectura, Hermes mejoró mucho y Expo se volvió una plataforma seria de verdad.

La decisión de Shopify dice más sobre Shopify que sobre React Native. Piensa en su escenario:

• Tiene dinero para mantener equipos separados de iOS y Android.
• Tiene apps enormes, con años de funcionalidades acumuladas.
• Compite en experiencia. Un checkout 200 ms más lento cuesta ventas.
• Necesita adoptar funciones nuevas de Apple y Google el día del lanzamiento, no tres meses después cuando se actualice la librería de la comunidad.

Ahora compáralo con el escenario de la mayoría de los proyectos que veo: un equipo pequeño, plazo ajustado, una app que es básicamente formulario, lista y llamada a una API. En ese caso, contratar un dev Swift y un dev Kotlin para hacer la misma pantalla dos veces es tirar dinero.

La pregunta correcta nunca fue "¿React Native o nativo?". Es "¿en qué fase está mi app y dónde está el cuello de botella?".

La IA entra en esta cuenta

Hay un detalle que cambió desde 2020 y que creo que pesa más de lo que parece. El costo de escribir código bajó. Con agentes de IA generando buena parte del boilerplate, portar una pantalla de SwiftUI a Jetpack Compose se volvió mucho más barato que antes.

Antes, el gran argumento del multiplataforma era "escribir dos veces es caro". Si escribir se volvió barato, el cuello de botella pasa a ser otro: revisar, probar, mantener y entender el código. Y ahí una app nativa, que usa las herramientas oficiales de la plataforma sin una capa extra en el medio, puede resultar más simple de mantener que una app híbrida llena de puentes.

No digo que ese haya sido el motivo de Shopify. Digo que esa cuenta cambió para todos, y quien elige stack en 2026 con la cabeza de 2020 corre el riesgo de optimizar el costo equivocado.

Qué cambia en la práctica para quien usa React Native

Si tienes una app React Native en producción, no hace falta entrar en pánico ni abrir un issue de migración mañana. Pero se pueden sacar algunas lecciones bien concretas:

1. Cuenta tus módulos nativos. Haz un relevamiento simple en el proyecto:

grep -rl "Platform.OS\|Platform.select" src | wc -l
ls ios/*/*.swift android/app/src/main/java/**/*.kt 2>/dev/null | wc -l

Si esos números crecen en cada sprint, la app está pidiendo nativo y estás pagando un impuesto de puente.

2. Separa lo que es producto de lo que es plataforma. Reglas de negocio, validación, estado y llamadas a la API pueden quedarse en TypeScript puro, fuera de los componentes. Si algún día migras, esa parte se va contigo o se vuelve backend. Quien mezcla todo dentro de la pantalla va a reescribir todo.

3. No pelees con la plataforma. Si la feature es muy específica de iOS, escríbela en Swift y expón un módulo pequeño. Intentar reproducir en JS algo que Apple ya entrega listo es la forma más cara de quedar parecido al original.

4. Mantén Expo y la nueva arquitectura al día. Buena parte del dolor del React Native antiguo venía del puente asíncrono y de las actualizaciones atrasadas. Quien quedó tres versiones atrás siente mucho más el peso del framework.

Mi opinión sobre la vuelta a lo nativo

Sigo empezando apps con React Native y Expo. Para el tamaño de proyecto que manejamos yo y la mayoría de los devs que leen este blog, sigue siendo la forma más rápida de poner algo bueno en las dos tiendas con un equipo pequeño. Mi opinión fuerte es esta: elegir nativo puro el primer día, para un MVP con tres pantallas, es vanidad técnica.

Pero Shopify muestra algo que todo el que ama una herramienta necesita escuchar: el stack no es un equipo de fútbol. La misma empresa que ayudó a construir el ecosistema miró los números, vio que el contexto cambió y cambió. Sin drama. Eso es ingeniería. Hacerle barra al framework y defenderlo en un hilo es otra cosa, y nadie paga por eso.

Si tienes dudas sobre qué camino seguir en tu app, echa un vistazo a los proyectos que ya entregué y a cómo elegí el stack en cada uno. Spoiler: la respuesta casi siempre fue "depende", pero con números al lado.

En 2020, Shopify dijo que React Native era el futuro. En 2026, anunció la vuelta a Swift y Kotlin.

Uso React Native todos los días y no leí esto con indiferencia. Pero el framework no murió. La decisión dice más sobre el momento de Shopify que sobre la herramienta.

El código compartido solo ahorra cuando el problema también es compartido. Con doscientos Platform.select repartidos, ya mantienes tres bases de código.

Y la IA cambió esa cuenta: escribir dos veces se volvió barato. Ahora lo caro es revisar, probar y mantener.

Para un MVP con un equipo pequeño, sigo con Expo. El stack no es un equipo de fútbol. Es una decisión con números al lado.

En el blog cuento cómo elijo el stack en cada proyecto. Enlace en los comentarios.

#ReactNative #DesarrolloMovil #Shopify #IngenieriaDeSoftware #Expo