Add-to-app es el mecanismo oficial de Flutter para embeber un módulo de Flutter dentro de una app nativa existente de iOS o Android. La app anfitriona sigue siendo exactamente lo que es —tu base de código en Swift o Kotlin, tu proceso de publicación, tus usuarios— y Flutter llega como un módulo compilado detrás de ella, renderizando las pantallas que decidas darle. Cada una de esas pantallas se escribe una vez y funciona en ambas plataformas.

Esta página es para equipos que quieren Flutter dentro de la app que ya tienen: un producto nativo que nadie va a reescribir, cuyas próximas funcionalidades siguen costando el doble porque hay que construirlas por separado para iOS y Android. Si tu objetivo real es acabar enteramente en Flutter, ese es otro tipo de proyecto con la misma mecánica: lee mejor migración desde React Native y nativo, que es honesta al reconocer que es una reescritura. Aquí no se reescribe nada: la app nativa sigue siendo el producto, y Flutter se gana su sitio funcionalidad a funcionalidad.

Los proyectos que llevamos

  • Una funcionalidad piloto: una funcionalidad acotada construida en Flutter y publicada dentro de tus dos apps nativas, con el coste de integración y el beneficio medidos en lugar de discutidos
  • Igualar funcionalidades entre plataformas: la pantalla que tu app de iOS tiene y la de Android no (o al revés), construida una vez para ambas en lugar de una segunda vez para una
  • La superficie nueva: un programa de fidelización, un flujo de reservas, un chat; una adición autocontenida a un producto nativo maduro, que llega a ambas plataformas con un solo presupuesto
  • Cimientos de adopción: el andamiaje del módulo, la integración del router, el cableado de CI y los contratos de platform channels bien montados, para que tus propios ingenieros publiquen las funcionalidades

Para quién es, y quién debería migrar en su lugar

Add-to-app se amortiza bajo condiciones concretas, y preferimos nombrarlas antes que venderle una integración a un equipo que necesita otra cosa.

Señales de que add-to-app encaja

  • Cada funcionalidad de la hoja de ruta se construye dos veces, y las versiones de iOS y Android de tu app han empezado a distanciarse en capacidades
  • La app es demasiado grande o está demasiado probada para reescribirla, así que «usa Flutter y ya» nunca ha sido una respuesta disponible
  • Quieres evaluar Flutter con trabajo real de producción —una funcionalidad, usuarios reales, con mediciones— antes de asumir un compromiso mayor
  • Dotar de personal por igual a dos equipos de plataforma es difícil, y las superficies nuevas se atascan en la plataforma que ande corta de gente ese trimestre

Cuándo NO es la decisión correcta

  • La app es lo bastante pequeña como para que una construcción nueva en Flutter o una migración pantalla a pantalla cueste menos que mantener una costura nativo–Flutter: la integración tiene sobrecoste, y una app anfitriona pequeña no puede amortizarlo
  • La decisión de acabar 100 % en Flutter ya está tomada: entonces llévalo como una migración desde el primer día, con un mapa de migración, en lugar de derivar hacia una
  • La app ya es React Native: embeber un segundo runtime multiplataforma junto al primero agrava el problema en vez de resolverlo; las opciones realistas de ese equipo son quedarse donde está o migrar
  • La funcionalidad que quieres es una capacidad profunda de plataforma —una experiencia centrada en widgets, funcionalidad pensada para el Watch— donde Flutter es la herramienta equivocada, y te lo diremos

La lectura honesta: una app híbrida es una costura permanente: dos cadenas de herramientas, dos conjuntos de convenciones y una frontera que todos los ingenieros del equipo tienen que entender. Add-to-app merece ese coste cuando la app anfitriona es demasiado grande para reescribirla y la hoja de ruta sigue pagando el impuesto de las dos plataformas. Si ninguna de las dos cosas es cierta en tu app, una de las páginas vecinas es la mejor respuesta, y la primera llamada es donde te decimos cuál.

Cómo funciona la adopción incremental

El flujo add-to-app

Paso 1

La app nativa sigue siendo el producto

Tus apps de iOS y Android siguen publicándose sin cambios: sin congelaciones, sin reescritura paralela, sin un cambio de golpe en el horizonte

Paso 2

Se embebe el módulo de Flutter

Un módulo de Flutter se integra en ambas apps anfitrionas, compartiendo su navegación, autenticación y analítica mediante contratos definidos

Paso 3

Se publica la funcionalidad piloto

Una funcionalidad acotada se construye una vez en Flutter y se lanza dentro de ambas apps, midiendo tamaño y coste de arranque antes y después

Paso 4

La adopción crece funcionalidad a funcionalidad

