Vas a empezar una app nueva: recorré el framework de decisión entre nativo, React Native, Flutter y KMM
La mejor respuesta nunca arranca con un framework favorito: arranca con los cuatro ejes que realmente deciden el tradeoff, y después recorre un caso real a través de ellos.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Vas a empezar una app nueva: recorré el framework de decisión entre nativo, React Native, Flutter y KMM
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.Esta es menos una pregunta técnica que una pregunta de criterio: ¿puede el candidato razonar sobre un tradeoff de negocio real en lugar de recitar su stack favorito? Las mejores respuestas no nombran un ganador de entrada — nombran los ejes que deciden la cuestión, y recién después recorren un caso concreto a través de ellos.
#Los ejes que realmente deciden
Cuatro cosas importan mucho más que qué framework está de moda en este momento. La profundidad de integración con el sistema operativo requerida desde el día uno — Bluetooth en background, ARKit/ARCore, CallKit, widgets de pantalla de inicio, cualquier cosa que dependa fuerte de las APIs más nuevas del SO — empuja hacia nativo, o como mínimo hacia un framework multiplataforma con una vía de escape a módulos nativos madura. La habilidad existente del equipo no es un factor blando, muchas veces es el mayor generador de costo: reentrenar a un equipo fuerte de React en el modelo de widgets de Flutter, o a un equipo fuerte de nativo Android/iOS en JavaScript, tiene un costo real de varios meses que se nota más en plazos incumplidos que en la calidad final de la app. Cuánto de la app es UI custom y de marca versus cuánto debería simplemente verse y sentirse como la plataforma importa porque Flutter y React Native resuelven eso de forma distinta — Flutter te da renderizado pixel-idéntico en todos lados a costa de reimplementar las convenciones de la plataforma, RN se apoya en componentes nativos reales así que el look-and-feel de la plataforma sale casi gratis. La realidad del mantenimiento a largo plazo — ¿van a seguir manteniéndose ambas apps nativas de todos modos?, ¿el dolor real del equipo es lógica de negocio duplicada y no UI duplicada? — es exactamente el caso para el que está construido KMM y no las otras tres opciones.
#Una comparación que conviene tener lista
| Eje | Nativo | React Native | Flutter | KMM |
|---|---|---|---|---|
| Consistencia de UI entre plataformas | Baja (a propósito) | Media (componentes nativos reales) | Alta (Flutter lo dibuja todo) | Baja (UI nativa en cada lado) |
| Reusa habilidad existente de web/JS | No | Sí | No (Dart) | No (Kotlin, y sobre todo para lógica) |
| Acceso a APIs nuevas del SO desde el día uno | Inmediato | Demorado / necesita módulo nativo | Demorado / necesita un plugin | Inmediato (la UI se mantiene nativa) |
| Qué se comparte realmente | Nada | UI + lógica de negocio | UI + lógica de negocio | Sólo lógica de negocio |
| Dos código base nativos para mantener | Sí (por definición) | No | No | Sí, a propósito |
#Cómo enmarcarlo para que aterrice bien en la entrevista
Una respuesta senior resiste la tentación de elegir un favorito personal y en cambio nombra el costo real que se está optimizando. React Native y Flutter intercambian algo de sensación nativa por un código base compartido e iteración más rápida — RN apoyándose en vistas nativas reales debajo de una capa de JS, Flutter siendo dueño del renderizado por completo. KMM ni siquiera intenta unificar la UI; acepta dos UIs y dos equipos, y sólo elimina la duplicación que nunca fue específica de plataforma para empezar. Nativo no es "la opción segura por defecto", es la decisión correcta específicamente cuando la propuesta de valor de la app depende de ser el primero en usar una capacidad de la plataforma, o cuando la organización no tiene ningún apetito por el riesgo de migrar a un código base compartido.