Shopify está volviendo de React Native a Swift y Kotlin

Artículo original ↗ Discusión en Hacker News ↗

Shopify está reescribiendo sus apps móviles de React Native de vuelta a Swift y Kotlin nativos, argumentando que los agentes modernos de codificación con IA han eliminado gran parte del coste histórico de mantener dos bases de código. Quienes comentan ven esto como parte de un cambio más amplio: si los LLM pueden encargarse del trabajo repetitivo multiplataforma, las grandes empresas pueden preferir el rendimiento nativo, una integración más estrecha con la plataforma y menos sobrecarga de framework, incluso a costa de perder una única pila compartida. Otros advierten que la paridad, las pruebas y el mantenimiento a largo plazo entre plataformas siguen siendo problemas difíciles, y que para equipos pequeños la economía de React Native, Flutter o enfoques basados en la web puede seguir siendo más convincente.

Razonamiento percibido detrás del cambio de Shopify

  • Muchos ven el cambio principalmente como una forma de escapar del “impuesto” de React Native: actualizaciones dolorosas, cambios constantes de dependencias e inestabilidad del framework aguas arriba.
  • Otros sostienen que el verdadero motor es la preferencia interna y la política, no solo la IA o el coste objetivo.
  • Varios señalan que Shopify ya estaba siendo empujada hacia una refactorización importante de RN (“New Architecture”), así que reevaluar la pila era oportuno.

IA/LLMs y la economía de lo nativo

  • Existe un amplio consenso en que los agentes de codificación reducen drásticamente el coste de construir y portar apps nativas; varios comentaristas cuentan portados de apps pequeñas o medianas de RN a Swift/Kotlin durante la noche o muy rápidamente.
  • Los defensores afirman que “una app RN frente a dos apps nativas” ahora es una falsa disyuntiva: la IA puede mantener ambas, especialmente si las especificaciones y las pruebas se comparten.
  • Los escépticos responden que la IA también abarata RN; el coste de paridad/mantenimiento a lo largo de los años sigue siendo incierto y no probado.

React Native, Flutter y alternativas

  • RN se describe como viable pero frágil: cambios incompatibles frecuentes, actualizaciones torpes, calidad desigual de las librerías y penalizaciones de rendimiento/UX, especialmente en Android.
  • Flutter recibe tanto elogios (“todavía me encanta”) como desdén (“callejón sin salida”), y algunos dicen que su pila basada en Skia es intrínsecamente pesada.
  • Se mencionan Kotlin Multiplatform, Rust+UniFFI y native .NET como mejores formas de compartir la lógica central manteniendo UIs nativas.

Revisión de App Store, OTA y despliegue

  • Hay un fuerte desacuerdo sobre los tiempos actuales de revisión en iOS: algunos informan de menos de 24 horas, otros de 2–7+ días y una gran variabilidad.
  • Las actualizaciones over-the-air (OTA) de RN se ven como una enorme ventaja práctica para correcciones rápidas de errores y cambios motivados por cumplimiento; a quienes critican el cambio les preocupa que Shopify renuncie a eso.

Paridad, complejidad y coste organizativo

  • Varios comentaristas dicen que lo más difícil no es la reescritura inicial, sino mantener alineado el comportamiento de iOS/Android durante años: experimentos, analíticas, accesibilidad, casos límite.
  • Las especificaciones y pruebas compartidas se consideran necesarias, pero su eficacia a largo plazo es “incierta”; la gente quiere números duros (horas, tasas de defectos, incidentes de deriva, gasto en modelos).

Preocupaciones sobre IA, calidad y seguridad

  • Algunos abrazan el desarrollo “agentic” y apenas leen la salida de Swift/Kotlin, confiando en las pruebas y en revisores adicionales basados en modelos.
  • Otros advierten que esto conduce a apps nativas “vibe-coded” e insostenibles, con errores ocultos, problemas de seguridad (secretos, OAuth, WebViews) y código frágil que los humanos no entienden realmente.

Tendencia más amplia

  • Muchos esperan que las organizaciones grandes y bien financiadas vuelvan a lo nativo, mientras que los equipos pequeños y los MVP seguirán con RN/Flutter/web.
  • Varios prevén un giro más amplio alejándose de Electron y de las pilas multiplataforma pesadas a medida que el código se vuelve “barato”, pero la complejidad y el bloat en tiempo de ejecución siguen siendo caros.