Migración de React Native a Flutter: costes

Cada pocos meses, un CTO nos escribe con alguna versión de la misma pregunta. Su equipo tiene una app en React Native. Lleva dos o tres años funcionando. Y ahora algo ha cambiado: necesitan mejor rendimiento, quieren lanzar en escritorio, están añadiendo integraciones de hardware que el bridge de JS complica. La pregunta sobre la mesa es si migrar a Flutter.

Este artículo va de esa decisión. No de “qué framework elijo para un proyecto nuevo” (eso lo cubre nuestra comparativa entre Flutter y React Native). Esta es la pregunta más difícil: ya tienes una base de código React Native, tu equipo la conoce, y estás valorando si el coste de una migración compensa lo que obtendrías al otro lado.

Seamos honestos: Unlock’d nunca ha hecho una migración completa de React Native a Flutter como encargo de cliente. Lo que sí hemos hecho es evaluar la viabilidad de migraciones en llamadas de discovery, auditar bases de código React Native para estimar lo que costaría reconstruirlas en Flutter, y construir apps Flutter en dominios donde los equipos de React Native chocan a menudo con techos. Este artículo se apoya en esa experiencia acumulada, no en un solo proyecto.

Señales de que tu app React Native está tocando techo

React Native funciona bien para muchas apps. Si la tuya cae en una categoría donde empieza a forzar, reconocerás estos patrones.

Rendimiento de animación y renderizado. La arquitectura de bridge de React Native hace que las actualizaciones de interfaz pasen por un runtime de JavaScript. En la mayoría de apps eso es invisible. Pero cuando necesitas control a nivel de frame, como animaciones a 60 fps, visualizaciones en tiempo real o interfaces que se actualizan con cada mensaje de WebSocket, el bridge se convierte en el cuello de botella. Flutter renderiza directamente, sin un runtime en medio. Para la plataforma de subastas Lava esto importaba: el reloj de precio descendente tenía que animarse a 60 fps incluso en hardware Windows de gama baja, con 100 puntos de precio redibujándose 20 veces por segundo. Ese es el tipo de requisito en el que el modelo de renderizado de Flutter te da herramientas que React Native no expone.

Rendimiento en listas grandes. React Native ha mejorado aquí con la New Architecture, pero los equipos siguen reportando un scroll inconsistente en listas complejas, sobre todo con renderers de ítems personalizados o vistas anidadas.

BLE e integración con hardware. El ecosistema BLE de React Native está fragmentado. A menudo acabas cosiendo varios paquetes de distintos mantenedores con distintas premisas. La librería BLE de Flutter está más consolidada: un paquete bien mantenido que cubre el ciclo de vida completo de una conexión. Si vas a añadir conectividad con hardware a tu app, o si las integraciones de hardware fueron lo que te hizo mirar a Flutter en primer lugar, esto pesa de verdad. La companion app de Classified Cycling gestiona conexiones BLE con cuatro tipos de dispositivo en exteriores. Se construyó en Flutter desde el principio, precisamente por esto.

Expansión a web y escritorio. El soporte de web y escritorio de React Native ha mejorado, pero sigue siendo un objetivo secundario. Si necesitas una sola base de código que funcione de forma fiable en iOS, Android, web y Windows escritorio, el soporte multiplataforma de Flutter es realmente equivalente en todos esos destinos. La plataforma de subastas Lava se publica en Windows escritorio y en web desde la misma base de código Flutter, con el mismo motor de renderizado y la misma gestión de estado.

Fricción al migrar a la New Architecture. La New Architecture de React Native (Fabric + TurboModules) es una mejora significativa, pero migrar apps existentes puede doler. Si de todas formas tienes por delante una gran actualización de infraestructura en React Native, algunos equipos encuentran que su coste total se parece al de una reescritura en Flutter, y entonces la pregunta pasa a ser con qué prefieres acabar.

Cuándo migrar NO tiene sentido

Esta es la sección que rara vez verás en el material de marketing sobre Flutter. Migrar no siempre es la decisión correcta.

Tu app funciona bien. Si los usuarios están contentos, los fallos son raros y no hay quejas de rendimiento, el argumento de negocio para migrar es débil. Una migración es una inversión grande cuyo resultado se ve idéntico para el usuario. Las mejoras técnicas tienen que traducirse en resultados de negocio reales.

Tu equipo de React Native es productivo y está a gusto. El ecosistema de React Native es maduro. Si tu equipo va rápido, va confiado y no choca con muros, cambiar de framework implica un periodo de menor velocidad mientras aprenden Dart y los patrones de Flutter. Ese coste es real.

No hay expansión multiplataforma prevista. La fuerza de Flutter se acumula cuando publicas en varias plataformas desde una sola base de código. Si el móvil es tu destino permanente y no tienes planes de escritorio ni web, esa ventaja no aplica en tu caso.

Presupuesto ajustado sin ROI claro. Las migraciones cuestan dinero. Si no puedes articular un resultado de negocio concreto derivado de la migración (entregar funcionalidades más rápido, soportar una nueva plataforma, reducir fallos, una integración de hardware hoy imposible), el argumento no se sostiene. La tecnología puntera por sí sola no es un argumento de negocio.

Rangos de coste y plazo de una migración

Estas son estimaciones honestas basadas en lo que hemos visto durante encargos de discovery. No son garantías. Los proyectos reales son más desordenados.

