Desarrollo nativo vs multiplataforma: cómo decidir

La comparativa de desarrollo nativo vs multiplataforma suele resolverse mal por el mismo motivo: quien la escribe ya había decidido antes de empezar. Si el estudio solo sabe hacer nativo, el multiplataforma «sacrifica calidad». Si solo sabe Flutter, el nativo es «el doble de caro». Publicidad, no ingeniería.

En Docastix construimos apps móviles con los dos enfoques, y no por indecisión: hemos tomado decisiones opuestas en dos proyectos y las dos siguen pareciéndonos correctas. Dormus es nativa en iOS y en Android. Saher Connect es una sola base de código en Flutter. Lo que viene es el razonamiento que nos llevó a cada una.

Respuesta rápida: ¿nativo o multiplataforma?

Elige nativo cuando la app es el producto y la retención se paga en acabado; elige multiplataforma cuando la app es una herramienta de trabajo y mandan el plazo y el presupuesto. El rendimiento ya casi nunca decide: en apps de negocio bien construidas la diferencia es imperceptible. Sí decide cuánta superficie del sistema tocas, a qué ritmo necesitas estrenar novedades de iOS y Android, y con cuánta gente mantendrás esto en dos años.

Si necesitas quedarte con tres criterios: cuánto vale un punto de retención, cuánto sistema toca la app y a cuánta gente podrás pagar para mantenerla.

Qué significa hoy «nativo» y qué no

Nativo es construir cada app con las herramientas oficiales de su plataforma: Swift con SwiftUI en iOS, Kotlin con Jetpack Compose en Android. Los dos son declarativos y se parecen: quien domina Compose entiende SwiftUI en semanas.

Lo que nativo no significa:

• No significa «más rápido» automáticamente. Una app nativa con una lista mal construida y llamadas sin caché va peor que una Flutter bien hecha.
• No significa dos equipos separados. Son dos capas de interfaz: el backend, el diseño y buena parte del proceso de desarrollo siguen siendo comunes.
• No significa renunciar a compartir código. Con Kotlin Multiplatform compartes la lógica y mantienes interfaz nativa.

La ventaja difícil de discutir es el acceso el día uno: cuando Apple o Google presentan una API, tu equipo la usa esa semana con la beta del SDK. En multiplataforma esperas a que el framework la exponga o escribes tú el puente.

Qué significa hoy multiplataforma: Flutter, React Native, KMP y .NET MAUI

• Flutter compila Dart a código nativo y pinta su propia interfaz con Impeller, que es el renderizador por defecto en iOS y en Android API 29 o superior. Al dibujar sus propios píxeles tienes control total del diseño, a costa de que los widgets no son los del sistema. En la versión 3.44, de mayo de 2026 Google declaró 1,5 millones de desarrolladores al mes.
• React Native usa componentes del sistema y TypeScript. Su gran cambio fue la nueva arquitectura: JSI, Fabric y TurboModules sustituyeron al puente asíncrono y pasaron a ser el comportamiento por defecto en la versión 0.76. Desde la 0.82 ya no se puede desactivar: la antigua está congelada. La rama actual es la 0.87, de agosto de 2026.
• Kotlin Multiplatform comparte lógica en Kotlin y deja la interfaz nativa en cada plataforma. Es estable desde noviembre de 2023 y, según JetBrains, su uso pasó del 7% al 18% de los encuestados entre 2024 y 2025. Si además compartes interfaz, Compose Multiplatform es estable en iOS desde la 1.8.
• .NET MAUI tiene sentido si tu casa ya es C# y .NET, y no en otro caso. Vigila el calendario: MAUI 10 salió en noviembre de 2025 y su soporte acaba en mayo de 2027.

El mito del rendimiento y dónde sí importa

El argumento decisivo durante años fue «el multiplataforma va lento». En 2026 eso ya no describe a una app de negocio bien construida. El dato más útil no viene de un vendedor de frameworks sino de Shopify, con media década de React Native en producción: cargas de pantalla por debajo de 500 ms en el percentil 75 y más del 99,9% de sesiones sin fallos. Su conclusión textual: «nativo no significa automáticamente rápido, y React Native no significa automáticamente lento».

JetBrains, parte interesada, publica que Compose Multiplatform en iOS arranca en tiempos comparables a nativo y añade unos 9 MB a la app. Encaja con lo que dice Google desde fuera: Google Docs para iOS corre con Kotlin Multiplatform en producción y su rendimiento es «igual o mejor» que antes.

Dónde el rendimiento y el acceso al sistema sí deciden:

