React Native o nativo: cómo decidirlo de verdad
Sergio Jimenez21 de octubre de 20266 min de lectura
La pregunta suele plantearse como si fuera ideológica. No lo es. React Native y el desarrollo nativo son buenas respuestas a situaciones distintas, y la correcta sale de cuatro hechos sobre tu producto: cuántas plataformas lanzas, cuánto del dispositivo tocas, quién lo mantiene y cuánto tiempo tiene que vivir.
Así se decide sin discusión de religión.
La respuesta corta
| Tu situación | Elige |
|---|---|
| Ambas plataformas, un equipo pequeño, producto convencional | React Native |
| Una sola plataforma, y eso no va a cambiar | Nativo |
| Cámara intensiva, audio, Bluetooth o machine learning en el dispositivo | Nativo, o React Native con módulos nativos |
| Un juego, o cualquier cosa que dibuje sus propios frames | Ninguno. Usa un motor de juego |
| Ya tienes un equipo web de React | React Native |
| Tu diferenciador es una función de plataforma desde el día uno | Nativo |
Qué te da React Native de verdad
Un solo código que produce apps iOS y Android reales. No es una página web dentro de una cáscara: los botones son botones de la plataforma, las listas son listas de la plataforma, y el resultado es indistinguible de nativo para la gran mayoría de productos.
El ahorro no es del 50 por ciento, que es el número que la gente espera. En la práctica compartes entre 85 y 95 por ciento del código de producto y escribes el resto dos veces, así que el ahorro realista frente a dos equipos nativos es de 30 a 40 por ciento en el primer desarrollo, y bastante más en los años siguientes, porque cada funcionalidad posterior al lanzamiento también se escribe una sola vez.
El segundo ahorro es organizativo y más grande de lo que parece. Un solo código significa un solo backlog, un solo proceso de release y un solo conjunto de bugs. Dos equipos nativos se desincronizan: un arreglo entra en Android en marzo y en iOS en mayo, y tu equipo de soporte empieza a preguntar qué teléfono tiene el cliente antes de poder responder nada.
Qué te da nativo de verdad
Acceso directo, el día del lanzamiento. Cuando Apple presenta una API nueva en la WWDC, nativo la tiene de inmediato y React Native la tiene cuando alguien escribe el puente. Si tu producto depende de llegar primero a una capacidad de plataforma, esa diferencia es todo el argumento y nada más importa.
Nativo también gana donde el trabajo está cerca del metal. Procesamiento sostenido de cámara, audio de baja latencia, periféricos Bluetooth, ubicación en segundo plano durante periodos largos, modelos en el dispositivo. React Native puede llegar a todo eso mediante módulos nativos, pero a esas alturas ya estás escribiendo Swift y Kotlin, y la pregunta pasa a ser qué porcentaje de la app es ese trabajo. Si es la mayor parte, ve nativo.
El argumento del rendimiento, honestamente
Para un producto normal, el rendimiento de React Native no es un problema, y quien diga lo contrario suele estar recordando 2018. La nueva arquitectura eliminó el puente serializado que causaba las quejas antiguas.
Dónde sí lo vas a notar: listas muy largas con celdas complejas, animaciones que deben sostener 60 cuadros por segundo mientras ocurre trabajo pesado, y el tiempo de arranque de la app, donde nativo mantiene una ventaja real. Si tu producto es un feed que la gente recorre cuarenta minutos al día, mide antes de comprometerte. Si es un flujo de reserva, un marketplace, un dashboard o una herramienta, ese no es tu cuello de botella. Tu cuello de botella es la latencia de red, y es la misma en ambos.
Los costos que se olvidan
React Native tiene un impuesto de actualización. Salen versiones nuevas con regularidad y arrastran al ecosistema. Un equipo que se salta actualizaciones durante dieciocho meses pasará semanas poniéndose al día, normalmente en el peor momento posible. Presupuesta unos días cada trimestre y se mantiene aburrido.
También tiene una superficie de dependencias. Buena parte de lo que necesitas viene de paquetes de la comunidad, de calidad variable. Elegir bien importa más que en desarrollo nativo, donde llega más cosa en la caja.
Nativo tiene su propio costo olvidado, y es mayor: estás contratando y reteniendo dos perfiles especializados de forma permanente. No para el desarrollo. Para siempre.
Y Flutter
Flutter es una alternativa genuina y buena en lo suyo. Dibuja sus propios componentes en vez de usar los de la plataforma, lo que da resultados idénticos píxel a píxel entre plataformas y una ligera sensación extraña en iOS si te importan las convenciones del sistema. El factor decisivo suele ser tu equipo: si tus ingenieros escriben React, React Native no les cuesta nada aprender, mientras que Dart es un lenguaje nuevo y una bolsa de talento aparte. Nosotros construimos en React Native por esa razón, no porque Flutter sea malo.
Cómo lo decidimos
Vamos por defecto a React Native y nos movemos a nativo cuando algo concreto lo obliga. En la práctica son pocos casos: el producto es un juego, el diferenciador es una API de plataforma recién salida, o más de la mitad del trabajo es procesamiento sostenido a nivel de dispositivo.
El híbrido también está infravalorado. Lanza React Native y escribe la única parte difícil como módulo nativo detrás de una interfaz limpia. Obtienes un solo código para el 90 por ciento que es trabajo de producto corriente y rendimiento nativo completo exactamente donde hace falta. La mayoría de apps que lanzamos se ven así, y es lo que nuestros contratos de Studio asumen por defecto.
Preguntas frecuentes
¿React Native sirve para una app en producción?
Sí, y ya mueve productos con decenas de millones de usuarios. Los límites son estrechos y concretos: juegos, procesamiento sostenido a nivel de dispositivo y acceso el mismo día a APIs de plataforma recién salidas. Para marketplaces, reservas, productos sociales, apps fintech y herramientas internas es una elección directa.
¿React Native es más barato que nativo?
Normalmente entre 30 y 40 por ciento más barato en un primer desarrollo para ambas plataformas, y la diferencia crece después del lanzamiento porque cada funcionalidad siguiente se escribe una vez en vez de dos. No es más barato si solo vas a lanzar una plataforma.
¿Se puede mezclar React Native con código nativo?
Sí, y a menudo es la mejor respuesta. Escribes el producto en React Native e implementas la pieza exigente, un pipeline de cámara o una integración Bluetooth, como módulo nativo en Swift o Kotlin detrás de una interfaz limpia. Mantienes un solo código para el trabajo corriente y rendimiento nativo donde importa.
¿Apple rechaza apps hechas con React Native?
No. La revisión de la App Store no mira con qué construiste la app, solo cómo se comporta. Los rechazos vienen de declaraciones de privacidad faltantes, flujos de inicio de sesión rotos, contenido pobre o reglas de pagos, y eso aplica igual a las apps nativas.
¿React Native o Flutter?
Ambos son capaces. Flutter renderiza sus propios componentes, lo que da visuales idénticas entre plataformas y una sensación algo menos nativa. El factor decisivo suele ser tu equipo actual: un ingeniero de React pasa a React Native de inmediato, mientras que Flutter implica Dart y otra bolsa de contratación.
¿Qué pasa cuando una versión nueva de iOS rompe mi app?
Lo mismo que con nativo: actualizas y publicas. La diferencia es que puedes esperar días a que un paquete de la comunidad se ponga al día. Es un costo real y se gestiona manteniendo las dependencias al día, no dejándolas pudrirse un año.
Por dónde empezar
Escribe las tres cosas técnicamente más difíciles que tu app debe hacer. Si ninguna toca la cámara, el pipeline de audio, el stack de Bluetooth o una API de plataforma salida este año, la decisión ya está tomada y deberías dejar de debatirla.
Si alguna sí lo hace, cuéntanos cuál y te decimos honestamente si necesita nativo, y cuánto cuesta en cada caso.
