Kotlin Multiplatform Mobile vs React Native, Xamarin y Flutter

En la primera parte de esta serie de artículos sobre Kotlin Multiplatform Mobile (KMM en adelante), vimos cómo se integra tanto en un proyecto Android, como en un proyecto iOS y de cuáles son sus ventajas e inconvenientes.

Sin embargo, y como es natural, introducir un nuevo método de programación con el objetivo de reducir los tiempos de desarrollo y los costes, haciendo uso de la programación cross-platform, surgen los primeros porqués de utilizar KMM sobre otras tecnologías con más experiencia y más adeptos dentro de la comunidad de desarrolladores mobile.

Comparar las diferentes tecnologías y entender qué beneficios tiene KMM sobre las demás tecnologías, es posible gracias a los siguientes criterios de desarrollo:

Capa de Interfaz de Usuario

A pesar de que KMM no tiene como objetivo compartir ningún tipo de lógica relacionada con la interfaz de usuario, ahí es donde radica la ventaja de KMM sobre las demás tecnologías, ya que no tiene que lidiar en ofrecer controles sobre la interfaz de usuario. Simplemente delega la responsabilidad de la interfaz de usuario a cada una de las plataformas asegurando un rendimiento óptimo y una magnífica integración con los diferentes componentes nativos.

Flutter, React Native y Xamarin intentan unificar en un único desarrollo todo el código de la aplicación, incluyendo la interfaz de usuario, pero todos y cada uno de ellos tienen problemas:

• En el caso de React Native, el rendimiento de JavaScript sigue siendo un problema, además de entorpecer la eficiencia de los desarrolladores ya que las librerías no son mantenidas por React Native.
• Xamarin por su parte tiene serias limitaciones ya que no fue concebido con la mentalidad de poder crear buenas UIs. Incluso el hecho de tener que crear dos UIs separadas, una para Android y otra para iOs, lo hace todavía más molesto que crearlas de forma nativa.
• Y Flutter, por último, toma el control de todo el renderizado de vistas, encapsulando de forma transparente el código nativo de Android y ofreciéndolo en forma de Widgets. El único problema es que en el caso de que haya algún bug, se debe esperar a una actualización por parte de Flutter.

Lógica de negocio

Para Android, KMM ya es todo lo nativa que puede llegar a ser gracias a Kotlin, por tanto, la integración es perfecta. Sin embargo, en iOS, aún existen ciertas carencias a la hora de compartir la lógica común, pero sigue siendo fiable gracias a la interoperabilidad entre C y Swift haciendo uso de Kotlin Native.

Por otro lado, Flutter y Xamarin, no ofrecen interoperabilidad directa con código nativo. Con Xamarin es necesario el uso de C++, JNI, Java, Kotlin, o Objective-C Bindings, pero no es posible con Swift. Usando Flutter, el compartir la lógica de negocio con aplicaciones nativas está en fase experimental, y es necesario programar absolutamente todo con el lenguaje oficial de Flutter, Dart.

Por último, React Native, necesita de un intérprete, en este caso JavaScript, algo altamente costoso en comparación con las otras tecnologías.

Eficiencia en el desarrollo

Depurar con KMM es sumamente sencillo gracias a su fácil integración con cada una de las plataformas de desarrollo de código, Android Studio para el caso de Android, y XCode para iOS.

En el caso de Flutter, para conectar con el código nativo, es necesario el uso de un wrapper para sus librerías. Para iOS no se puede utilizar XCode, y para Android, a pesar de que se puede utilizar Android Studio, realmente no se está creando un App de Android con Flutter, sino que se está creando un App en Flutter mediante el uso de plugins de Flutter. Básicamente está en territorio extranjero.

Por otra parte, en React Native, Facebook ha hecho grandes esfuerzos para tener un amplio abanico de herramientas de depuración e IDEs con una muy buena integración. Su principal ventaja es su gran comunidad de desarrolladores web, sin embargo, el uso de librerías nativas no es tan sencillo como en KMM.

Por último, para integrar librerías nativas existentes en un proyecto de Xamarin, Xamarin.Android requiere o bien Java Bindings o bien JNI, y Xamarin.iOS solo soporta ObjC Frameworks, e incluso a veces, no es posible integrar nuevos frameworks de iOS o Android en un proyecto. Además, es necesario el uso de LLDB o GDB para depurar código nativo.