• Gráficos intensivos: juegos, render 3D, mapas con capas propias a 120 Hz.
• Cámara y vídeo en tiempo real: filtros en vivo, escaneo, realidad aumentada.
• Procesamiento en el dispositivo: modelos de visión o audio en local contra Core ML o el NPU de Android.
• Widgets, Apple Watch y Wear OS: memoria muy limitada, donde un runtime completo estorba.
• Integraciones profundas: HealthKit, extensiones del sistema, tareas en segundo plano, teclados.
• Adopción el día uno: Flutter se marcó como objetivo para 2026 dar soporte de día cero a Android 17 y a las próximas versiones de iOS, lo cual dice bastante de que no lo era.

Ninguno de esos seis puntos dice «app de gestión con listados, formularios y login». Si tu app es eso, el rendimiento no es tu criterio.

Dos proyectos nuestros, dos decisiones opuestas

Dormus: nativo en iOS y en Android

Dormus es una app de sueño infantil, B2C, con suscripción. Swift y SwiftUI en iOS, Kotlin y Jetpack Compose en Android, Firebase detrás. Va por 50.000 descargas, más de 22.500 familias registradas y 4,5 estrellas de media.

El criterio fue simple: la app es el negocio. Nada garantiza que el usuario la siga abriendo salvo que la experiencia se sienta impecable a las tres de la mañana, con un padre agotado y el móvil a media batería: fluidez, audio en segundo plano que no se corta, notificaciones que llegan cuando deben. Cada punto de retención vale dinero, y eso cambia el cálculo respecto a una app interna. Se cruza además con la monetización de apps: una app de suscripción vive o muere en el onboarding y el paywall.

Saher Connect: Flutter, una sola base de código

Saher Connect es lo contrario en casi todo: sector agrícola, herramienta de trabajo y una flota conocida de técnicos. Funciona offline para calibrar equipos fitosanitarios, permite consultar más de 200 referencias de boquillas ISO sin cobertura y lleva el cuaderno de campo normativo. Está en Flutter, iOS y Android con una sola base de código.

• La interfaz es formularios, tablas y cálculo. Nada que ganar pintando dos veces la misma pantalla de introducción de datos.
• El usuario no elige la app. Es su herramienta de trabajo: el acabado tiene que ser legible con guantes y sol de frente, no espectacular.
• Lo difícil no era la plataforma. Era el modelo de datos offline, la sincronización y la exactitud de los cálculos. Ese trabajo cuesta lo mismo en Swift, Kotlin o Dart, y compartirlo fue ventaja neta.

Con la misma inversión, hacerlo nativo habría significado la mitad de funcionalidad o el doble de plazo.

La regla que sacamos de los dos

En una frase comprobable: el nativo se paga cuando la calidad percibida se convierte en ingresos; el multiplataforma gana cuando la métrica que importa es funcionalidad por euro. Tres preguntas que puedes responder hoy sin hablar con ningún técnico:

1. ¿Quién paga por usar la app y qué pasa si la desinstala? Si el usuario paga y puede irse cuando quiera, el acabado es inversión de negocio. Si va dentro de un servicio ya contratado, no lo es.
2. ¿Cuánta superficie del sistema toca? Cuenta cámara en directo, procesamiento local, widgets, wearables y segundo plano. Con dos o más, el nativo sale a cuenta.
3. ¿Con cuánta gente la mantendrás en dos años? Si la respuesta es «una persona y media», dos bases de código nativas no se sostienen.

El coste real: el multiplataforma no cuesta la mitad

«Una base de código en vez de dos, luego la mitad de precio» no se sostiene, porque la interfaz no es todo el proyecto. Hay trabajo que no se duplica nunca: descubrimiento, diseño, backend, integraciones, analítica, gestión y publicación. Y hay trabajo que sigue siendo doble aunque tengas una sola base de código: probar en dispositivos reales de las dos plataformas, pasar la revisión de cada tienda, resolver permisos y ajustar notificaciones y pagos en cada sistema. Lo que ahorras es la capa de cliente: una porción del presupuesto, no el presupuesto.

Haz el ejercicio con tus números en vez de creerte un porcentaje: separa qué parte de tu presupuesto es capa de cliente y aplica el ahorro solo ahí. Si es el 40% del total y compartes el 80%, el ahorro sobre la factura ronda un tercio de ese 40%: lejos del 50% del argumentario comercial. Los propios defensores del código compartido lo miden en lógica, no en dinero: JetBrains publica que las empresas con Kotlin Multiplatform comparten en torno al 80% de la lógica y que Philips redujo a la mitad el tiempo de desarrollar funcionalidades. Son cifras de parte, y lógica compartida no es presupuesto ahorrado.

Estos son los rangos que ya publicamos en cuánto cuesta hacer una app: un MVP a medida desde 8.000 €, un proyecto medio en España en torno a 40.000 € y una app compleja entre 80.000 € y 300.000 €. Las tarifas van de 25-40 €/h en junior a 65-110 €/h en senior, con diferencias por zona: 55-120 €/h en Madrid o Barcelona frente a 40-90 €/h en Valencia, Sevilla o Galicia. Para tu caso, tienes la calculadora de presupuesto.

