Shopify Native Mobile ha vuelto, y la IA cambió el equilibrio
El desarrollo móvil nativo de Shopify está reemplazando React Native, invirtiendo una estrategia de seis años después de que los agentes de programación cambiaran el coste de mantener dos aplicaciones. Shopify desarrollará su software para iOS en Swift y el de Android en Kotlin. La empresa afirma que los agentes ahora pueden traducir, probar y revisar suficiente trabajo como para hacer prácticos los códigos base separados.
La decisión desafía una de las promesas más sólidas del desarrollo multiplataforma. React Native permite a los equipos compartir gran parte de la implementación de una aplicación entre iOS y Android. Shopify adoptó ese modelo para evitar desarrollar las funcionalidades dos veces, facilitar que los desarrolladores web contribuyeran y mantener ambas plataformas alineadas.
Shopify no afirma que React Native sea lento o haya fracasado. Dice que el framework proporcionó los beneficios prometidos por su decisión móvil de 2020. El cambio se basa en un argumento distinto: la IA ha reducido el trabajo que se ahorra al compartir la implementación, mientras que el software nativo sigue ofreciendo un acceso más directo a cada plataforma.
Esta distinción importa más allá de Shopify. Si los agentes de programación hacen asequibles las implementaciones paralelas, los equipos de ingeniería deben reconsiderar cómo miden la reutilización de código. La capa compartida valiosa podría pasar del código fuente a las especificaciones, las pruebas, los sistemas de diseño y los procedimientos de revisión.
Shopify Native Mobile reemplaza una estrategia exitosa de React Native
Shopify está retirando una arquitectura exitosa porque ha cambiado el supuesto económico que la sustentaba.
La empresa anunció su regreso al desarrollo nativo el 10 de septiembre de 2026. Sus principales productos móviles incluyen Shop, Shopify, Point of Sale e Inbox. Millones de comerciantes y compradores dependen de estas aplicaciones, según Shopify.
La empresa apostó por completo por React Native en 2020. React Native es el framework de Meta para crear interfaces de iOS y Android con JavaScript y componentes nativos de cada plataforma. Shopify buscaba una pila tecnológica común que redujera el desarrollo duplicado entre ambos sistemas operativos.
Sus primeros resultados respaldaron esa decisión. La empresa informó de un 95 por ciento de código compartido para Arrive, que se convirtió en Shop, y de un 99 por ciento para Compass. Un equipo también se sintió dos veces más productivo después de reescribir Arrive con React Native.
Más adelante, Shopify trasladó hacia el framework su mayor aplicación para comerciantes. Ese producto contenía más de 300 pantallas en cada plataforma. Al principio, una migración gradual parecía más segura que detener el desarrollo de funcionalidades para realizar una reescritura completa.
La estrategia exigió una inversión organizativa considerable. Shopify formó a desarrolladores nativos mediante un programa interno de React Native, creó bases compartidas y aportó bibliotecas al ecosistema más amplio. También desarrolló procesos para combinar código nativo con React Native cuando seguía siendo necesario realizar trabajo específico de cada plataforma.
En enero de 2025, Shopify seguía describiendo el futuro de React Native como prometedor. Su revisión de cinco años elogió la gestión de Meta y prometió más inversión en bases compartidas. También promovió la reactivación de un grupo de trabajo para empresas que utilizan el framework.
Por tanto, el nuevo anuncio representa un giro real, no un rechazo tardío de un experimento fallido. Shopify afirma que React Native ahorró tiempo, amplió quién podía contribuir y redujo el esfuerzo dedicado a perseguir la paridad de funcionalidades.
Sin embargo, esos beneficios acarreaban costes continuos. Los equipos optimizaban el rendimiento, mantenían componentes fundamentales, seguían los cambios del framework y gestionaban dependencias externas. Shopify consideraba aceptables esos costes mientras una implementación compartida eliminara una cantidad sustancial de trabajo duplicado.
Los agentes de programación cambiaron ese cálculo. Shopify afirma que utiliza grandes modelos de lenguaje para el desarrollo de software desde 2021. Los primeros usos incluían implementar funcionalidades, investigar errores, resolver problemas y revisar código.
A finales de 2025, la empresa confió a los agentes trabajos más complejos. Los equipos comenzaron a probar si una implementación de iOS podía guiar una implementación de Android y si el proceso inverso funcionaba igual de bien. Esos prototipos llevaron a Shopify hacia aplicaciones Swift y Kotlin separadas.
La nueva estrategia nativa de la empresa sigue reconociendo la desventaja central. El desarrollo nativo requiere que los equipos construyan y mantengan el software dos veces. Según Shopify, la IA ha reducido esa carga, pero no la ha eliminado.
El cambio es relevante porque Shopify ofreció en su día pruebas especialmente sólidas de React Native a gran escala. No se limitó a usar el framework para una funcionalidad pequeña. Migró aplicaciones grandes, formó equipos, construyó infraestructura, patrocinó a mantenedores y publicó bibliotecas reutilizables.
Ahora la misma empresa sostiene que la reutilización de implementación ya no merece el mismo peso. Esa es la tensión central del artículo. El historial de migración de Shopify a React Native muestra que el framework funcionó, mientras que los agentes de Shopify debilitaron el argumento empresarial para conservarlo.
Los agentes de programación presionan a los equipos multiplataforma
La presión inmediata recae sobre las organizaciones que consideran el código compartido la principal medida de eficiencia móvil.
Los frameworks multiplataforma combinan dos tipos de ventaja. Permiten a los desarrolladores expresar un comportamiento una vez y permiten a las empresas organizar el trabajo móvil en torno a menos lenguajes y herramientas. Ambas ventajas reducen los costes de coordinación, además del tiempo de programación.
El argumento de Shopify debilita directamente la primera ventaja. Un agente puede inspeccionar una funcionalidad existente de iOS, producir una implementación correspondiente para Android y ayudar a verificar la paridad de comportamiento. El código fuente es distinto, pero gran parte del esfuerzo humano ya no necesita repetirse manualmente.
Eso desplaza la atención hacia la segunda ventaja. Las plataformas separadas siguen requiriendo distintos sistemas de compilación, dependencias, procedimientos de lanzamiento, entornos de prueba y criterio especializado. Los agentes pueden ayudar con esas tareas, pero los equipos siguen siendo responsables de cada resultado enviado.
Los responsables de los frameworks se enfrentan ahora a una propuesta de valor más complicada. “Escribe una vez” resulta menos persuasivo cuando la traducción de software es barata. Las herramientas multiplataforma deben demostrar valor mediante fiabilidad, velocidad de iteración, movilidad de equipos, calidad del ecosistema y menor sobrecarga de coordinación.
Los líderes de ingeniería móvil afrontan presión desde la otra dirección. Los ejecutivos podrían interpretar el desarrollo Swift Kotlin de Shopify como prueba de que todas las empresas pueden abandonar su código base compartido. Esa conclusión ignoraría los sistemas que Shopify construyó alrededor de sus agentes.
Shopify no pidió a un modelo que regenerara una aplicación de una sola vez. Creó flujos de trabajo estructurados, puntos de control de revisión, herramientas de prueba y restricciones arquitectónicas. Los ingenieros experimentados siguieron siendo responsables de los requisitos, las decisiones de plataforma y la calidad de producción.
La migración también comenzó con un insumo inusualmente favorable: un producto React Native funcional. Esa aplicación sirvió como una especificación ejecutable para pantallas, interacciones, navegación, analítica y comportamiento de datos. Los agentes traducían un comportamiento definido en lugar de inventar un producto completo.
Esta distinción somete a presión adicional a las empresas con aplicaciones mal documentadas. Las migraciones generadas por IA dependen de un comportamiento de referencia claro y de resultados observables. Los sistemas heredados ambiguos ofrecen a los agentes más oportunidades de reproducir errores, omitir casos límite o inventar patrones incompatibles.
Los desarrolladores también se ven afectados. React Native amplió en su día el grupo de colaboradores de Shopify al permitir que personas con experiencia web trabajaran en funcionalidades móviles. El código nativo tradicionalmente otorgaba mayor valor a conocimientos especializados de Swift, Kotlin, iOS y Android.
Shopify afirma que los agentes ahora ayudan a los ingenieros a contribuir fuera de su pila tecnológica principal. Los patrones familiares de interfaces declarativas también facilitaron a los desarrolladores de React Native aprender SwiftUI y Jetpack Compose. SwiftUI y Jetpack Compose son los frameworks modernos de Apple y Google para definir interfaces mediante el estado de la aplicación.
Eso no convierte la experiencia en plataformas en opcional. Los ingenieros nativos siguen comprendiendo el comportamiento del ciclo de vida, la accesibilidad, la memoria, el procesamiento en segundo plano, las convenciones de plataforma y las restricciones de lanzamiento. El código generado puede parecer correcto mientras crea deriva arquitectónica o problemas sutiles de rendimiento.
La respuesta obligada no es necesariamente una migración de framework. Los equipos ahora deben recalcular dónde el código compartido produce ahorros reales. También necesitan evidencia que demuestre si los agentes pueden preservar la calidad entre dos implementaciones dentro de su propio entorno.
Para los equipos de React Native, la respuesta más sólida será operativa en lugar de ideológica. Pueden medir el esfuerzo de actualización, el mantenimiento de dependencias, las tasas de fallos, la velocidad de inicio, el tiempo de compilación y las excepciones específicas de plataforma. Esas cifras revelan si la implementación compartida sigue justificando su capa de abstracción.
Para los equipos nativos, los resultados de Shopify elevan el estándar para demostrar la productividad de la IA. La mera finalización de código es insuficiente. Un flujo de trabajo agéntico creíble debe preservar la analítica, la accesibilidad, la navegación, las pruebas, la seguridad de lanzamiento y un comportamiento de producto coherente.
Por tanto, la presión a largo plazo afecta a ambos campos. Los defensores del desarrollo multiplataforma deben cuantificar beneficios más allá de la reutilización de código. Los defensores del desarrollo nativo deben demostrar que la duplicación asistida por agentes sigue siendo mantenible después de que pase el entusiasmo de una migración.
El giro trata sobre reutilización, no sobre el rendimiento de React Native
La decisión de Shopify separa la reutilización de código de la consistencia del producto, tratándolas como problemas de ingeniería distintos.
Históricamente, React Native conectaba esos objetivos. Un componente o funcionalidad compartidos solían comportarse de manera similar en todas las plataformas porque ambas aplicaciones ejecutaban gran parte de la misma implementación. Esa relación reducía la superficie en la que las versiones de las plataformas podían divergir.
El nuevo modelo de Shopify mantiene la consistencia mientras descarta el código de interfaz compartido. Los equipos utilizarán especificaciones comunes, pruebas, reglas de diseño, contratos de analítica y puntos de control de revisión. Después, los agentes implementarán el mismo comportamiento previsto usando el framework nativo de cada plataforma.
Se trata de un giro más profundo que cambiar lenguajes de programación. La empresa está elevando la fuente de verdad. En lugar de tratar el código compartido como el principal contrato de producto, considera que la intención revisada y el comportamiento observable son el contrato.
Este enfoque conserva varias ventajas nativas. Los desarrolladores pueden utilizar API propias a medida que Apple y Google las lanzan. Pueden seguir las convenciones de cada plataforma sin negociar una abstracción compartida. También eliminan las capas del framework y de dependencias entre la aplicación y el sistema operativo.
El cambio llegó mientras Shop afrontaba otra gran inversión en React Native. La aplicación necesitaba adoptar la New Architecture del framework, que modifica el renderizado, la integración de módulos nativos y los límites entre el código compartido y el específico de cada plataforma.
Antes de realizar esa inversión, Shopify probó el desarrollo directo con SwiftUI y Jetpack Compose. Un ingeniero dedicó una semana a usar agentes de programación para migrar a un prototipo nativo de iOS la mayor parte posible de Shop.
Ese prototipo no estaba listo para producción. Sin embargo, reprodujo suficientes pantallas, interacciones y flujos de aplicación para que una migración completa pareciera viable. Los agentes ofrecieron sus mejores resultados cuando podían trabajar a partir de funcionalidades definidas y comportamiento visible.
Un grupo central de seis ingenieros construyó entonces las bases nativas y los principales flujos de Shop. Los equipos de funcionalidades se incorporaron a mitad del proceso para validar sus áreas y resolver casos límite. Shopify pasó de la prueba de concepto a aplicaciones nativas disponibles en tiendas en 12 semanas.
Estas cifras explican por qué el giro resultó creíble. Una reescritura greenfield convencional, es decir, una nueva implementación construida sin arrastrar la arquitectura anterior, puede requerir años. También puede congelar el desarrollo de producto e introducir problemas prolongados de paridad.
Shopify había vivido ese desafío en la dirección opuesta. Su anterior migración gradual hacia React Native creó un periodo con tres arquitecturas: iOS, Android y React Native. Un informe de 2022 señaló que el ritmo original habría requerido entre cuatro y cinco años.
La empresa eligió un enfoque greenfield para regresar a lo nativo. Afirma que los agentes de programación podían usar la aplicación React Native existente como referencia, mientras que los nuevos repositorios eliminaban las antiguas restricciones arquitectónicas. Los prototipos sugirieron que las aplicaciones podían reconstruirse de forma considerablemente más rápida que antes.
Los resultados de Shop también aportaron evidencia de rendimiento. Shopify informó que la aplicación nativa de iOS alcanzó contenido visible en la pantalla de inicio en 2.466 milisegundos, frente a los 3.200 milisegundos anteriores. Esto representa una reducción del 23 por ciento en el tiempo de arranque.
En Android, el tiempo de arranque bajó de 4.433 milisegundos a 2.233 milisegundos, una reducción del 50 por ciento. La compilación de lanzamiento de Android también se redujo de 293 MB a 184 MB, mientras que la compilación de iOS aumentó de 67 MB a 68 MB.
El tiempo de compilación de lanzamiento de Android disminuyó alrededor de un 75 por ciento. Shopify también mostró que la aplicación nativa de Android alcanzaba 120 fotogramas por segundo durante el desplazamiento del feed y la navegación en un dispositivo Pixel.
La estabilidad de las sesiones aumentó de al menos el 99,5 por ciento históricamente a al menos el 99,95 por ciento tras el lanzamiento nativo. Shopify caracterizó ese cambio como una reducción de diez veces en las sesiones que fallan.
Se trata de comparaciones reportadas por la empresa, no de benchmarks independientes. La migración también incluyó simplificación del producto, con algunas pantallas retiradas y otras optimizadas. Esto dificulta atribuir cada mejora exclusivamente a la tecnología nativa.
Shopify evita hacer esa afirmación. Declara explícitamente que sus aplicaciones React Native eran rápidas y que React Native sigue siendo un excelente framework. Su argumento central se refiere al valor relativo de una implementación compartida después de que los agentes reduzcan el trabajo duplicado.
La distinción evita un veredicto engañoso de React Native frente a nativo. Shopify no presenta un benchmark universal para todas las aplicaciones. Está informando que su equipo, herramientas, arquitectura y escala de producto ahora favorecen un equilibrio diferente.
Helix muestra por qué la migración fue más que generación de código
Shopify hizo manejable la duplicación nativa al convertir la migración en un ciclo de verificación controlado.
La empresa descubrió que una conversión de una sola vez producía demasiado código difícil de mantener. Incluso especificaciones detalladas por adelantado no hacían fiable una reescritura automatizada completa. El resultado podía parecer terminado mientras ocultaba patrones inconsistentes y comportamientos ausentes.
Shopify creó Helix para dividir el trabajo de migración en pequeños puntos de control. Un desarrollador dirige el sistema hacia una pantalla, y Helix lee la implementación de React Native. Luego propone una secuencia ordenada de trabajo que los humanos pueden revisar rápidamente.
Cada punto de control debe demostrar su comportamiento mediante pruebas. También pasa por comparación visual, dos revisiones de código adversariales y aprobación humana antes de que comience el siguiente punto de control. La retroalimentación se conserva para que el flujo de trabajo se vuelva más autónomo con el tiempo.
Este mecanismo importa más que la velocidad bruta de generación. La migración de software falla cuando los errores se acumulan más rápido de lo que los revisores pueden comprenderlos. Las unidades pequeñas aceptadas limitan la cantidad de comportamiento no verificado que entra en la nueva aplicación.
Shopify también ejecutó múltiples sesiones de agentes en worktrees separados. Subagentes especializados inspeccionaron el código existente, documentaron el comportamiento, prepararon planes de plataforma, implementaron funcionalidades y revisaron la paridad. Los ingenieros aprobaron requisitos y planes de implementación antes de que avanzara el desarrollo.
La aceptación del plan estaba vinculada a un hash del contenido revisado. Si el plan cambiaba, su aprobación anterior dejaba de ser válida. Ese diseño reducía la posibilidad de que un agente implementara silenciosamente un plan distinto después de recibir autorización.
El flujo de trabajo examinó más que los elementos visibles de la interfaz. Shopify afirma que su revisión de código fuente cubría estado, navegación, analítica, accesibilidad y comportamiento de datos. Estas áreas suelen contener los fallos de migración más difíciles porque las capturas de pantalla por sí solas no pueden revelarlos.
La preservación de la analítica fue especialmente importante. Las recomendaciones y otros sistemas posteriores dependían de eventos esperados y campos contextuales. Una aplicación visualmente correcta aún podía dañar sistemas de decisión si cambiaban los nombres de los eventos, los recuentos o las relaciones entre cargas útiles.
Shopify desarrolló otra herramienta, Tardis, para exponer eventos, registros y estado de aplicaciones en ejecución en una forma estructurada. Los agentes podían enviar comandos a la aplicación, investigar problemas, inspeccionar la navegación y validar correcciones con menos interacción manual.
Para las revisiones de paridad, Tardis capturaba capturas de pantalla y ventanas de eventos de las aplicaciones React Native y nativas en puntos de control con nombre. Los agentes comparaban los campos de eventos teniendo en cuenta diferencias legítimas, incluidas marcas de tiempo e identificadores únicos de página.
La arquitectura también abordó la latencia del simulador. Los agentes móviles a menudo dependen de árboles de accesibilidad o capturas de pantalla para comprender el estado de la interfaz. Pueden modificar código en segundos y luego dedicar varios minutos a compilar y probar mediante un simulador.
Shopify descubrió que este ciclo lento requería supervisión humana frecuente. La recarga en caliente de módulos de React Native mejoró la iteración, pero no eliminó el cuello de botella del simulador. La capacidad del modelo tenía un valor limitado cuando la retroalimentación seguía siendo lenta y frágil.
La empresa respondió separando la lógica de negocio de la interfaz. La lógica de negocio sin interfaz puede ejecutarse sin mostrar la aplicación. Shopify expuso esa lógica mediante una interfaz de línea de comandos, lo que permitía a los agentes ejecutarla en milisegundos en un equipo de escritorio.
Este es el mecanismo detrás del desarrollo móvil nativo de Shopify. Los agentes no se limitaron a sustituir a seis ingenieros por código generado. Shopify rediseñó la arquitectura de la aplicación, los sistemas de retroalimentación, los controles de revisión y el acceso a pruebas en torno a la participación de máquinas.
Ese trabajo cambia la economía aparente. Mantener dos implementaciones se vuelve más barato, en parte porque la organización invierte en un sistema compartido de verificación. El activo común ya no es el código de interfaz, sino la maquinaria que describe y comprueba el comportamiento esperado.
El modelo también se parece a cómo los equipos pueden crear un registro consultable de decisiones técnicas. Las especificaciones, los planes, los hallazgos de revisión y los resultados de pruebas se convierten en contexto reutilizable. Una base de conocimiento de ingeniería puede ayudar a las personas a rastrear esas decisiones en toda la documentación, aunque no sustituye las pruebas a nivel de repositorio.
Este enfoque favorece a grandes organizaciones con infraestructura madura. Shopify podía crear herramientas personalizadas, mantener amplias comprobaciones automatizadas y asignar ingenieros experimentados a arquitectura y revisión. Un equipo más pequeño puede obtener más valor de un framework que proporciona coordinación mediante código compartido.
La verdadera competencia es, por tanto, implementación compartida frente a intención compartida. React Native codifica la consistencia directamente en código fuente reutilizable. El nuevo proceso de Shopify codifica la consistencia mediante especificaciones, instrumentación, pruebas y traducción controlada.
Los resultados de Shopify no resuelven el debate entre React Native y nativo
Una reescritura exitosa en 12 semanas no demuestra que dos bases de código nativas seguirán siendo más baratas durante todo su ciclo de vida.
La velocidad de migración es solo la primera medición. La prueba más difícil llega después de que ambas aplicaciones evolucionen de forma independiente. Las nuevas funcionalidades, los cambios en el sistema operativo, las correcciones de emergencia y la rotación de personal revelarán si los agentes pueden mantener las implementaciones alineadas.
La paridad de funcionalidades sigue siendo un requisito declarado. Shopify afirma que Android e iOS deben mantenerse alineados en todo momento. Antes, el código compartido de React Native imponía gran parte de esa condición estructuralmente. El nuevo proceso debe imponerla mediante controles de desarrollo y lanzamiento.
Esto introduce varios modos de fallo. Un agente puede crear un comportamiento equivalente con patrones arquitectónicos incompatibles. Puede copiar una suposición de iOS en Android o preservar un error heredado porque la aplicación de referencia lo contiene.
El código generado también puede satisfacer las pruebas mientras aumenta la duplicación o la deuda técnica. Shopify reconoce riesgos que incluyen deriva arquitectónica, lógica repetida y problemas de rendimiento. La guía del repositorio, el linting, el análisis estático, las comprobaciones de rendimiento y la revisión humana siguen siendo necesarios.
Por lo tanto, la experiencia nativa se vuelve más importante, no menos. Los ingenieros deben juzgar si el Swift generado sigue las convenciones de Apple y si el Kotlin generado encaja con la arquitectura de Android. También deben reconocer comportamientos que un modelo reprodujo fielmente pero que no deberían conservarse.
La migración de Shop se benefició de una implementación de referencia estable. El desarrollo de productos nuevos crea un problema diferente. Cuando ninguna plataforma cuenta con una versión aceptada, los agentes no pueden traducir el comportamiento desde una fuente conocida. Los equipos primero deben definir la intención con suficiente claridad para ambas implementaciones.
El descubrimiento de producto puede dificultarlo. Diseñadores e ingenieros refinan con frecuencia el comportamiento mientras usan una versión inicial. Un componente compartido de React Native aplica ese refinamiento de inmediato en todas las plataformas, mientras que los equipos nativos deben propagarlo y verificarlo dos veces.
Las comparaciones de rendimiento también requieren cautela. Shopify reconstruyó Shop sobre una base limpia y simplificó partes del producto. Los frameworks nativos, las dependencias reducidas, las pantallas retiradas y la limpieza arquitectónica pueden haber contribuido a las mejoras reportadas.
Las mediciones procedían de Shopify, en lugar de una organización independiente de pruebas. Siguen siendo valiosas porque describen un despliegue en producción, pero no deberían convertirse en proporciones universales. Diferentes aplicaciones tendrán distintas rutas de arranque, integraciones nativas y estructuras de equipo.
React Native sigue ofreciendo ventajas que los agentes de programación no eliminan. Una implementación compartida reduce el número de lugares donde la lógica de negocio puede divergir. Su ecosistema también proporciona bibliotecas, prácticas de depuración, herramientas de despliegue y una gran comunidad de desarrolladores React.
La propia Shopify ha enfatizado esas fortalezas. Su migración anterior produjo bases compartidas y ayudó a los desarrolladores a moverse entre aplicaciones. La empresa también afirmó que React Native permitía a los equipos entregar valor sin reconciliar constantemente las diferencias entre plataformas.
La transición de código abierto añade otra incertidumbre. Shopify planea patrocinar React Native Skia hasta finales de 2026, tras lo cual el mantenedor William Candillon continuará el proyecto bajo un nuevo nombre. El repositorio original terminará archivándose.
FlashList presenta un camino diferente. Shopify afirma que la biblioteca de listas de alto rendimiento recibe alrededor de dos millones de descargas por semana. La empresa pretende corregir problemas críticos de compatibilidad mientras discute la administración a largo plazo con otras organizaciones.
Restyle tiene una base de usuarios más pequeña y será archivada. Shopify afirma que seguirá funcionando hasta finales de 2026, con posible apoyo para la transferencia a otro mantenedor. Estas transiciones generan trabajo práctico de planificación para los desarrolladores que dependen de las bibliotecas de Shopify.
También muestran por qué la salida de un usuario importante afecta a un ecosistema incluso sin desacreditar su tecnología. React Native pierde inversión en ingeniería, pruebas de campo y defensa institucional por parte de un adoptante destacado. La gestión comunitaria puede sustituir esa contribución, pero la transición debe tener éxito.
La migración más amplia de la empresa sigue incompleta. Shop es la primera aplicación en trasladarse. La aplicación principal de Shopify contiene más de 300 pantallas, widgets, una aplicación para Apple Watch, complicaciones y Siri Shortcuts.
Shopify afirma que esa aplicación se lanzará de forma nativa más adelante en 2026, seguida por el resto de sus aplicaciones. Esos proyectos ofrecen una prueba más sólida que Shop porque incluyen integraciones de plataforma más amplias y flujos de trabajo críticos para los comerciantes.
Hasta entonces, la conclusión responsable es limitada. Shopify demostró que una migración nativa asistida por agentes puede funcionar con rapidez para una aplicación importante. Aún no ha establecido el coste de mantenimiento a largo plazo en toda su cartera móvil.
Tres señales mostrarán si la apuesta de Shopify se sostiene
La próxima evidencia debe demostrar repetibilidad, paridad sostenida y una transición estable hacia el código abierto.
La primera señal será el lanzamiento nativo de la aplicación principal de Shopify. Sus más de 300 pantallas y amplias integraciones con Apple la convierten en una migración más compleja que Shop. Un lanzamiento puntual con la funcionalidad preservada reforzaría la afirmación de Shopify de que su método escala.
La calidad de ese lanzamiento importa más que la fecha por sí sola. El rendimiento de arranque, la estabilidad de las sesiones, los tiempos de compilación, la accesibilidad, la continuidad analítica y los flujos de trabajo de los comerciantes deberían igualar o mejorar la versión de React Native. Un lanzamiento tardío o irregular debilitaría el argumento a favor de una migración greenfield rápida.
La segunda señal será una paridad sostenida una vez que comience el desarrollo independiente de funcionalidades. Shopify debe demostrar que iOS y Android siguen lanzando funciones equivalentes sin aumentar los retrasos de revisión. La evidencia de varios ciclos de lanzamiento importará más que la velocidad de la migración.
Esta prueba llega al núcleo del desarrollo Shopify Swift Kotlin. Los agentes pueden traducir una función terminada, pero los equipos de producto también modifican los requisitos durante la implementación. Una analítica y un comportamiento coherentes mostrarán si las especificaciones compartidas pueden sustituir al código fuente compartido con el tiempo.
La tercera señal será el futuro de las bibliotecas React Native de Shopify. Un fork fluido de React Native Skia, una gestión duradera de FlashList y una guía clara sobre Restyle respaldarían la afirmación de Shopify de que está gestionando responsablemente su salida.
Un mantenimiento interrumpido contaría una historia distinta. Demostraría que los cambios de arquitectura imponen costes más allá de los repositorios de una sola empresa. Esos costes recaerían sobre los desarrolladores que hicieron planes basándose en los compromisos anteriores de Shopify.
Los líderes de ingeniería deberían observar estas señales antes de copiar la decisión. También deberían establecer su propia línea base para fallos, tiempo de arranque, tamaño de la aplicación, duración de las compilaciones, mantenimiento del framework y trabajo de paridad.
Después podrán ejecutar un prototipo acotado usando una funcionalidad real. La prueba debería incluir analítica, accesibilidad, navegación, estados de error y convenciones de plataforma. Debería medir el tiempo de revisión y la detección de defectos, no solo las líneas de código generadas.
El desarrollo móvil nativo de Shopify es importante porque replantea la reutilización para una era de agentes. No ofrece una respuesta universal sobre React Native frente a desarrollo nativo. En su lugar, plantea una pregunta exigente: si la implementación se vuelve barata, ¿dónde debería situar una organización de ingeniería su fuente de verdad?
Los equipos deberían responder a esa pregunta con evidencia de producción. Deben seguir si los agentes reducen el esfuerzo total de revisión y mantenimiento a lo largo de varios lanzamientos. Si lo hacen, las aplicaciones nativas separadas se vuelven más atractivas. Si la coordinación crece más rápido de lo que mejora la generación de código, la implementación compartida sigue mereciendo su lugar.
