Shopify anunció que sus aplicaciones móviles vuelven a Swift y Kotlin, después de años como el caso de éxito más citado de React Native a gran escala. El anuncio está en el blog de ingeniería de Shopify y explotó en Hacker News: más de mil puntos y casi ochocientos comentarios en un día. Simon Willison también lo levantó en su sitio, lo cual dice bastante sobre cuánto ruido hizo.
Por qué importa
La noticia no es "React Native falló". La noticia es que la empresa que más fuerte apostó públicamente a React Native, la que escribió los posts que todos citábamos en las reuniones para justificar la decisión, cambió de opinión. Y eso rompe el argumento de autoridad que muchos equipos veníamos usando sin pensarlo demasiado.
Mi lectura: el cross-platform no compite contra lo nativo en abstracto. Compite contra lo nativo en el contexto de una organización específica. Shopify tiene plata para contratar equipos separados de iOS y Android. Tiene volumen de usuarios donde cada milisegundo de arranque se traduce en plata. Tiene apps que necesitan integrarse con hardware de punto de venta. Para esa organización, el ahorro de compartir código dejó de compensar el costo de pelearse con la capa de abstracción.
Tu startup de siete personas no está en ese contexto. Y ahí está el error que voy a ver repetirse en las próximas semanas: alguien va a llevar este post a una reunión como prueba de que hay que reescribir todo en Swift, sin tener ni el equipo ni el volumen ni el problema que Shopify tenía.
Qué cambia en la práctica
Lo primero: cambia la conversación cuando proponés cross-platform. Antes alcanzaba con nombrar a Shopify. Ahora te van a pedir un argumento propio, y eso en el fondo es sano. Te obliga a ser explícito sobre qué estás comprando y qué estás pagando.
Cuando alguien me pregunta por stack móvil, el eje real no es "¿cuál es mejor?" sino esto:
| Dimensión | Cross-platform | Nativo |
|---|---|---|
| Costo inicial de equipo | Un equipo | Dos equipos, o uno que alterna |
| Acceso a APIs nuevas del SO | Esperás el puente | Día uno |
| Techo de performance | Lo pone la abstracción | Lo pone la plataforma |
| Deuda que acumulás | En el puente y en los parches | En la duplicación de lógica |
| Perfil de contratación | Devs web reconvertibles | Especialistas por plataforma |
Ninguna columna gana. Lo que cambia es cuál de esos costos tu organización puede absorber hoy. Un equipo chico absorbe mal el costo de dos especialistas y bien el de esperar un puente. Shopify está exactamente al revés.
Lo segundo, y esto me parece más interesante: el anuncio es sobre mobile, no sobre React. El mismo día anterior salió React 19.3, con View Transitions, Fragment Refs, browser() y Trusted Types. Son features de web, para el DOM, resolviendo problemas de web. React en el navegador y React Native en el teléfono comparten modelo mental y poco más. Si trabajás en frontend web, esta noticia no te toca ni un poco, y no vale la pena que la uses para dudar de tu stack.
Cuándo NO usarlo
Voy a ser honesto con las dos direcciones, porque acá es donde se arma el desastre.
Cuándo no seguir a Shopify a nativo:
- Si tu app ya funciona en React Native y tus usuarios no se quejan de performance. Una migración es meses de trabajo que no le agrega una sola feature al producto. Reescribir para copiar la decisión de otro es la peor razón posible.
- Si no tenés gente que sepa Swift y Kotlin en serio. Nativo escrito por alguien que aprendió la semana pasada rinde peor que cross-platform escrito por alguien que lo domina.
- Si tu app es formularios, listas y llamadas HTTP. Ahí el techo de la abstracción está muy por encima de donde estás. Nunca lo vas a tocar.
- Si la velocidad de iteración es tu ventaja competitiva. Dos codebases significa dos releases, dos revisiones de tienda, dos ciclos de QA.
Cuándo no elegir cross-platform:
- Si tu producto vive de una capacidad de plataforma específica: cámara con procesamiento en tiempo real, Bluetooth de bajo nivel, hardware dedicado, widgets profundos del sistema. Vas a terminar escribiendo módulos nativos igual, y ahí tenés lo peor de los dos mundos: la complejidad de nativo más la del puente.
- Si necesitás adoptar APIs del SO el día que salen. La comunidad tarda en portarlas, y esa espera no la controlás vos.
- Si el equipo va a crecer a dos escuadras por plataforma en el corto plazo. Ahí el código compartido pasa de ser un ahorro a ser un punto de contención entre equipos.
Una advertencia sobre los datos: el post de Shopify tiene los detalles técnicos y las razones específicas. Yo no vi ahí números de performance que pueda citar sin inventar, así que no te voy a tirar porcentajes. Si el argumento te importa de verdad, leelo entero y fijate si sus razones aplican a tu contexto. Ese es todo el ejercicio.
Qué haría hoy
Nada. Literalmente nada, si mi app móvil anda bien.
Lo único que sí haría es una revisión honesta de una pregunta: ¿cuánto tiempo del último trimestre gastó mi equipo peleándose con la capa de abstracción en lugar de escribir features? Si la respuesta es "casi nada", el debate no existe. Si es "la mitad del sprint se fue en parchear un módulo nativo", entonces la decisión de Shopify no es tu razón para migrar, pero sí es un buen momento para hacer la cuenta que venías postergando.
Las decisiones de arquitectura de las empresas grandes son datos sobre esas empresas, no instrucciones para el resto. Shopify no te está diciendo qué hacer. Te está contando qué le pasó a Shopify.