Y hay economía que no cambia con el stack: la cuenta de Apple cuesta 99 € al año y la de Google Play 25 € una sola vez, y las comisiones de tienda son idénticas en Flutter y en Swift: un 15% por debajo de 1 millón de euros anuales y, en la UE tras el DMA, un 10% para pequeñas empresas o un 17% estándar en Apple, más un 3% si usas su sistema de pagos.

El coste a largo plazo: mantenimiento, contratación y dependencia

Aquí se decide de verdad: el desarrollo es un pago y el mantenimiento es una cuota. Cuenta un 15-20% del coste de desarrollo al año solo para mantener la app viva; nuestro mantenimiento evolutivo arranca en 500 €/mes.

Dos bases de código frente a una. Con nativo, cada funcionalidad se implementa dos veces y cada bug se arregla y se prueba dos veces; cada septiembre llegan dos ciclos de sistema operativo, no uno. Con multiplataforma haces ese trabajo una vez, pero cambias el problema por otro: seguir el ritmo del framework. React Native publica versión cada dos meses y cada salto sube los mínimos de Node, Kotlin y SDK de Android. Si tu plan es no tocar la app en tres años, ese riesgo se presupuesta hoy.

Contratar perfiles. No hemos encontrado una fuente pública fiable con recuentos de ofertas por stack en España, así que no te daremos un porcentaje inventado. Lo estructural sí es claro: con nativo necesitas dos especialidades y con Flutter o React Native una sola. En un equipo pequeño eso es enorme, porque una baja no te deja media app huérfana. Lo desarrollamos en cómo elegir el mejor equipo para desarrollar tu app.

Dependencia de un tercero. Con nativo dependes de Apple y de Google, que es inevitable; con multiplataforma añades una más. La desaparición súbita de Flutter o React Native no es realista; el riesgo real es más aburrido: un paquete de terceros abandonado, una migración forzada como la de la arquitectura nueva de React Native, o una librería que tarda meses en soportar la última versión de iOS.

Lo que no cambia con el stack: la seguridad en el desarrollo de aplicaciones móviles y las obligaciones de accesibilidad de la normativa europea se te aplican igual en Swift que en Dart.

Kotlin Multiplatform: la tercera vía

La propuesta es elegante: compartes en Kotlin la lógica, el modelo de datos, la red y la persistencia, y dejas la interfaz nativa en SwiftUI y Jetpack Compose. Acabado de nativo, sin duplicar las reglas de negocio.

No es una promesa de laboratorio: Google ha llevado piezas de Jetpack a multiplataforma —Room, DataStore, ViewModel, Paging— y tiene Google Docs para iOS en producción con KMP. Un respaldo poco habitual: la dueña de Android empujando algo que sirve para hacer mejores apps de iOS.

Tiene sentido si ya tienes equipo Android sólido en Kotlin y quieres iOS sin duplicar la lógica, si la app carga con cálculos, reglas o sincronización offline, o si quieres migrar por partes.

Es complejidad de más si tu app son sobre todo pantallas conectadas a una API, porque montas una cadena de compilación doble para ahorrar poco; si tu equipo no viene de Kotlin; o si es un MVP con plazo corto, donde manda salir, y de eso hablamos en cómo desarrollar un MVP en menos de 3 meses.

Tabla de decisión por tipo de producto

Si aún no tienes claro si necesitas app propia, empieza por aquí antes de discutir stacks.

Lo que no debe decidir esto

• El gusto del equipo. Que a tu desarrollador le encante Dart no es un argumento de negocio, ni que odie JavaScript. Un buen equipo te explica las contrapartidas y acepta lo que salga del producto.
• La moda. Cada dos años hay un framework al que todo el mundo cita en LinkedIn. La lista de frameworks multiplataforma abandonados es larga, y ninguno lo anunció.
• Lo que usa la competencia. No conoces su equipo, su presupuesto ni su deuda técnica. Copiar su stack es heredar sus restricciones sin sus motivos.

Y uno que sí conviene vigilar: quién te lo recomienda. Si el estudio que te asesora solo ofrece un enfoque, su recomendación venía escrita.

Conclusión

La comparativa de desarrollo nativo vs multiplataforma no se resuelve con benchmarks, porque en 2026 ya no separan a los candidatos en las apps que construye la mayoría de las empresas. Se resuelve mirando el producto: quién paga, qué pasa si el usuario se va, cuánto sistema tocas y con cuánta gente vas a mantenerlo. Dormus es nativa y Saher Connect es Flutter porque las respuestas eran distintas, no porque una tecnología gane a la otra.

Si te llevas una idea, que sea esta: la decisión correcta es la que puedes justificar con criterios de negocio y no con preferencias técnicas. Si quieres que la revisemos contigo, cuéntanos qué estás construyendo y te decimos con qué lo haríamos y por qué, incluso si la respuesta es que aún no necesitas una app.