La respuesta corta
No se migra de golpe. Se migra pantalla a pantalla, con las dos tecnologías conviviendo en el mismo binario, mientras la app sigue publicada y recibiendo actualizaciones.
Flutter tiene una modalidad documentada para eso: add-to-app. Permite integrar Flutter dentro de una app existente de Android o iOS como módulo, en lugar de empezar de cero. La documentación lo plantea exactamente para este caso: ya tienes una app que no está escrita en Flutter y reescribirla entera no es práctico.
El resultado es una migración sin big bang, sin congelar el producto durante meses y sin una fecha única en la que todo tiene que salir bien.
Cómo funciona la convivencia
En móvil, add-to-app usa el modo multi-motor: una o más instancias de Flutter embebidas en la app anfitriona. Cada instancia es un programa Dart independiente, con su propio estado de aplicación y de interfaz, aislado del resto. La documentación destaca que la sobrecarga de memoria de ese aislamiento es mínima.
Eso da los dos patrones que necesitas para una migración progresiva:
- Pila de navegación híbrida: pantallas Flutter y pantallas nativas conviviendo, con navegación en los dos sentidos.
- Vistas parciales: un componente Flutter incrustado dentro de una pantalla nativa, con scroll e interacción compartidos.
Lo que se toca en cada plataforma
Android. El módulo se integra automáticamente por ganchos de Gradle, o se compila como AAR si tienes un sistema de build propio. Las piezas son FlutterEngine —que permite arrancar y mantener vivo el entorno de Flutter de forma independiente— y FlutterActivity o FlutterFragment para la interfaz. Funciona con Java y con Kotlin.
iOS. El módulo se puede compilar como Swift package, o integrarse mediante fases de build de Xcode. Las piezas son FlutterEngine y FlutterViewController. Funciona con Objective-C y con Swift.
En los dos: flutter attach conecta el depurador y da hot reload con estado sobre la app híbrida en ejecución, desde la línea de comandos o desde el IDE. Es lo que hace que el desarrollo no se vuelva insoportable durante la convivencia.
Las limitaciones, antes de prometer nada
Están documentadas y conviene leerlas antes de dibujar el plan:
| Limitación | Qué implica |
|---|---|
| No hay modo multi-vista en móvil | Solo multi-motor: no se puede compartir estado entre instancias de Flutter |
| No se pueden empaquetar varias librerías Flutter en una misma app | Un solo módulo Flutter, no varios independientes |
Plugins sin soporte de FlutterPlugin | Pueden comportarse de forma inesperada; algunos plugins antiguos asumen que siempre hay una Activity o View de Flutter presente |
| Android exige AndroidX | El módulo Flutter solo soporta aplicaciones AndroidX |
La primera es la que más condiciona el diseño de la migración: si dos pantallas Flutter necesitan compartir estado, no pueden ser dos instancias. O van en la misma instancia, o el estado vive fuera —en la capa nativa o en el backend— y las dos lo consultan.
La última es un requisito de entrada: si la app anfitriona todavía no está en AndroidX, esa migración va antes que la de Flutter.
El orden que funciona
- Inventario de pantallas por dependencia y por riesgo. No por facilidad: por cuántas cosas tocan.
- Empezar por una pantalla de hoja — una que no sea origen de navegación de otras y que no comparta estado. Un detalle, un formulario aislado, una pantalla de ajustes.
- Establecer el puente: cómo se pasan datos entre lo nativo y lo Flutter, y quién es la fuente de verdad de la sesión. Esto se decide una vez y condiciona todo lo demás.
- Migrar por bloques de navegación completos, no por pantallas sueltas repartidas. Saltar de nativo a Flutter y otra vez a nativo dentro de un mismo flujo se nota en las animaciones y en el rendimiento.
- Publicar en cada bloque. Si un bloque no puede salir a producción solo, el bloque es demasiado grande.
- Retirar React Native cuando ya no quede nada suyo, no antes.
Qué mirar en cada release
- Tamaño del binario: convivir dos motores tiene coste. Hay que medirlo desde el primer bloque, no al final.
- Tiempo de arranque en frío, especialmente en la gama baja del parque de dispositivos real.
- Crashes por plataforma y por pantalla, para saber si la regresión viene del lado nuevo o del viejo.
- Consistencia visual en las transiciones entre lo nativo y lo Flutter, que es donde el usuario nota la costura.
Cuándo NO migrar
- Si la app funciona y no hay dolor. Migrar por moda es gastar presupuesto sin comprarse nada.
- Si el problema es el backend. Muchas apps «lentas» lo son por latencia de red y por consultas mal resueltas. Cambiar la capa de UI no arregla eso, y se descubre tarde y caro.
- Si el equipo no va a mantener Flutter. Migrar a una tecnología que nadie del equipo va a poder tocar es cambiar una deuda por otra peor.
- Si el producto está a punto de cambiar de rumbo. Migrar pantallas que van a desaparecer es trabajo tirado.
Cómo saber si tiene sentido
Antes de plantear el plan hay que mirar tres cosas del estado actual: qué dependencias nativas tiene la app hoy, qué versiones mínimas soporta, y cuántas de sus pantallas comparten estado entre sí. Con eso ya se puede decir si la migración es de tres bloques o de doce, y qué hay que resolver antes de empezar.
Eso es lo que hacemos en una auditoría técnica de app móvil antes de proponer nada, y el trabajo posterior es una migración a Flutter por bloques, con el producto vivo todo el tiempo.
Fuente primaria, consultada el 14 de agosto de 2026: Add Flutter to an existing app en la documentación oficial de Flutter.
