Shopify cambia React Native por Swift y Kotlin: qué cambia

En 2020, Shopify publicó un texto con un título que se volvió bandera: React Native is the future of mobile at Shopify. Seis años después, el mismo blog de ingeniería anuncia el camino inverso: la empresa está sacando sus apps de React Native y volviendo a Swift y Kotlin. Si tienes una app en React Native en producción, o estás eligiendo el stack de un proyecto nuevo, esta noticia merece algo más que una captura con un comentario irónico.

Trabajo con React Native todos los días. Así que voy a ser directo sobre lo que significa esta decisión y sobre lo que no significa.

Qué anunció Shopify

Shopify fue, durante años, el caso más citado de React Native fuera de Meta. Migró apps grandes, contrató gente del core, contribuyó a la New Architecture y escribió bastante sobre el proceso. Cuando alguien preguntaba "¿pero React Native aguanta una app seria?", la respuesta de siempre era: "Shopify lo usa".

Ahora la empresa dice que va a volver a nativo: Swift en iOS, Kotlin en Android. Dos bases de código, dos equipos de plataforma, el mismo modelo que ella había abandonado.

Vale la pena leer el post original completo. Aquí quiero enfocarme en lo que esto significa para quien no es Shopify, que es el caso de casi todos los que están leyendo esto.

Por qué esta decisión pesa más que un caso aislado

Que una empresa cambie de stack pasa todas las semanas. Airbnb dejó React Native en 2018 y la comunidad sobrevivió. Lo que hace diferente este caso es el historial.

Shopify no usó React Native de forma superficial. Invirtió fuerte, conocía las entrañas del framework y ayudó a mejorar el propio React Native. Cuando un equipo con ese nivel de dominio decide irse, el motivo difícilmente es "no supimos usarlo".

Eso deja una pregunta incómoda: si ni quien dominaba la herramienta quiso quedarse, ¿qué nos dice eso al resto?

Mi respuesta: dice mucho sobre la escala de Shopify y poco sobre tu app.

¿Esto significa que React Native murió?

No. Y quien diga eso en LinkedIn esta semana está vendiendo un curso de otra cosa. (La gente de Flutter ya está calentando los dedos para comentar "se los dije", y, bueno, ellos también usan una capa entre el código y la plataforma.)

React Native resuelve un problema específico: entregar una app decente en las dos plataformas con un equipo pequeño, aprovechando el conocimiento de React y TypeScript. Ese problema sigue existiendo. Una startup con tres devs no gana nada manteniendo dos apps nativas.

Lo que cambia es el punto de equilibrio. En una app gigante, con decenas de equipos tocando la misma base, el costo de la capa intermedia crece:

• Cada feature nueva de iOS o Android llega tarde o necesita su propio módulo nativo.
• Un bug de rendimiento se vuelve una investigación en tres capas: JS, puente (o JSI) y plataforma.
• Actualizar la versión de React Native se vuelve un proyecto de un trimestre.
• Terminas contratando gente de Swift y Kotlin de todos modos.

Este último punto es el que poca gente admite. Una app grande en React Native no elimina el código nativo. Solo esconde parte de él.

El costo que aparece cuando la app crece

Quien ya mantiene una app en producción conoce este camino. Todo empieza en TypeScript. Luego llega un requisito de cámara personalizada, un widget en la pantalla de inicio, una Live Activity en iOS, la integración con algún SDK de pagos. Abres la carpeta ios/ por primera vez en meses.

Un módulo simple con Expo Modules queda más o menos así:

import ExpoModulesCore

public class ReceiptPrinterModule: Module {
  public func definition() -> ModuleDefinition {
    Name("ReceiptPrinter")

    AsyncFunction("print") { (payload: String) -> Bool in
      return PrinterSDK.shared.send(payload)
    }
  }
}

Y del lado de JavaScript:

import { requireNativeModule } from 'expo-modules-core'

const ReceiptPrinter = requireNativeModule('ReceiptPrinter')

export const printReceipt = (payload: string): Promise<boolean> =>
  ReceiptPrinter.print(payload)

