En qué consiste realmente la elección
Una aplicación nativa se escribe en el lenguaje y con las herramientas propias de cada plataforma: Swift para iOS, Kotlin para Android. Dos plataformas significan dos bases de código, normalmente desarrolladas por dos grupos de especialistas. React Native permite a un equipo escribir una sola aplicación en JavaScript o TypeScript con React; su propia descripción es «escrito en JavaScript, renderizado con código nativo», con componentes que corresponden a las piezas nativas de cada plataforma [1]. Las pantallas son pantallas nativas de verdad, no una página web dentro de un envoltorio.
No es una opción minoritaria. La web de React Native incluye entre las aplicaciones desarrolladas con él algunas de Meta, Microsoft (como Office, Outlook y Teams), Shopify y Discord [1]. Flutter es la otra opción multiplataforma habitual, con compromisos parecidos y su propia forma de dibujar la interfaz; casi todo lo que sigue también se le aplica.
Cuándo React Native es la mejor opción
- Aplicaciones de empresa hechas de formularios, listados, paneles, reservas, pagos, mensajes y notificaciones. Es decir, la mayoría.
- Productos que también tienen una aplicación web. Los conocimientos de React, y parte del código como los modelos de datos y la validación, se comparten con la web.
- Equipos que quieren mantener una sola base de código, un solo conjunto de pruebas, y que las funciones lleguen a las dos plataformas a la vez.
- Proyectos en los que llegar a las dos tiendas con un solo presupuesto importa más que exprimir el último detalle de acabado de cada plataforma.
Cuando una aplicación en React Native necesita algo que el framework no ofrece, como un dispositivo Bluetooth concreto o un widget propio de una plataforma, se escribe un módulo nativo para esa pieza en Swift o Kotlin. El resto de la aplicación sigue siendo común.
Normalmente empezamos los proyectos en React Native con Expo, un conjunto de herramientas de código abierto en torno a React Native que se ocupa de las compilaciones, los envíos a las tiendas y las actualizaciones, y añadimos módulos nativos solo donde una función los necesita. Así el proyecto se mantiene cerca del camino estándar, lo que facilita las actualizaciones y que otro equipo pueda hacerse cargo del código.
Cuándo lo nativo justifica el trabajo extra
- Gráficos exigentes, procesamiento de cámara o de audio en tiempo real, realidad aumentada y juegos, donde cuenta cada fotograma.
- Integración profunda con la plataforma: widgets, aplicaciones para el reloj, pantallas del coche, procesos en segundo plano con límites estrictos, o funciones nuevas de la plataforma el mismo día en que salen.
- Aplicaciones que solo van a necesitar una plataforma, como una aplicación interna para iPad para un equipo que solo usa iPad.
- Organizaciones que ya tienen buenos equipos de iOS y Android y el presupuesto para mantener ocupados a ambos.
Comparación directa
| React Native | Nativo (Swift y Kotlin) | |
|---|---|---|
| Bases de código | Una, con pequeños módulos nativos donde haga falta | Dos, una por plataforma |
| Aspecto y sensación | Componentes nativos; muy cerca de lo nativo en aplicaciones de empresa | Exactamente nativo, con todos los detalles de la plataforma disponibles |
| Rendimiento | Bueno para aplicaciones típicas; los gráficos exigentes necesitan cuidado o módulos nativos | El mejor posible, con acceso directo a todas las API de la plataforma |
| Funciones nuevas de la plataforma | Normalmente disponibles con retraso, o mediante un módulo nativo | Disponibles el día de su lanzamiento |
| Compartido con una aplicación web | Conocimientos, y parte del código como la validación y los tipos de datos | Poco o nada |
| Equipo | Ingenieros de React y TypeScript, más algo de conocimiento nativo | Especialistas en iOS y en Android |
| Mantenimiento | Un solo conjunto de funciones y pruebas; actualizaciones del framework que hay que planificar | Dos conjuntos de funciones y pruebas que mantener acompasados |
Lo que exigen las tiendas de aplicaciones en ambos casos
A las tiendas no les importa cómo está hecha una aplicación, pero sí fijan reglas que condicionan cualquier proyecto móvil y su calendario.
- La revisión lleva tiempo. Apple indica que, de media, el 90% de los envíos se revisan en menos de 24 horas [2], pero un rechazo supone una corrección y otra revisión, así que planifique los lanzamientos con margen.
- Las directrices de Apple dicen que una aplicación debe ofrecer funciones, contenido e interfaz que la eleven por encima de una web reempaquetada [3]. Una página web dentro de una carcasa de aplicación tiene muchas probabilidades de ser rechazada.
- La directriz 2.5.2 de Apple dice que las aplicaciones no pueden descargar ni ejecutar código que introduzca o cambie funciones o funcionalidades [3]. Las aplicaciones en React Native pueden enviar algunas actualizaciones de forma remota, pero las funciones nuevas van en una versión revisada.
- Google Play exige que las aplicaciones nuevas y las actualizaciones se dirijan a una versión reciente de Android: a partir del 31 de agosto de 2026, Android 16, nivel de API 36, para la mayoría de las aplicaciones [4]. El requisito sube a medida que avanza Android, así que toda aplicación necesita actualizaciones periódicas para poder seguir publicando novedades.
Esto último es un coste de funcionamiento de cualquier aplicación móvil, nativa o no. Las actualizaciones de la plataforma, los nuevos tamaños de dispositivo y los cambios en las políticas de las tiendas llegan cada año, así que presupueste el mantenimiento desde el principio.
Cuándo no necesita ninguna de las dos
Algunas aplicaciones no necesitan estar en una tienda. Una aplicación web adaptable funciona en cualquier teléfono, se puede añadir a la pantalla de inicio y se actualiza en cuanto se despliega, sin revisión. Si sus usuarios entran de vez en cuando, le encuentran por buscadores o enlaces, y no necesitan uso sin conexión, ubicación en segundo plano ni notificaciones avanzadas, empiece por la web.
- Encajan bien en la web: portales de clientes, reservas y pedidos, paneles y herramientas internas que se usan tanto en la oficina como fuera de ella.
- Encajan bien en una aplicación de tienda: productos de uso diario, trabajo de campo sin conexión, funciones de cámara y sensores, notificaciones push fiables y todo lo que los usuarios esperan encontrar en una tienda.
- Un camino habitual: lanzar la aplicación web, aprender qué usa la gente en el teléfono, y después desarrollar la aplicación móvil para esos recorridos.
Empezar por la web no es trabajo perdido. El backend, la parte de administración, el modelo de datos y buena parte del diseño pasan directamente a la aplicación móvil, así que el segundo paso cuesta menos de lo que habría costado empezar por ahí.
La mitad de una aplicación móvil que nadie ve
Se construyan como se construyan las pantallas, buena parte de un proyecto móvil es el mismo trabajo por debajo, y a menudo es la parte más grande.
- El backend: el servidor, la base de datos y las API con las que habla la aplicación, con inicio de sesión, permisos y una parte de administración para el personal. Nativo o React Native, esto es común.
- Sin conexión y sincronización: si la gente usa la aplicación donde hay poca cobertura, tiene que guardar el trabajo en el teléfono y conciliarlo después sin perder ni duplicar nada. Es tanto trabajo de diseño como de código.
- Notificaciones push: certificados y claves de Apple y Google, un servicio que las envíe y ajustes para que los usuarios controlen lo que reciben.
- Pruebas en dispositivos reales: distintos tamaños de pantalla, versiones antiguas del sistema operativo, redes lentas y sesiones interrumpidas. Las pruebas automatizadas cubren la lógica; las personas con teléfonos reales cubren el resto.
- Gestión de versiones: fichas en las tiendas, capturas de pantalla, declaraciones de privacidad, despliegues escalonados, informes de fallos y una forma de volver atrás.
Un presupuesto que pone precio a las pantallas pero no a esta mitad se moverá. Pida que la detallen.
Dos proyectos móviles, con el precio de nuestra tarifa
Los ejemplos prácticos de abajo muestran la horquilla de nuestra tarifa de hoy, con las horas por perfil y el calendario de pagos. El primero es una aplicación para iPhone sola. El segundo cubre iOS y Android con una aplicación web y una parte de administración. Si elige dos aplicaciones nativas separadas en lugar de un código común, casi todo el trabajo móvil se hace dos veces; abra cualquiera de los ejemplos en el estimador y podemos calcular con usted el precio de esa variante.
Ejemplo práctico, con precio de hoy
Una aplicación para iPhone
Dieciséis pantallas en iOS con inicio de sesión, pagos dentro de la aplicación, notificaciones push y analítica, con un diseño a medida y datos personales.
- Desarrollo
- ≈ 57.200 US$ a 87.400 US$, delivered within 26 weeksCAD 81,400 to 124,400
Los precios en su moneda son estimaciones con el tipo de cambio de hoy del Banco de Canadá. Toda la facturación se emite en CAD o USD.
Esfuerzo estimado por perfil
- Développement
- 318 to 486 h
- Concepteur de produits
- 57 to 87 h
- Ingénieur assurance qualité
- 39 to 59 h
- Développeur dorsal principal
- 38 to 59 h
- Concepteur de produits principal
- 38 to 58 h
- Gestionnaire de projet
- 37 to 57 h
- Développeur dorsal
- 35 to 54 h
- Développeur frontal
- 32 to 49 h
- Développeur mobile
- 25 to 39 h
- Ingénieur principal
- 24 to 36 h
- Architecte logiciel
- 21 to 32 h
- Développeur mobile principal
- 20 to 30 h
- Développeur frontal principal
- 19 to 29 h
- Développeur dorsal junior
- 18 to 27 h
- Développeur frontal junior
- 13 to 19 h
- Développeur mobile junior
- 11 to 17 h
- Rédacteur technique
- 7 to 10 h
- Ingénieur DevOps
- 6 to 10 h
Cómo se paga
- Anticipo 20%
- CAD 16,280 to 24,880
- Découverte 10%
- CAD 8,140 to 12,440
- Maquettes approuvées 10%
- CAD 8,140 to 12,440
- Première version sur appareils 30%
- CAD 24,420 to 37,320
- Soumission aux boutiques 10%
- CAD 8,140 to 12,440
- Mise en ligne 10%
- CAD 8,140 to 12,440
- Holdback, 30 days after launch (10%)
- CAD 8,140 to 12,440
Ejemplo práctico, con precio de hoy
Aplicaciones para iOS y Android con una aplicación web
Veintidós pantallas entre iOS, Android y la web, con inicio de sesión, pagos, una parte de administración para el personal, notificaciones y analítica, y un plan de soporte después de la puesta en marcha.
- Desarrollo
- ≈ 97.600 US$ a 149.000 US$, delivered within 25 weeksCAD 139,000 to 212,600
Los precios en su moneda son estimaciones con el tipo de cambio de hoy del Banco de Canadá. Toda la facturación se emite en CAD o USD.
Esfuerzo estimado por perfil
- Développement
- 528 to 807 h
- Concepteur de produits
- 107 to 164 h
- Concepteur de produits principal
- 71 to 109 h
- Gestionnaire de projet
- 68 to 104 h
- Développeur frontal
- 64 to 98 h
- Développeur dorsal principal
- 63 to 96 h
- Ingénieur assurance qualité
- 61 to 93 h
- Développeur dorsal
- 57 to 88 h
- Ingénieur principal
- 40 to 61 h
- Développeur frontal principal
- 38 to 59 h
- Développeur mobile
- 34 to 52 h
- Architecte logiciel
- 34 to 52 h
- Développeur dorsal junior
- 29 to 44 h
- Développeur mobile principal
- 27 to 41 h
- Développeur frontal junior
- 26 to 39 h
- Développeur mobile junior
- 15 to 23 h
- Ingénieur DevOps
- 13 to 20 h
- Rédacteur technique
- 11 to 16 h
Cómo se paga
- Anticipo 20%
- CAD 27,800 to 42,520
- Découverte 9.2%
- CAD 12,788.00 to 19,559.20
- Maquettes approuvées 9.2%
- CAD 12,788.00 to 19,559.20
- Fonctions principales 7.6%
- CAD 10,564.00 to 16,157.60
- Développement complet 5%
- CAD 6,950 to 10,630
- Première version sur appareils 20.1%
- CAD 27,939.00 to 42,732.60
- Tests et corrections 2.5%
- CAD 3,475 to 5,315
- Soumission aux boutiques 6.7%
- CAD 9,313.00 to 14,244.20
- Mise en ligne 9.7%
- CAD 13,483.00 to 20,622.20
- Holdback, 30 days after launch (10%)
- CAD 13,900 to 21,260
Después de la puesta en marcha, en ambos casos
Una aplicación móvil nunca está terminada como puede estarlo una web. Cada año trae versiones nuevas del sistema operativo, dispositivos nuevos y reglas nuevas en las tiendas, y los usuarios esperan que la aplicación se mantenga al día. Planifique un ritmo de versiones, mensual o trimestral, que agrupe pequeñas mejoras con las actualizaciones que exigen las plataformas, y mantenga en marcha los informes de fallos y la analítica para saber qué problemas importan. Con React Native, añada a esa lista las actualizaciones del framework; con aplicaciones nativas, hágalo todo dos veces.
Cómo decidir
- 01
Enumere las funciones que tocan el dispositivo
Cámara, ubicación, Bluetooth, trabajo en segundo plano, widgets, datos de salud. Cada una es una pregunta sobre el soporte nativo.
- 02
Pregúntese si alguna tiene que ser la mejor de su clase
Si una función es el producto, como un efecto de cámara en tiempo real, puede justificar código nativo para esa función o para toda la aplicación.
- 03
Compruebe sus plataformas
Si sus usuarios están en iOS y en Android, lo normal es un código común. Si todos están en una sola, lo razonable es nativo para esa.
- 04
Piense en la web
Si también necesita una aplicación web, React Native comparte con ella conocimientos y parte del código.
- 05
Planifique los años posteriores a la puesta en marcha
¿Quién la mantendrá, y podrá contratar para ello? Es más fácil encontrar ingenieros de React y TypeScript que dos especialistas nativos.