Nativo o multiplataforma: cómo decidimos
Ambos enfoques permiten lanzar buenas apps. La opción adecuada depende del producto, del equipo y de lo que ocurra tras el lanzamiento.
Una de las primeras preguntas técnicas ante una nueva app es si conviene desarrollarla dos veces, una para cada plataforma, o una sola vez con un framework multiplataforma. Hay opiniones firmes en ambos lados. Nosotros no partimos de una preferencia. Empezamos con algunas preguntas sobre el producto y las personas que se ocuparán de él.
Las opciones
El desarrollo nativo implica crear la app de iOS en Swift y la de Android en Kotlin, cada una con las herramientas y frameworks de interfaz propios de su plataforma. Los frameworks multiplataforma como React Native y Flutter permiten que una sola base de código funcione en ambos sistemas. Kotlin Multiplatform se sitúa en un punto intermedio: lógica de negocio compartida, con interfaces que se pueden compartir o escribir de forma nativa en cada lado.
Cuándo compensa el desarrollo nativo
El desarrollo nativo tiene sentido cuando la app depende mucho de la plataforma: uso avanzado de cámara o audio, widgets y apps para relojes, enlaces profundos a funciones del sistema o gráficos exigentes. También ayuda cuando la app debe integrarse de forma totalmente natural en cada plataforma y aprovechar las nuevas funciones del sistema en cuanto se publican. El coste son dos bases de código, lo que suele traducirse en más personas, más tiempo o ambos.
Cuándo compensa el enfoque multiplataforma
El enfoque multiplataforma tiene sentido cuando la mayor parte de la app son pantallas, formularios, listas y llamadas de red, algo habitual en muchas apps de empresa. Una sola base de código implica un único conjunto de funciones para desarrollar y probar, y ambas plataformas se lanzan a la vez. Si su equipo ya escribe TypeScript para la web, React Native le permite reutilizar esas habilidades y parte de ese código.
Fíjese en el equipo, no solo en la app
La mejor tecnología es la que su equipo puede mantener tras el lanzamiento. Si la app pasará a manos de un equipo interno, constrúyala con lo que ya dominen o puedan contratar con facilidad. Un framework que nadie en el equipo comprende se convierte en un riesgo en cuanto surge un problema que la documentación no cubre.
Cuente con el trabajo nativo de todos modos
Multiplataforma rara vez significa prescindir por completo del código nativo. Las notificaciones push, las compras dentro de la app, las tareas en segundo plano y ciertas funciones del dispositivo siguen requiriendo configuración nativa, y cada tienda tiene su propio proceso de publicación. Reserve presupuesto para algo de trabajo nativo en cualquier proyecto multiplataforma y asegúrese de que alguien en el equipo sea capaz de asumirlo.
Mantenga la lógica de negocio portable
Elija el camino que elija, mantenga las reglas del producto —como precios, permisos y cálculos— separadas de las pantallas y en el servidor cuando sea oportuno. Esto facilita las pruebas de la app, mantiene la coherencia entre plataformas y hace que un cambio de enfoque futuro resulte mucho menos costoso.
En resumen
Elija nativo cuando la app dependa de la plataforma, y multiplataforma cuando dependa principalmente de pantallas y datos. En cualquier caso, elija una opción que el equipo pueda mantener durante años. La elección importa menos que construirla bien.