Cada superficie nueva que aterriza en el módulo es una que no construiste dos veces, y cada una es una decisión, no una obligación

Paso 5

Tú decides el final del camino

Quédate en híbrido indefinidamente, entrega el módulo a tu propio equipo o convierte el impulso en una migración completa; cada frontera es un punto de parada

El flujo es deliberadamente la misma maquinaria que usa nuestro servicio de migración: un módulo de Flutter detrás de un router compartido, pantallas que se trasladan una a una. La diferencia es el destino: una migración retira la app anfitriona al final, y la adopción nunca tiene por qué hacerlo. Eso también significa que la adopción se convierte limpiamente en una migración más adelante si el módulo se lo gana, sin tirar nada.

Qué exige realmente add-to-app

Un solo motor, con un ciclo de vida gestionado

Un módulo de Flutter trae consigo el motor de Flutter, y el motor es un recurso que la app anfitriona debe gestionar deliberadamente: precalentado para que la primera pantalla de Flutter se abra sin un arranque visible, compartido entre puntos de entrada en lugar de instanciarse por pantalla, y liberado cuando la plataforma reclama memoria. Hacerlo mal es invisible en una demo y evidente en producción. Es lo primero que construimos, no lo último que afinamos.

Navegación a través de la frontera

A los usuarios no les importa qué framework renderizó la pantalla en la que están, y la navegación debe actuar en consecuencia: gestos de retroceso que se comportan según la convención de cada plataforma, enlaces profundos que aterrizan en pantallas de Flutter con la misma fiabilidad que en las nativas, y estado que sobrevive al cruce en ambas direcciones. El contrato de router entre anfitriona y módulo es la pieza de la arquitectura add-to-app que decide si la costura es invisible o una fuente permanente de bugs.

Servicios compartidos, prestados en lugar de duplicados

Tu app ya tiene autenticación, analítica, red y feature flags. El módulo de Flutter debe tomarlos prestados a través de , no crear copias propias, que es la vía por la que una app híbrida acaba con dos sesiones, dos esquemas de eventos y métricas en las que nadie confía. Definir esos contratos de canal con precisión es la mayor parte del proyecto de cimientos, y es trabajo que rinde en cada funcionalidad que viene después.

Dos cadenas de herramientas en un solo pipeline

Tras la integración, tu compila el módulo de Flutter y ambas apps anfitrionas, y el módulo se versiona contra dos trenes de publicación que no siempre se moverán juntos. Cableamos la compilación del módulo en tu pipeline existente —con caché, reproducible y propiedad de tu repositorio en lugar de un portátil— porque una integración que tu CI no puede compilar no está integrada.

Una costura con la que tus diseñadores puedan vivir

Flutter dibuja sus propios píxeles, y eso tiene dos caras: no heredará tus componentes nativos, pero reproducirá tu sistema de diseño con exactitud, una vez que tus tokens, tipografía y espaciados estén trasladados al tema del módulo. Hacemos ese traslado como parte de los cimientos, para que un usuario que pasa con el scroll de una pantalla nativa a una de Flutter no tenga forma de saber dónde estaba la frontera.

Los costes, medidos en lugar de afirmados

Embeber Flutter añade peso real: del orden de varios megabytes en una build de release de Android y algo más en iOS, además del arranque del motor la primera vez que se abre una pantalla de Flutter. Las cifras exactas dependen de tu app, y por eso los entregables del piloto incluyen las mediciones de antes y después del tamaño del binario y del tiempo de arranque: decides si ir más lejos con datos de tu propio producto, no de un artículo de benchmarks.

Precedente en producción

Add-to-app lleva años siendo un modelo de integración soportado de Flutter, y su usuario más conocido es Google Pay, que adoptó Flutter dentro de una app nativa existente con cientos de millones de usuarios antes de comprometerse más. El patrón es el que describe esta página: embeber, publicar una superficie, medir y luego decidir. Nuestro propio historial de entrega con él viene del trabajo de migración, donde la misma maquinaria de módulo detrás de un router traslada apps enteras; la adopción usa esa maquinaria con un compromiso más ligero.

Cómo trabajamos

Cimientos y piloto de alcance cerrado. Integramos el módulo en ambas apps anfitrionas, trasladamos los tokens de diseño, definimos los contratos de canal y publicamos la primera funcionalidad: un proyecto acotado con las mediciones como parte del entregable. Nuestro proceso de desarrollo describe cómo llevamos el trabajo acotado semana a semana.

Ingenieros integrados. Nuestros ingenieros de Flutter se suman a tu equipo nativo, en tu repositorio y tus sprints, y construyen el módulo junto a las personas que son dueñas de la app anfitriona; mira ampliación de equipo. Es la forma natural una vez que el piloto se ha validado y el módulo se convierte en un lugar donde tu hoja de ruta aterriza con regularidad.