Hay unas cuantas cosas que disparan el coste más de lo que sugiere el número de pantallas:

Equivalentes de los módulos nativos. Cada módulo nativo de React Native necesita un equivalente en Flutter. Algunos tienen sustituto directo. Otros exigen platform channels a medida o, en algunos casos, bindings FFI a código nativo. Inventaría tus módulos nativos pronto. Suele ser la mayor fuente de variación en la estimación.

Reescritura de la gestión de estado. Los patrones de Redux y MobX no se mapean 1:1 a Riverpod o Bloc. La lógica es portable, el código no. Una app grande con un store Redux maduro exigirá un rediseño arquitectónico deliberado, no una traducción.

Diferencias de comportamiento por plataforma. Los casos límite del comportamiento de iOS y Android que tu equipo aprendió en producción hay que reaprenderlos en contexto Flutter. Cosas como el comportamiento al evitar el teclado, la gestión de safe areas, los flujos de permisos por plataforma y el enrutado de deep links tienen idiomas ligeramente distintos.

Reconstrucción de la infraestructura de pruebas. Tus widget tests y tests de integración actuales no se transfieren. Reconstruyes la suite desde cero en el framework de pruebas de Flutter.

Errores habituales en una migración

Los equipos que subestiman una migración tropiezan casi siempre con el mismo conjunto de problemas.

Estrategias de migración

No todas las migraciones siguen el mismo patrón. Hay tres enfoques principales, cada uno con un perfil de riesgo distinto.

Para la mayoría de equipos con los que hablamos, la reescritura completa es la opción más práctica en apps pequeñas y medianas. El patrón strangler resulta atractivo porque parece menos arriesgado, pero mantener una base de código híbrida de RN y Flutter es realmente complejo. Mantienes dos sistemas de gestión de estado, dos stacks de navegación y un puente entre ambos. La carga operativa se acumula rápido. El patrón strangler tiene más sentido en apps grandes y de mucho tráfico, donde un cambio de golpe es comercialmente arriesgado.

Si estás valorando una migración por necesidades de integración con hardware, consulta nuestro artículo sobre desarrollo de apps BLE con Flutter para ver qué implica realmente ese trabajo. Si tu app tiene funcionalidad de e-commerce y sopesas una reconstrucción frente a un enfoque híbrido, nuestro artículo sobre la integración de Flutter con Magento cubre ambos patrones.

Cómo es un encargo de discovery

Cuando los equipos vienen con preguntas de migración, así abordamos la evaluación.

Auditoría de la base de código. Revisamos la base React Native existente: número de pantallas, complejidad de componentes, inventario de módulos nativos, arquitectura de gestión de estado, cobertura de pruebas y configuración de CI/CD. El objetivo es un inventario factual, no un juicio sobre la calidad.

Inventario de módulos nativos. Mapeamos cada módulo nativo a su equivalente en Flutter, o lo marcamos como trabajo a medida. Es con diferencia la entrada más importante para la estimación de coste. Una base con cinco módulos nativos que tienen equivalentes Flutter bien mantenidos no se parece en nada a una con cinco módulos que exigen implementaciones a medida.

Puntuación de complejidad. Asignamos un nivel de complejidad a cada área principal: complejidad de la interfaz, profundidad de la gestión de estado, integraciones nativas, requisitos offline y comportamiento específico de plataforma. Eso da una estimación ponderada en lugar de una basada en pantallas.

Estimación de plazo y presupuesto. A partir de la auditoría producimos una estimación por rangos, con intervalos de confianza honestos. Especificamos qué supuestos sostienen la estimación y qué la haría crecer.

Recomendación de seguir o parar. Damos nuestra opinión honesta sobre si migrar merece la pena para esa app y ese contexto de negocio concretos. Si la respuesta es que no, lo decimos. Una evaluación acertada es más útil que un proyecto que arranca por los motivos equivocados.

Conclusiones clave

Las decisiones de migración merecen más rigor del que les dedica la mayoría de equipos. Antes de comprometerte, asegúrate de poder responder a estas preguntas.

¿Sabes nombrar el problema concreto que resuelve la migración? El rendimiento de una pantalla determinada, la expansión a escritorio, una integración de hardware que hoy no puedes construir, una arquitectura que frena a tu equipo. Si la respuesta es vaga, el ROI también lo será.

¿Has inventariado tus módulos nativos? Ese único factor explica la mayor parte de la variación en las estimaciones de coste de una migración. Hazlo antes que cualquier otro trabajo de alcance.

¿Aguanta el argumento de negocio en el horizonte temporal de la migración? Una migración de 4 a 6 meses que da como resultado 18 meses de entrega más rápida tiene sentido. Una migración de 6 meses para una app con releases estables y poco frecuentes cuesta más de justificar.

¿Has considerado la alternativa strangler? En apps grandes, incrustar módulos Flutter de forma incremental puede reducir el riesgo comercial, aunque aumente la complejidad técnica. La respuesta correcta depende del tamaño de tu equipo, de la presión comercial y de tu tolerancia al riesgo.

Los equipos con mejores migraciones son los que entraron con datos precisos. Los que sufren son los que subestimaron la complejidad de sus módulos nativos y dieron por hecho que la base de código se portaría más rápido de lo que lo hizo.