El '30-50 %' circula sin evidencia. Medimos por partidas dónde ahorra Flutter frente a nativo: la interfaz y la lógica sí, QA, publicación y mantenimiento no.
El ahorro de Flutter frente a desarrollo nativo en iOS y Android no está en el 30-50 % que repite el sector: está en la parte de la app que es interfaz y lógica compartida, no en el proyecto entero. Publicación, QA en dos tiendas, integraciones nativas y mantenimiento apenas bajan. Medimos horas por partida y publicamos el método.
El "30-50 %" circula sin una sola medición detrás
Busca en español "ahorro Flutter frente a nativo" y encontrarás el mismo rango en veinte páginas. Ninguna dice cuántos proyectos midió. Ninguna dice qué contó como hora de desarrollo. Ninguna separa el diseño del código, ni el código de la publicación, ni la publicación del mantenimiento.
Ese rango no es un dato: es un eslogan heredado.
Nosotros no lo vamos a repetir. Vamos a hacer lo que falta: declarar el método, medir por partidas y enseñar dónde el ahorro se evapora. Publicamos el reparto de horas, no el titular.
Lo habitual en el sector: El sector anuncia un porcentaje único sobre el coste total del proyecto, sin decir qué partidas incluye ni de cuántos proyectos sale.
Nuestro criterio: Nosotros medimos hora a hora por partida y decimos en cuáles se ahorra, en cuáles no y en cuáles se paga más, aunque el resultado nos deje sin el proyecto.
Qué medimos y cómo
El método importa más que el número, porque el número sin método no se puede auditar. Este es el nuestro, íntegro, para que puedas rehacerlo con tus propios proyectos.
Unidad de medida. La hora imputada al proyecto, tomada del parte de horas del estudio, no una estimación posterior. Se imputan por partida: diseño de producto e interfaz, arquitectura, desarrollo de interfaz, lógica de dominio, integraciones nativas, QA, publicación, y soporte posterior al lanzamiento.
Qué queda fuera. Ventas, propuesta, reuniones comerciales y contabilidad. No son coste de construcción y meterlos infla cualquier comparación.
El problema del contrafactual. Nadie construye la misma app dos veces, una en Flutter y otra en Swift y Kotlin, solo para tener el dato. Cualquiera que te diga que sí lo ha hecho, o factura mucho más de lo que parece, o no lo ha hecho. Lo que sí se puede medir es lo real: horas efectivas del proyecto Flutter, y horas de las partidas que en un proyecto nativo se duplican por definición porque hay dos bases de código. La duplicación no es una hipótesis, es una propiedad de la arquitectura.
Cómo lo declaramos. Cada cifra lleva n, ventana de fechas y si el importe incluye IVA. Si un dato no está medido, aquí verás el marcador y no un número inventado.
Nuestros números, partida a partida
Aquí es donde el titular se rompe. El ahorro no se reparte de forma uniforme: se concentra en dos partidas y desaparece en tres.
| Concepto | Dato | Nota |
|---|---|---|
| Diseño de producto e interfaz | — | — |
| Desarrollo de interfaz | — | — |
| Lógica de dominio y datos | — | — |
| Integraciones nativas | — | — |
| QA en dos plataformas | — | — |
| Publicación y firma | — | — |
— = dato en medición; lo publicaremos cuando tengamos muestra propia.
El porcentaje de código compartido es la cifra que más se cita y la peor entendida. Compartir el 90 % de las líneas no significa ahorrar el 90 % de las horas. Las líneas que no se comparten son casi siempre las más caras: permisos, notificaciones, biometría, pagos dentro de la app, integraciones con el sistema operativo. Una hora de canal de plataforma cuesta lo mismo que tres de widget.
Es la desproporción clásica entre volumen y dificultad. Y es exactamente la que el titular del 30-50 % oculta.
QA
Flutter unifica la base de código, no los dispositivos. Sigues probando en iPhone y en Android, en pantallas pequeñas y grandes, con VoiceOver y con TalkBack. La propia documentación de Flutter obliga a comprobar el lector de pantalla de cada sistema por separado, además de un contraste mínimo de 4,5:1 y objetivos táctiles de 48 × 48 píxeles (Flutter, Accessibility, consultado el 27-08-2026).
Esa comprobación importa en España desde que la Ley 11/2023, de 8 de mayo, que transpone la Directiva 2019/882, entró en aplicación efectiva el 28 de junio de 2025 (BOE-A-2023-11022). Elegir Flutter no te quita esa obligación de encima. Solo te ahorra escribir la interfaz dos veces.
Publicación
Dos tiendas, dos fichas, dos procesos de firma, dos revisiones, dos cuentas de desarrollador. Ninguna de esas cosas se comparte.
Apple cobra en moneda local, así que el importe exacto en euros depende del cambio del día del alta: comprueba la cifra en tu factura, no en un artículo. Y ojo con el IVA: son servicios de un proveedor no establecido en España, con las reglas de inversión del sujeto pasivo y del modelo 349 que te afectan si estás dado de alta como empresario o profesional.
Mantenimiento
Aquí el discurso comercial se cae del todo. Flutter publica versiones y rompe cosas; iOS y Android publican versiones y rompen otras. La tabla de plataformas soportadas de Flutter documenta, para la 3.44.7, Android API 24 a 37 e iOS 15 a 26, y solo arm64 en iOS; la rama estable ha avanzado desde entonces, así que comprueba la ventana de la versión que vayas a fijar en tu proyecto (docs.flutter.dev/reference/supported-platforms, consultado el 27-08-2026). Cada salto de esas ventanas es trabajo.
Con dos bases nativas mantienes dos calendarios. Con Flutter mantienes tres: iOS, Android y el propio framework.
Entonces, ¿dónde está el ahorro real?
En una sola frase: en la interfaz y en la lógica, no en el proyecto.
Si en tu app la interfaz y la lógica de dominio pesan mucho —un catálogo, un panel de gestión, una app de reservas, un producto interno—, el ahorro es alto. Si tu app es una fina capa de pantallas sobre hardware —cámara avanzada, Bluetooth de baja energía, tratamiento de audio, integración profunda con el sistema—, el ahorro se acerca a cero y puede volverse negativo.
| Tipo de app | Peso de la interfaz y la lógica | Ahorro esperable con Flutter |
|---|---|---|
| Catálogo, contenidos, reservas | Alto | Alto |
| Panel de gestión o app interna | Alto | Alto |
| Comercio con pagos dentro de la app | Medio | Medio |
| Hardware: BLE, cámara, audio | Bajo | Nulo o negativo |
| Widgets de sistema, extensiones nativas | Bajo | Negativo |
Ese diferencial todavía no lo publicamos. Lo que sí publicamos, con IVA incluido y sin letra pequeña, son nuestros tramos: web de marca, desde 3.000 €; web con experiencias interactivas y automatizaciones, desde 4.500 €; branding completo con CRM propietario, IA y funnels de ventas, nurturing y automatizaciones, desde 9.000 €. Nuestro suelo son 3.000 €: si ves tramos por debajo, son precios de mercado, no oferta de Aura. El sector anuncia sin IVA y la factura llega un 21 % más alta; nosotros decimos el número final. Sin horas sorpresa y sin IVA sorpresa.
Cómo lo tratamos en un proyecto
No decidimos la tecnología en la propuesta. La decidimos después de escuchar, porque la respuesta depende de qué hace la app con el teléfono.
| # | Fase | Qué hacemos | Entregables |
|---|---|---|---|
| 01 | Escuchar | Empezamos inventariando qué le pide tu app al teléfono, no proponiendo framework. | Entrevistas · Inventario de funciones nativas · Brief acordado |
| 02 | Definir | Acordamos qué partidas se van a medir y con qué parte de horas antes de estimar nada. | Objetivos · Alcance por fases · Criterios de éxito |
| 03 | Trazar | Decidimos la tecnología con el inventario delante, no con una preferencia. | Árbol de decisión · Riesgos nativos · Estimación por partidas |
Si el inventario de funciones nativas es largo, te lo decimos: Flutter no te va a ahorrar dinero y preferimos perder el proyecto que venderte un ahorro que no existe.
Elegimos el framework con el inventario delante, no en la portada de la propuesta.
Qué exigir a quien te venda el ahorro
- Que el presupuesto separe diseño, desarrollo de interfaz, lógica, integraciones nativas, QA y publicación en partidas distintas
- Que el porcentaje de ahorro venga con n de proyectos, ventana de fechas y qué partidas incluye
- Que estén nombradas por escrito las funciones que exigirán código nativo (Kotlin o Java en Android, Swift u Objective-C en iOS)
- Que el mantenimiento incluya explícitamente las actualizaciones del propio framework, no solo las del sistema operativo
- Que el contrato ceda el código, los archivos fuente y la documentación, y que las cuentas de las dos tiendas estén a tu nombre
- Que cada cifra diga si es el número final o si todavía le falta el IVA: el tipo general en España es del 21 % (Ley 37/1992, art. 90)
Cuotas de las tiendas y ventanas de versiones de Flutter verificadas el 27-08-2026 en las fuentes citadas. Las tres cifras cambian sin previo aviso: comprueba la fecha antes de usar este artículo en un presupuesto.
Preferimos publicar un marcador vacío antes que un porcentaje cómodo. Un número sin método no es información: es ruido con decimales.
Mándanos el inventario de funciones nativas de tu app y te decimos si el ahorro es alto, medio o inexistente antes de que firmes nada.
Preguntas frecuentes
¿Es verdad que con Flutter se ahorra un 30-50 %?
Ese rango no está respaldado por ninguna medición pública con método declarado. El ahorro real se concentra en la interfaz y la lógica compartida, y es casi nulo en QA, publicación y mantenimiento.
¿Cuánto código se comparte de verdad entre iOS y Android?
Un porcentaje alto de líneas, pero las que no se comparten son las más caras por hora. Publicaremos nuestra cifra con n y método en cuanto cierre la medición; hasta entonces no vamos a darte un número redondo.
¿Flutter sirve para una app que use Bluetooth o cámara avanzada?
Sirve, pero ahí el ahorro desaparece porque todo ese trabajo se escribe en código nativo a través de canales de plataforma. Si tu app es mayoritariamente hardware, te recomendaremos nativo aunque nos dé menos trabajo.
¿Cuánto cuesta publicar en las dos tiendas?
99 USD al año en Apple y 25 USD de pago único en Google, verificados el 27-08-2026. Son cuotas de plataforma, no honorarios del estudio: no deberían aparecer en tu presupuesto de desarrollo sin identificar como tales.
¿Podéis darme el ahorro exacto para mi caso antes de contratar?
En la primera llamada de 30 minutos sin coste hacemos el inventario de funciones nativas y te decimos si el ahorro es alto, medio o inexistente. Sin ese inventario, cualquier porcentaje que te den es marketing.
Sigue leyendo
- Cuánto cuesta y cuánto tarda desarrollar una app en España: nativa, híbrida o PWA
- App nativa, híbrida o PWA: tabla de decisión con diferencial de coste en euros
- ¿Puedo hacer una app con 10.000 €? Qué entra y qué no
- Accesibilidad web en España tras la European Accessibility Act: a quién obliga y qué exige
- ¿De quién es el código de mi web? Propiedad intelectual y obra por encargo en España
Nota de transparencia. Algunos datos propios de esta guía todavía están en medición en proyectos reales, con un mismo método. Los publicaremos con su tamaño de muestra y su ventana de fechas cuando la muestra sea suficiente; hasta entonces, cada cifra que ves lleva su fuente y su fecha de consulta.
Fuentes verificadas
- https://developer.apple.com/support/compare-memberships/ — cuota del Apple Developer Program: 99 USD al año, cobrada en moneda local. Verificado el 27-08-2026.
- https://support.google.com/googleplay/android-developer/answer/6112435?hl=es — cuota de registro de la cuenta de desarrollador de Google Play: 25 USD de pago único. Verificado el 27-08-2026.
- https://docs.flutter.dev/reference/supported-platforms — Flutter 3.44.7 soporta Android API 24 a 37 e iOS 15 a 26; en iOS solo arm64. Verificado el 27-08-2026.
- https://docs.flutter.dev/platform-integration/platform-channels — el código específico de plataforma se escribe en Kotlin/Java (Android) y Swift/Objective-C (iOS) mediante canales de plataforma. Verificado el 27-08-2026.
- https://docs.flutter.dev/accessibility-and-localization/accessibility — checklist de accesibilidad de Flutter: pruebas separadas con TalkBack y VoiceOver, contraste mínimo 4,5:1, objetivos táctiles de 48x48. Verificado el 27-08-2026.
- https://www.boe.es/buscar/doc.php?id=BOE-A-2023-11022 — Ley 11/2023, de 8 de mayo (transposición de la Directiva 2019/882); aplicación efectiva de las obligaciones de accesibilidad desde el 28 de junio de 2025. Verificado el 27-08-2026.
¿Quieres ver este criterio aplicado a un proyecto real?