En cualquiera de los dos casos, enviamos un presupuesto detallado en un plazo de dos días laborables desde que entendemos los requisitos.

Cuánto cuesta una integración add-to-app

El proyecto de cimientos más piloto se presupuesta después de ver la app: el coste de integración lo determina la anfitriona —su arquitectura de navegación, su sistema de compilación, cómo expone sus servicios compartidos— mucho más que la propia funcionalidad piloto, así que una cifra producida antes de mirar la base de código sería ficción. Como referencia, un piloto acotado queda muy por debajo de lo que cuesta una app independiente: los niveles publicados en la página de desarrollo de apps con Flutter empiezan en 12-24 mil € por un MVP completo, y una funcionalidad piloto dentro de una app anfitriona existente es una fracción de ese alcance.

Para el modelo de ingenieros integrados se aplica la tarifa publicada de ampliación de equipo: 8-11,2 mil € por ingeniero senior al mes. Y si el final honesto de la hoja de ruta es una app enteramente en Flutter, presupuéstalo como lo que es: una migración, que esa página dimensiona frente a una reconstrucción completa, no como una adopción a la que se le quedó pequeño el nombre.

Preguntas frecuentes

Dudas habituales de los equipos que se plantean Flutter dentro de una app nativa existente.

Sí: para eso existe precisamente el modelo de integración add-to-app de Flutter. Un módulo de Flutter se embebe en tu app existente en Swift o Kotlin, se conecta a su navegación, autenticación y analítica mediante platform channels, y renderiza las pantallas que decidas construir en él. Tu app sigue publicándose sin cambios durante todo el proceso; el módulo se añade junto al código que tienes, no en su lugar. Cada pantalla de Flutter se escribe una vez y funciona dentro de tus apps de iOS y de Android.
No. La adopción y la migración comparten mecánica —un módulo de Flutter detrás de un router compartido—, pero una migración se compromete a retirar la app nativa al final, y la adopción nunca tiene por qué hacerlo. Cada frontera entre funcionalidades es un punto de parada legítimo: algunos productos se quedan híbridos indefinidamente con Flutter a cargo de un puñado de superficies, otros entregan el módulo a su propio equipo, y otros convierten el impulso en una migración completa cuando el módulo se lo ha ganado. Nada de lo construido durante la adopción se tira si después decides ir más lejos.
El motor y el módulo de Flutter añaden peso real: del orden de varios megabytes en una build de release de Android y algo más en iOS. La cifra precisa depende de tu app y de lo que contenga el módulo, y por eso nuestro proyecto piloto incluye mediciones de antes y después del tamaño del binario y del tiempo de arranque en tu producto real. Tomas la decisión de adopción a partir de tus propios números, no de un benchmark genérico.
Mecánicamente funciona: Flutter puede embeberse en una app anfitriona React Native igual que en una totalmente nativa. Estratégicamente rara vez tiene sentido: estarías ejecutando dos runtimes multiplataforma, dos puentes y tres estilos de interfaz en un solo binario, lo que agrava el problema de mantenimiento en lugar de resolverlo. Para un equipo de React Native descontento con su situación, las opciones realistas son quedarse donde está o migrar a Flutter pantalla a pantalla, y nuestra página de migración empieza diciéndote quién no debería hacer ninguna de las dos cosas.
Sí. Add-to-app lleva años siendo un modelo de integración soportado de Flutter, y su adoptante más conocido es Google Pay, que embebió Flutter dentro de una app nativa con cientos de millones de usuarios antes de ampliar su compromiso. El patrón de embeber un módulo, publicar una superficie, medir y luego decidir está más que rodado. Los riesgos de ingeniería que quedan son los detalles de integración —el ciclo de vida del motor, la navegación a través de la frontera, los servicios duplicados—, que es exactamente el trabajo que un proyecto de cimientos estructurado adelanta.
Para el piloto, no: lo construimos nosotros, y tu equipo revisa la frontera del módulo en lugar del Dart que hay dentro. Si la adopción de Flutter crece, algunos de tus ingenieros querrán trabajar en el módulo, y Dart queda muy cerca de Swift o Kotlin: tipado fuerte, recolección de basura y más parecido a lo que ya escriben de lo que sería JavaScript. El modelo de ingenieros integrados existe exactamente para esta transición: nuestra gente construye junto a la tuya hasta que el módulo es una base de código de la que tu equipo es dueño, no una que simplemente aloja.

Lee la página de migración si el destino es todo Flutter, ampliación de equipo para el modelo de ingenieros integrados, o empieza por el pilar de desarrollo de apps con Flutter.