Esfuerzo: Output Ratio

Usando KMM, tanto en Android como en iOS, la integración del código es sumamente sencilla. En el caso de Android, ya es totalmente nativo. Y en iOS, gracias al uso de Kotlin Native, se compila un framework compatible. Y mientras la UI deba permanecer separada, no es un problema ya que por tanto se puede conseguir una UI totalmente independiente de la lógica de negocio (tal y como se recomienda en la implementación de patrones de diseño como MVP, MVVM y Clean Architecture).

Por otro lado, Flutter y Xamarin han sido concebidos para ser un único ecosistema. Por esa razón, es difícil compartir código externo. En ambas tecnologías debes escribir tus popias librerías, en Dart parra Flutter, y en C# para Xamarin. Sin embargo, en Flutter es más fácil compartir la UI que en Xamarin.

Por último, React Native, no es ideal para aplicaciones grandes. A pesar de que la comunidad es grande, está formada prácticamente por desarrolladores web y, por tanto, la integración de estas librerías con dispositivos móviles no es la opción más óptima. Existen diferencias significativas: tamaños de pantalla, rendimiento variable dependiendo de la CPU, RAM y GPU, e innovaciones para plataformas específicas por parte de Google, Apple y Samsung.

Potencial de compartición de código

KMM no está pensado para compartir la UI, solo está pensado para compartir la lógica de negocio. Por tanto, el código que se puede compartir está limitado. Sin embargo, la implementación de una arquitectura separando la UI de la lógica de negocio es una buena práctica (tal y como se recomienda en la implementación de patrones de diseño como MVP, MVVM y Clean Architecture).

Flutter y React Native, en comparación, ofrecen absolutamente todo excepto las características específicas de cada plataforma, por lo que es necesario un canal de conexión con el código nativo. Lo que significa que, si una librería ya existe en el ecosistema correspondiente, bien. Pero en el caso contrario, es necesario escribir código para las tres plataformas – Android, iOS y, Flutter Package API o React Native Bridge Module para acceder a las implementaciones de las plataformas específicas.

Xamarin, por su lado, permite compartir cerca del 100% del código para aplicaciones sencillas. Sin embargo, en aplicaciones más complejas, no es ideal ya que demasiadas características específicas de plataforma, además la UI, necesitan separarse en Xamarin.iOS y Xamarin.Android.

Calidad de la app

Cuando se escribe código con KMM, se consigue una UI y una lógica de negocio totalmente nativa, con la misma calidad que una aplicación escrita en Android o iOS directamente.

En Flutter, la UI es eficiente. Dart VM es más o menos rápido (mucho más en comparación con JavaScript). Sin embargo, el soporte en dispositivos antiguos no es sólido, y como consecuencia el rendimiento puede ser peor que una UI nativa a pesar de que sea un diseño moderno y vanguardista.

React Native, uno de sus aspectos positivos, es que anima vistas nativas y widgets, por tanto, las actualizaciones de UX no se quedan atrás (el usuario espera una característica, si no, las Apps empiezan a verse anticuadas para ellos). Por tanto, existe un alto riesgo de bajo rendimiento a causa de Javascript.

Y para Xamarin, la UI es un añadido, y a pesar de que últimamente el uso de Xamarin.Forms ha ganado popularidad, incluso incorporando widgets nativos, se termina escribiendo toda la aplicación en Xamarin.iOS y Xamarin.Android.

Conclusión

Como era de esperar, cada tecnología tiene sus ventajas y sus desventajas, y no hay una por encima de la otra. Dependerá de cada situación utilizar una u otra.

Sin embargo, el protagonista de este artículo, KMM, sabe lo que puede ofrecer y lo que no puede ofrecer ya que, al compartir, únicamente, la lógica de negocio usando Kotlin y delegar la UI a cada una de las plataformas se consigue una App de máxima calidad gracias a que su código es totalmente nativo, con una integración sencilla con cada una de las plataformas de desarrollo, asegurando un rendimiento óptimo y una magnifica integración con los diferentes componentes nativos.

Autor del artículo

Marc Gareta, consultor de Consultoría Tecnológica de Deloitte