Por Josué Yeray Julián Ferreiro, CTO y cofundador de DevsDNA
Hace 8 años, cuando DevsDNA todavía era solo una idea sobre un papel y comencé a trabajar como autónomo con la ayuda de Beatriz y Ciani, Xamarin era una tecnología emergente e increíble que, para alguien cuya carrera se había centrado en C# y .NET, era la elección lógica y más productiva.
A esto tenemos que agregar que, en el contexto de hace 8 años, las alternativas eran pocas: hacer el desarrollo en cada plataforma por separado o usar PhoneGap/Córdova. Xamarin ofrecía la misma potencia que el desarrollo nativo, unificando y reduciendo el tiempo de desarrollo y, en mi opinión, superaba con creces a lo que PhoneGap/Córdova ofrecían.
Durante 2 años, desarrollamos más de 10 aplicaciones nativas usando Xamarin, diseñando la UI con Storyboards, AXML y XAML dependiendo de la plataforma.
En junio de 2016, tras volver del Xamarin partner summit de Sillicon Valley, cambiamos a Xamarin Forms, que ya estaba empezando a mostrar signos de madurez y nos permitía ir un paso más allá, unificando las UIs en un solo XAML que se renderizaba a controles nativos.
Sobre el papel esto nos permitiría ser más rápidos y efectivos en nuestros desarrollos. Seguía sin haber, a mi juicio, ninguna alternativa que por rendimiento y facilidad se igualase. Ahora podíamos escribir una aplicación para iOS, Android y Windows, compartiendo la lógica, la UI y usando un lenguaje común para implementar el acceso nativo al hardware o servicios específicos de cada plataforma. En los últimos 6 años, hemos desarrollado más de 30 apps multiplataforma con Xamarin Forms.
Como todo, no era perfecto, un entorno que unifica 3 sistemas tan diferentes como iOS, Android y Windows (por no hablar de Tizen, linux, mac, WPF…) requiere que mantengas los SDKs nativos de las tres plataformas, además del propio SDK de Xamarin, sincronizados y en las versiones correctas, lo cual es un trabajo interesante, pero totalmente necesario en casi cualquier framework multiplataforma.
También existían bugs, pero el equipo trabajaba duro y con cada versión teníamos mejor rendimiento, más estabilidad lo que nos aportaba mucha confianza en la plataforma. Hasta que llegó el día, en 2020, en que Microsoft anunció el sustituto de Xamarin Forms: MAUI. Ya estábamos a las puertas de recibir la versión 5.0 de Xamarin forms y se quedaría ahí, seguiría recibiendo actualizaciones durante un año, pues MAUI se lanzaría en noviembre de 2021 junto a .NET 6.
Y este era uno de los mayores cambios y que nos llenaba de esperanza y fe en un futuro muy prometedor: Xamarin dejaba de existir como producto separado y se integraba en .NET, pasaba a ser la solución multiplataforma móvil de .NET y eso era bueno.
Pero noviembre llegó y pasó, .NET 6 se lanzó, pero MAUI iba con retraso, se lanzaría en el segundo trimestre de 2022. Hablamos de entre 6 y 9 meses de retraso. Pasaban los meses, recibíamos PREVIEWS de MAUI… hasta 15 diferentes, y la cosa se ponía cada vez más tensa, preview tras preview se veían cosas decentes, pero con grandes ausencias y necesidades que no se cubrían.
Por su lado, tras casi 2 años en mantenimiento vital, Xamarin Forms 5 empezaba a mostrar signos de agotamiento. La release 5 no fue la mejor de todas, muchos problemas con las listas, un calvario conseguir una lista con buen rendimiento, sobre todo en Android, fallos en el layout, updates de mantenimiento que arreglaban un bug e introducían 3 más nuevos. Al final dependiendo de que hacía y que usaba tu app, tenías que ir a una versión de Xamarin Forms 5 u otra y en algunos casos incluso quedarte en Xamarin Forms 4.X…
Por fin en mayo de 2022 se lanza la versión final de MAUI, el sustituto de Xamarin Forms que venía a salvarnos… y que ni siquiera llegaba en estabilidad y rendimiento a la altura de Xamarin Forms. Controles que no existían, fallos con las listas y los scrolls, bugs aleatorios, rendimiento peor en ciertas circunstancias que el de Xamarin Forms… Y comenzaron las dimisiones, miembros del equipo que se marchaban… Miguel de Icaza que abandona Microsoft, aunque a estas alturas era más un símbolo que una parte activa de Xamarin…
Y los viejos del lugar, empezamos a oler algo conocido, el aroma de la muerte, el mismo que olimos con Silverlight, el mismo con WinRT, el mismo con Windows Phone (7, 7.5, y 8.1)… la gran pregunta ¿Por qué una corporación enorme como Microsoft, se permite lanzar un software en un estado tan primitivo como el de MAUI? lamentablemente la respuesta… es que no les interesa en absoluto.
Mirad las apps que desarrolla Microsoft: están hechas nativas para Windows con WinUI o en Electrón multiplataforma. ¿Conocéis React Native? Pues Microsoft tiene un equipo de gente dedicada a portarlo a Windows. ¿Os suena Flutter? Pues también hay gente que ha colaborado y colabora en su desarrollo para Windows… todo bajo el mantra de «ir donde los desarrolladores están» que estaría muy bien, si además apoyases a los desarrolladores que usan (y pagan) tus productos…
Mientras, al sur de Seattle, en Mountain View… un gigante estaba preparando su asalto al mundo del desarrollo multiplataforma… y que bien lo ha hecho.
Flutter se basa en el lenguaje de desarrollo dart y aporta una solución a medio caballo entre Xamarin Forms y Córdova, por ejemplo, permitiéndonos escribir la lógica y la UI de forma unificada en dart, pero no usando controles nativos si no un canvas de Skia para dibujar nuestra app. Como si de un motor gráfico se tratase, a 60fps, nuestra app parecerá 100% nativa si queremos, pero no usará controles nativos, más allá de la base de la app y del canvas de Skia.
Siempre he sido un gran detractor de esta idea, pero hay veces que lo más importante es darte cuenta de que, llegado el momento adecuado, estas equivocado. Google está apostando por Flutter, van por la tercera versión, que tiene una madurez y estabilidad increíble, el rendimiento es algo nunca visto en Xamarin Forms, y lo más importante: Lo usan internamente en apps como Google Pay y Stadia. Pero no solo eso, empresas como BMW, eBay, ByteDancer, Toyota… confían ya en Flutter.
En unos pocos años, Google ha conseguido un show case de Flutter con el que Microsoft por ahora solo puede soñar para Xamarin.
Por todo esto, después de este largo camino, cuando nos enfrentamos a la decisión de que hacer mirando a medio plazo, a 2 o 3 años, me di cuenta de que no podía poner mi confianza, mi fe y de paso el sustento de 7 familias, en las manos de Microsoft y MAUI. Llevamos desde principios de 2022 estudiando Flutter, preparándonos, probando todos los rincones oscuros como acceso a hardware nativo, uso de librerías nativas de terceros, llamadas a librerías escritas en C, rendimiento… y oficialmente este mes de Julio hemos comenzado el desarrollo de nuestra primera app seria y grande con Flutter 3.
Y tras un mes, os puedo decir que la experiencia de desarrollo, cómo funciona el hot reload de verdad que tiene, que no tengas que pelearte con las herramientas… ha hecho que la experiencia sea muy placentera, por lo que ya estamos preparados y decididos a que todos nuestros nuevos proyectos a partir de ahora sean en Flutter.
Pronto empezaremos a publicar contenido sobre Flutter en nuestro canal de YouTube e intentaremos movernos en la comunidad y enseñaros lo que nos ofrece y no nos ofrece Flutter y como crear apps increíbles con él.
Adiós, amigo mío, ha sido un largo y emocionante camino, pero toca despedirse…