Se ve bonito. Ahora multiplícalo por 40 módulos, dos plataformas, pruebas en cada una y un equipo que necesita entender los tres lados. En algún momento la cuenta se da vuelta: estás manteniendo una app nativa y una app en React Native al mismo tiempo.

Una sola base de código es más barata solo mientras no tengas que pelearte con ella.

Qué cambió desde 2020

Aquí entra una lectura mía, no necesariamente el argumento de Shopify.

En 2020, el argumento más fuerte de React Native era económico: escribir la misma pantalla dos veces cuesta caro. Hoy, con agentes de código escribiendo buena parte del código repetitivo, ese costo bajó bastante. Pedirle a un agente que porte una pantalla de SwiftUI a Jetpack Compose no es gratis, pero está lejos de ser el doble de trabajo.

Cuando escribir código se vuelve más barato, lo que más pesa es el costo de mantener y depurar. Y en esas dos cosas lo nativo tiene ventaja: menos capas, documentación oficial, herramientas de la propia Apple y de Google, ninguna dependencia esperando una actualización de la comunidad.

Esto no aplica para todos. Ningún agente reemplaza a alguien que entiende de verdad el ciclo de vida de una vista en iOS. Pero el argumento de "una sola base de código porque el código es caro" perdió fuerza, y creo que más empresas van a rehacer esa cuenta en los próximos años.

Cuándo React Native todavía tiene sentido en tu app

Mi regla práctica, después de algunas apps entregadas:

• Equipo pequeño, producto validando mercado: React Native con Expo, sin pensarlo dos veces. La velocidad importa más que todo.
• App que es básicamente formularios, listas y llamadas a una API: React Native. La ganancia de lo nativo ahí es casi invisible para el usuario.
• Ya tienes un equipo web fuerte en React: React Native aprovecha ese conocimiento como ninguna otra opción.
• App que depende de hardware, gráficos pesados o recursos nuevos de la plataforma el día del lanzamiento: empieza a considerar nativo en serio.
• Decenas de devs mobile y presupuesto para equipos por plataforma: ahí sí estás en territorio de Shopify.

Si estás en los tres primeros grupos, la noticia de Shopify no cambia nada en tu backlog del lunes.

Qué haría yo hoy

Si fuera a empezar una app mañana, para la mayoría de los clientes que atiendo, seguiría con React Native y Expo. Para el 90% de las apps que veo, cambiar a nativo hoy sería una decisión cara para resolver un problema que no tienen.

Pero me quedaría con dos lecciones de Shopify. Primero: trata la carpeta ios/ y la android/ como código de primera clase, con gente en el equipo que sepa tocarlas. Segundo: elegir un stack no es un matrimonio. Shopify cambió de opinión dos veces en seis años, y está bien. La decisión correcta en 2020 puede ser la equivocada en 2026, porque el contexto cambió.

El error es copiar la decisión de una empresa con miles de ingenieros creyendo que vale para un equipo de cuatro personas. Mira tu tamaño, tu producto y tu equipo. Si quieres ver cómo lo he resuelto en la práctica, algunas apps están en mis proyectos.

En 2020 Shopify dijo que React Native era el futuro. En 2026 está volviendo a Swift y Kotlin.

Uso React Native todos los días, y mi lectura es simple: esta decisión dice mucho sobre la escala de Shopify y poco sobre tu app.

En una app gigante, con decenas de equipos, la capa intermedia sale cara. Una actualización se vuelve un proyecto de un trimestre, un bug se vuelve una investigación en tres capas y terminas contratando devs de Swift y Kotlin de todos modos.

Y hay un detalle nuevo: con agentes escribiendo el código repetitivo, escribir la misma pantalla dos veces salió mucho más barato. Lo que pesa ahora es mantener y depurar.

Para un equipo pequeño, un producto validando mercado o una app de formularios y API, React Native con Expo sigue siendo la elección correcta. El stack no es un matrimonio, pero copiar la decisión de una empresa con miles de ingenieros tampoco es una estrategia.

Escribí el análisis completo en el blog. Si estás con esta duda en tu app, cuéntame cómo lo estás pensando.

#ReactNative #DesarrolloMovil #Swift #Kotlin #Expo