Responda 12 preguntas sobre su producto, su equipo y sus restricciones. Obtendrá una recomendación con sus motivos, una comparación de coste y primera versión frente a nativo, y los puntos a vigilar.
Elegir mi stack
La herramienta muestra qué stack encaja mejor con sus respuestas y qué inclinó la balanza. El coste y el plazo son relativos a nativo y se basan en nuestros artículos publicados; sirven para planificar, no son un presupuesto. Desarrollamos en los cinco stacks, así que el resultado sigue a sus respuestas, no a nuestra preferencia.
Cada respuesta suma puntos a algunos stacks y resta a otros, de −2 a +2. Los puntos se multiplican por el peso de la pregunta (de 1 a 3) y se suman. El total se escala a una puntuación de encaje de 0 a 100. Las respuestas «No lo sé» no suman nada y reducen la confianza; quedan fuera de la escala, para no arrastrar las puntuaciones hacia el centro.
Algunas respuestas fijan límites estrictos. Si la app necesita Bluetooth en segundo plano, datos de salud, widgets, NFC, CarPlay o una cámara personalizada, la PWA queda limitada a 20: una app web no accede a estas funciones como lo hace una app nativa. Los límites más suaves restan algunos puntos y se muestran como puntos a vigilar.
La confianza es alta cuando el primero aventaja en 12 puntos o más y usted estaba seguro de casi todo. Cuando los dos primeros están a menos de 6 puntos, la herramienta lo indica: tiene dos opciones cercanas y la elección depende de su equipo y su hoja de ruta.
| Pregunta | Peso |
|---|---|
| ¿Qué plataformas necesita en el lanzamiento? | 3 |
| ¿Qué tipo de producto es? | 2 |
| ¿Cómo debe sentirse la interfaz? | 2 |
| ¿Qué funciones del dispositivo necesita la app? | 3 |
| ¿Cómo debe funcionar la app sin conexión? | 1 |
| Requisitos de seguridad y cumplimiento normativo | 1 |
| ¿Qué conocimientos tiene ya su equipo? | 3 |
| ¿Qué tiene ya? | 2 |
| ¿Cómo obtendrán la app los usuarios? | 2 |
| ¿Cuándo necesita la primera versión? | 2 |
| ¿Qué pesa más en el presupuesto? | 2 |
| ¿Cuánto tiempo debe vivir la app sin rehacerse? | 1 |
| Stack | Cuándo | Efecto |
|---|---|---|
| PWA | La app necesita Bluetooth en segundo plano, AR o cámara personalizada, datos de salud, widgets o apps de reloj, NFC o CarPlay | limitado a 20 · No apta: una PWA no accede a esta función del dispositivo como lo hace una app nativa. |
| PWA | La app debe estar en App Store y Google Play | −10 puntos · Para publicarse en las tiendas necesita un contenedor (Capacitor o Trusted Web Activity). |
| PWA | Offline-first con sincronización | −8 puntos · En iOS, el almacenamiento sin conexión de las apps web es limitado y el sistema puede borrarlo. |
| Nativo iOS + Android | Primera versión en menos de 3 meses y el menor coste | −10 puntos · Dos bases de código rara vez encajan en un encargo de 3 meses y coste mínimo. |
| Kotlin Multiplatform | Sin conocimientos de Kotlin en el equipo y sin proveedor | −8 puntos · Requiere conocimientos de Kotlin en el equipo. |
| Kotlin Multiplatform | Primera versión en menos de 3 meses | −6 puntos · Ecosistema más joven: prevea tiempo adicional. |
| Flutter | Se necesita web y el producto es de contenido o medios | −8 puntos · Flutter en la web rinde peor para contenido que depende de buscadores. |
| React Native | Producto con gráficos intensivos o tipo juego | −8 puntos · Para interfaces con mucho renderizado encajan mejor Flutter o nativo. |
Flutter / Dart: una base de código para iOS y Android, además de web y escritorio
El kit de UI de Google en Dart. Dibuja cada píxel por sí mismo, de modo que un diseño de marca propio y la animación se ven igual en iOS y Android. Un equipo, una base de código y versiones web y de escritorio a partir del mismo código. Los inconvenientes: una cantera de contratación menor que la de JavaScript, y las novedades de la plataforma llegan mediante plugins, a veces con retraso.
React Native (incl. Expo): JavaScript / TypeScript, componentes de UI nativos
El framework de Meta en JavaScript o TypeScript, con Expo como herramienta por defecto y la nueva arquitectura activada de serie. Renderiza componentes reales de la plataforma, por lo que las pantallas estándar resultan naturales en cada sistema. Destaca cuando su equipo ya trabaja con React o cuando la app comparte lógica con un producto web. Su punto débil son los gráficos personalizados intensivos.
Swift / SwiftUI para iOS y Kotlin / Compose para Android: dos bases de código
Dos apps, cada una en el lenguaje y el kit de UI propios de su plataforma. Obtiene cada novedad del sistema desde el primer día, el mejor acceso al hardware, como Bluetooth, datos de salud, widgets y la cámara, y la experiencia más familiar. El precio son dos bases de código: aproximadamente 1,4–1,8 veces el coste de desarrollo de una app multiplataforma y dos equipos que coordinar.
Kotlin Multiplatform: lógica de negocio compartida, UI nativa o Compose Multiplatform
Comparte en Kotlin la lógica de negocio, la red y los datos, mientras cada plataforma mantiene una UI nativa o usa Compose Multiplatform para pantallas compartidas. Encaja con equipos que ya tienen apps nativas o ingenieros Android y quieren menos duplicación sin reescribirlo todo. El ecosistema es más joven, así que prevea tiempo adicional para herramientas e integración con iOS.
Progressive Web App, opcionalmente empaquetada con Capacitor o TWA para las tiendas
Una app web que se instala en la pantalla de inicio y funciona sin conexión dentro de los límites del navegador. Es la vía más barata y rápida cuando basta con un enlace o un código QR y la app consiste sobre todo en contenido y formularios. En iOS, las notificaciones push, el trabajo en segundo plano, el almacenamiento y el acceso al dispositivo están más limitados que en una app nativa, y publicar en las tiendas requiere un contenedor.
| Fuente | Qué tomamos de ella |
|---|---|
| Desarrollo nativo frente a multiplataforma en 2026 (en inglés) | El multiplataforma cuesta el 55–70% del nativo; la primera versión llega un 30–40% antes; el nativo requiere 8–14 semanas |
| App web frente a nativa frente a PWA en 2026 (en inglés) | Una PWA requiere 5–8 semanas y 40–100 mil $ frente a 80–250 mil $ del nativo; límites de las PWA en iOS |
| Coste de mantenimiento de una app móvil en 2026 (en inglés) | El mantenimiento supone el 15–25% del coste de desarrollo al año y el 30–50% el primer año; el multiplataforma es un 20–35% más barato de mantener |
| React Native frente a Flutter en 2026 (en inglés) | Dónde encaja cada framework y qué papel tiene Kotlin Multiplatform |
Los valores de Kotlin Multiplatform y PWA son estimaciones nuestras entre las cifras publicadas y están pendientes de revisión por nuestro responsable de desarrollo móvil.
Depende de su equipo y de la interfaz. React Native encaja con equipos que ya trabajan con React o comparten código con una app web; Flutter encaja con un diseño de marca propio y animación. La herramienta sopesa ambos según sus respuestas, y nuestra comparativa React Native frente a Flutter profundiza más.
Cuando la app depende de funciones de la plataforma como Bluetooth en segundo plano, datos de salud, widgets, CarPlay o una cámara personalizada, cuando debe sentirse exactamente como el sistema, o cuando la seguridad estricta y una vida útil larga importan más que el coste de desarrollo. También es la opción natural para una sola plataforma.
Kotlin Multiplatform comparte la lógica de negocio entre iOS y Android, mientras cada uno mantiene una interfaz nativa. Encaja con equipos que tienen apps nativas o ingenieros Android y quieren menos código duplicado sin reescribirlo todo. El ecosistema es más joven, así que prevea tiempo adicional.
A menudo sí, para contenido, formularios y herramientas internas que se abren desde un enlace. En iOS, las apps web tienen límites más estrictos en notificaciones push, trabajo en segundo plano, almacenamiento y acceso al dispositivo, y en la UE el soporte de iOS para apps web en la pantalla de inicio ha cambiado con la Ley de Mercados Digitales. Compruebe el comportamiento actual antes de decidir.
Flutter y React Native suelen costar el 55–70% de dos apps nativas, es decir, un ahorro del 30–45%. Cuanto más código específico de plataforma necesite la app, menor es el ahorro. La herramienta ajusta la cifra a sus respuestas y muestra el rango.
Según nuestros proyectos: nativo requiere 8–14 semanas, Flutter y React Native son un 30–40% más rápidos, unas 5–9 semanas, y una PWA requiere 5–8 semanas. Kotlin Multiplatform queda en medio. El alcance influye en estas cifras más que el stack.
Cada respuesta suma o resta puntos a cada stack, ponderados según la importancia de la pregunta. Los límites estrictos acotan un stack que no puede cumplir un requisito. La sección «Cómo decide la herramienta» de arriba recoge cada pregunta, peso y límite.
Sí. Desarrollamos en Flutter, React Native, nativo con Swift y Kotlin, Kotlin Multiplatform y como apps web. Por eso la herramienta muestra su razonamiento en lugar de imponer una opción.
Una base de código para iOS, Android y la web.
Apps móviles para equipos que ya trabajan con React.
Apps nativas en Swift y SwiftUI.
Apps nativas en Kotlin y Jetpack Compose.
Del primer prototipo a la publicación en tiendas y el soporte.