La respuesta corta
Un solo código no significa la mitad de trabajo. Quien lo vende así está preparando una decepción en el mes cuatro.
El ahorro de una app multiplataforma frente a dos apps nativas es real y sostenido, pero está en sitios concretos: la lógica de negocio, el mantenimiento y el equipo. No está en la interfaz — y no está porque nosotros adaptamos cada UI a las guías de su plataforma, que es lo que hace que la app no se sienta ajena en ninguna de las dos.
Es decir: se comparte lo que debe compartirse y se separa lo que el usuario nota. Y ahí es donde el cálculo a tres años cambia de forma.
Dónde está el ahorro
La lógica de negocio se escribe una vez. Reglas de precios, validaciones, estados, sincronización, permisos, cálculos. Es la parte que más cambia a lo largo de la vida del producto y la que más caro sale mantener por duplicado. Escribirla dos veces no solo cuesta el doble: hace que las dos versiones se desincronicen, que es peor.
Una decisión, una implementación. Cuando negocio cambia una regla, se cambia en un sitio. Con dos apps nativas hay dos implementaciones, dos revisiones, dos pruebas y dos oportunidades de que una se quede atrás. La divergencia silenciosa entre plataformas es el coste oculto más caro del modelo nativo doble, y no aparece en ningún presupuesto.
El equipo. Un solo equipo, un solo conjunto de convenciones, una sola base de conocimiento. Eso reduce el tiempo de desarrollo de forma considerable, y no solo por las horas: reduce el coste de formación y el de coordinación. Dos equipos nativos necesitan sincronizarse constantemente para no divergir, y esa sincronización es tiempo de gente cara que no produce funcionalidad.
El desarrollo en remoto. Con un solo código y un solo equipo, trabajar distribuido es mucho más manejable. Con dos plataformas y dos equipos, la coordinación remota multiplica las reuniones y los malentendidos.
Dónde NO está el ahorro
Y esto es lo que casi nadie dice:
La interfaz. Si quieres que la app respete las convenciones de cada plataforma —navegación, gestos, tipografía, comportamiento de los controles—, hay trabajo específico por plataforma. Nosotros lo hacemos, porque una app que ignora las guías de iOS o de Android se nota inmediatamente y se paga en valoraciones.
Las integraciones con el sistema. Notificaciones, biometría, widgets, cartera, permisos, compartir, fondo. Cada plataforma tiene su modelo y su comportamiento, y eso hay que resolverlo dos veces aunque el código sea uno.
Las pruebas. Hay que probar en las dos plataformas igual. El código compartido reduce la superficie de fallo, no la elimina.
La publicación. Dos tiendas, dos ciclos de revisión, dos conjuntos de requisitos que caducan. Idéntico coste.
El cálculo a tres años
El error de comparar solo el proyecto inicial es que la construcción es la parte pequeña. A tres años, lo que pesa es:
| Partida | Dos apps nativas | Un código compartido |
|---|---|---|
| Construcción de lógica de negocio | ×2 | ×1 |
| Evolución de esa lógica, cada cambio | ×2 | ×1 |
| Interfaz adaptada a cada plataforma | ×2 | ×2 (se sigue haciendo) |
| Integraciones con el sistema | ×2 | ×2 |
| Mantenimiento de plataforma obligatorio | ×2 | ×1 código, 2 objetivos |
| Coordinación entre equipos | alta | baja |
| Riesgo de divergencia funcional | alto | nulo |
La última fila no tiene coste en euros hasta que ocurre. Cuando ocurre —una regla de negocio que se comporta distinto en iOS y en Android— el coste es soporte, confianza y una investigación cara para descubrir cuál de las dos está bien.
Cuándo dos nativas siguen siendo la respuesta
Por honestidad, porque no siempre es multiplataforma:
- Cuando el producto es la plataforma. Apps que viven de capacidades muy específicas y muy nuevas de un sistema operativo.
- Cuando solo hay una plataforma. Si el 95 % de tus usuarios está en una, la comparación no aplica.
- Cuando ya hay dos equipos nativos consolidados y funcionando bien. Migrar por ahorro teórico puede costar más de lo que ahorra — la forma de hacerlo sin parar producción está en migrar de React Native a Flutter, y el razonamiento aplica igual viniendo de nativo.
- Cuando el rendimiento gráfico es el producto: juegos, edición en tiempo real.
Cómo calcular tu caso, sin creerte a nadie
En lugar de aceptar un porcentaje, mide sobre tu propio producto:
- Qué porcentaje de tu backlog del último año fue lógica de negocio y qué porcentaje fue interfaz o integración con el sistema. Ahí está tu ahorro potencial real.
- Cuántas incidencias tuviste por comportamiento distinto entre plataformas.
- Cuánto tiempo dedicaron los dos equipos a coordinarse para no divergir.
- Cuánto costó la última actualización obligatoria de plataforma, hecha dos veces.
Con esos cuatro datos, la conversación deja de ser de fe. Y si el resultado sale ajustado, probablemente no había que migrar.
Antes de decidir
- ¿Cuánto del producto es lógica de negocio y cuánto es interfaz?
- ¿Hay hoy divergencias entre las dos apps que nadie ha resuelto?
- ¿Qué equipo lo va a mantener dentro de tres años?
- ¿Hay alguna capacidad de plataforma crítica que condicione la decisión?
La tercera es la que decide de verdad, y casi nunca se pregunta.
Es la conversación que tenemos al principio de un proyecto de Flutter para empresas: no vendemos que sea la mitad de trabajo, explicamos qué mitad se comparte y cuál no.
