Flutter vs Xamarin: Una opinión de un análisis

Flutter vs Xamarin, ¿un tema agnóstico? difícil es, mas no imposible. Este artículo es basado en un artículo que se compartió en la comunidad de Universo Xamarin en WhatsApp y que luego se compartió en la comunidad de Telegram.

Xamarin y Flutter son Frameworks que han estado en la boca de muchos, ofrecen un modelo de trabajo interesante que ha llamado la atención de muchos. He visto muchas personas que abogan a favor de un framework haciendo comparaciones basadas en malas experiencias pasadas o en el comentario de lo que otros escucharon.

Si piensan que hablare del maravilloso mundo de Disney, entonces lamento decepcionarlos. La idea es mostrar ambos lados basado en una previa investigación que hecho con el fin de que esto llegue a un maravillo lugar llamado «Conciencia».

ASO strategies

Igual pienso agregar y dar crédito a aquellos comentarios interesantes que tengan fundamentos, con el fin de actualizar este reporte.

Hasta ahora solo he conocido algunas personas que probado Flutter, mas no trabajan con el, y hemos hablado al respecto y les puedo decir que hay cosas que las personas no comentan, pero no pasa nada porque es algo normal con las nuevas tecnologías. Yo no voy a entrar en esos detalles, quizás mencione algunos detalles dependiendo del apartado, pero al final siempre recomendaré que hagan su propia investigación y no tomen mis palabras como una decisión final. Ustedes empezar con una simple búsqueda como esta o esta.

La verdad, es que hay muchos comentarios acerca de estos dos Frameworks y siempre viene la discusión de cual es mejor o donde está el futuro de una determinada herramienta. Si bien es cierto que el futuro es incierto, siempre podemos apostar por una determinada tecnología al final; eso dependerá de nuestro entorno.

¡Nunca olvides esto!

Realmente soy escéptico a este tipo de conversaciones, en este caso quiero compartir la información porque creo que en muchas comunidades se está suponiendo o sacando conclusiones en base a experiencias pasadas o rumores mal informados.

¡Hey! Si eres una de esas personas que ha tenido malas experiencias con una determinada herramienta quiero que visualices esta palabra en tu mente: TODO EVOLUCIONA. Si, así es, Todo Evoluciona. Repite conmigo, ¡Todo Evoluciona! ¡Una vez más! Todo… Ok, ya.

Para mi (opinión personal), todos los Frameworks son herramientas y la calidad del producto final no depende de la herramienta, si no del desarrollador que hay detrás.

Sabiendo que el entorno en el que me desenvuelvo es Xamarin, los puntos a tratar pudieran ser vistos como parcializados. Es por ello que quiero recalcar que la información que verán aquí, es un tema de discusión expuesto en varias comunidades donde pude interactuar con distintos puntos de vistas. Adicional a esto, tuve que investigar cada detalle por propia cuenta para tratar de traeros información verídica.

Es bueno mencionar que tratare de no hacer ninguna declaración en contra o favor de ninguna herramienta (Si se me escapa algo, bueno… ¿Qué le vamos a hacer?), solo discutiremos los criterios de evaluación tomados en cuenta para el análisis. Cuando empecemos a ver las herramientas como lo que son empezaremos a sacarles mayor provecho a estas para subir el siguiente nivel.

¡Dicho esto, empecemos!

Flutter vs Xamarin: Criterios de Evaluación

En el artículo original se cubrieron algunos criterios de evaluación que os dejare aquí:

  1. Instalación
  2. Arquitectura
  3. Patrón de Arquitectura
  4. Lenguaje
  5. Curva de aprendizaje
  6. Productividad
  7. Tiempo de lanzamiento
  8.  Código compartido
  9. UI/UX
  10. DevOps
  11. App size
  12. Performance
  13. Soporte de la comunidad
  14. Plataformas soportadas
  15. Precio / Open source
  16. Futuro

De igual manera os dejo una Conclusión por si son muy desesperados y quieren ver la resolución final. Ahora sí, ¡vamos a ello!

Instalación

Realmente, yo no tomaría la instalación como criterio de evaluación, ya que la instalación se hace una vez y no debería ser punto de evaluación por más complicado que sea.

tecnologies

En la comunidad de Universo Xamarin en WhatsApp, algunos comentaron que el entorno de VS es mejor. Solo tienes que dar algunos clics y dejar el VS con los componentes que vas a necesitas descargando e instalando, y ya está. Se puede decir que el proceso es casi automático, por así decirlo.

Yo no he instalado Flutter, pero para este apartado me puse a investigar. Para poder instalar Flutter, tienes que hacerlo todo por consola y hay que instalar SDK, Android Studio, Tools, Editor, etc. Añádele editar algunas variables de entorno y eso. Todo por consola de comandos. No es que sea algo del otro mundo, aunque creo que con VS el proceso es más intuitivo ya que no hay que hacer prácticamente nada. De igual manera, vi algunos comentarios que dicen que con VSCode el proceso de instalación de Flutter es casi automático también.

Independientemente de, no creo que este sea un punto para evaluar estos Frameworks. Al final este proceso solo se hace una vez. En fin, yo no lo tomare en cuenta. Igual ustedes dejen sus comentarios sobre este apartado.

Actualización: La consola no es mala, yo la utilizo de vez en cuando, solo digo que las personas que no usan la consola se les dificultara la linea de aprendizaje.

Arquitectura – Nivel Técnico 

Flutter y Xamarin tiene dentro de su motor todos los componentes necesarios para desarrollar una app.

La arquitectura de Xamarin parece más sólida si hacemos la comparación. Si queremos hacer uso de la API nativa de la plataforma objetivo podemos hacerlo con C#. Es bueno mencionar, que Xamarin no tiene soporte para Kotlin o Swift en tiempo de ejecución.

Ahora bien, ¿No se supone que utilizamos un framework multiplataforma para no ir a utilizar código nativo? ¿Esto no alargaría la ruta de aprendizaje? Dentro del entorno de Xamarin, podemos utilizar componentes nativos sin la necesidad de utilizar código nativo.

Por otro lado, Flutter utiliza el código especifico de la plataforma (Java/ Kotlin en Android y Objective-C/Swift en iOS) para hacer uso de estas API. Esto aumentaría bastante la línea de aprendizaje al tener que aprender varios lenguajes más (Mas sobre este tema en la ruta de aprendizaje).

Hay algunos casos específicos, donde tendremos que utilizar librerías muy específicas o Frameworks desarrollados por las mismas empresas, y tendremos que utilizar esas librerías o código. Xamarin te permite enlazar esas librerías, en el caso de Flutter, aunque te permite enlazar esas librerías también tiene la opción de utilizar una porción de código, ya que utiliza código nativo para casos específicos.

Flutter aquí tiene un punto a favor. Si bien es cierto, darle la opción al usuario que pueda hacer o no lo que quiera de varias formas, en este caso utilizando los lenguajes nativos, no está nada mal.

Tanto Flutter como Xamarin en este apartado tienen ventajas y desventajas. Dependiendo del mundo en el que vengas una u otra puede ser más conveniente o interesante para ti.

Si alguno quiere agregar algo más al tema, bienvenido seas compañero. Yo lo dejare por aquí.

Patrón de Arquitectura

En Xamarin.Forms, se utiliza una arquitectura limpia a través del patrón MVVM (Model-View-ViewModel). En Xamarin.Android, se utiliza MVP (model-view-presenter). En Xamarin.iOS, comúnmente se utiliza MVC (Model-View-Controller). Todos ellos son unos claros y bien conocidos patrones de arquitectura o diseño que han demostrado funcionar bien para cualquier tipo de aplicaciones.

En Flutter, todavía no se ha definido un estándar o un enfoque de arquitectura universalmente aceptada. Hasta donde he estado viendo, todos los artículos muestran ejemplos simples, lo que es normal porque necesitan guiar a las personas en lo más básico antes de hablar sobre aspectos más avanzados.

Según lo que he leído, si están pensando usar Flutter para un proyecto grande, sería preferible tener una idea clara de cómo lo va a estar estructurado, de modo que sea escalable y fácil de mantener a medida que la aplicación crezca en tamaño y complejidad. Obviamente, esto tiene sus pros y sus contras; pero aquí no hablaremos de eso.

Lenguaje

Se habla de que C# es mejor que Dart porque es más popular. ¡Ok, calmaos! Ciertamente el uso de una determinada tecnología puede significar algo especial dentro de una tecnología, pero la popularidad de un lenguaje no define lo sólido, maduro y funcional que este puede ser. C# es un poderoso lenguaje orientado a objetos (OOP) bien diseñado y legible.

Hay muchas características dentro y fuera del entorno por lo que se recomienda C# sobre Dart como lenguaje de programación (No tienen que creer en mí, googleen lo). No voy a abundar mucho en esos detalles, aquí parece que el foco principal es DART.

«Google está desarrollando Dart porque Google tiene un interés comercial en migrar fuera de la JVM (Máquina Virtual Java). Si no tiene esos mismos intereses comerciales, ¿qué ofrece Dart? Carece de características (sin subprocesos múltiples, soporte deficiente para funciones de orden superior, sin seguridad para nulos, no tipos de unión, no funciones de extensión, no clases de datos, peculiaridades de sintaxis como el operador de cascada, etc.), tiene herramientas menos robustas, un ecosistema menos maduro, etc.»

Esto es lo que comentan algunas personas. Yo no tengo ningún conocimiento sobre esto, pero ahí les dejo el hilo.

Nota: Con Xamarin también se puede utilizar FSharp (F#) que es un lenguaje de programación funcional.

Curva de aprendizaje

Cuando hablo de ruta de aprendizaje, hablo literalmente del dominio de lo que estás haciendo. En Xamarin.Forms, muchos se quejaban de que tenían que utilizar un CustomRender cuando necesitaban hacer algo que era especifico de alguna plataforma.

Esto ya no pasa tanto, la comunidad ha madurado bastante y hay buenos plugins y herramientas que nos ahorran muchos dolores de cabeza. ¿Pero qué pasa cuando necesitamos hacer algo muy específico? Así es, CustomRenders son la solución.

Con Xamarin, hay configuraciones que tendrás que hacer en cada plataforma específica para el lanzamiento de tu aplicación, por ejemplo, en Xamarin.Android y Xamarin.iOS. Estas pueden alargar un poco la curva de aprendizaje, y digo un poco porque en un inicio los cambios que tendrías que hacer serian mínimos. Entre casos más avanzados, más avanzadas algunas configuraciones.

Como mencione anteriormente, vi que en Flutter tienes que hacer uso de las API nativa en código nativo lo cual aumentaría bastante la línea de aprendizaje al tener que aprender varios lenguajes más, aparte de los por menores de estas plataformas.

Como pueden ver, independientemente de la plataforma o el framework, parece que siempre habrá este tipo de casos y ¿Adivina qué? Al menos que seas el jefe, tendrás que resolver el problema, para eso te pagan.

Por otro lado, Flutter utiliza consola de comando para realizar muchas tareas. ¿Las personas que no utilizan consola mucho, no le afecta en la curva de aprendizaje? Solo digo, porque al final estoy hablando de aprender, no copiar y pegar.

Con esto no quiero decir que Xamarin es más fácil de aprender que Flutter. No he visto Flutter, solo digo que hay muchos criterios de evaluación que afectan la curva de aprendizaje a largo tiempo. No es solo crear un TODO o seguir un tutorial y decir que uno u otro es más fácil. Es sumar todos los detalles y ver que te hace más productivo.

Al final tu ruta de aprendizaje va a variar mucho dependiendo del entorno en el que te desenvuelvas y estés acostumbrado a trabajar.

Actualización: Con ambos frameworks puedes crear una aplicación sin la necesidad de la personalización en cada plataforma (CustomRenders en Xamarin / Lenguaje Nativo en Flutter).

Productividad

Recursos

Si bien es cierto, la comunidad de Flutter está creciendo enormemente y está siendo muy activa. Pero aun así su ecosistema aún le falta madurar. La comunidad de Flutter ha creado gran cantidad de componentes y plugins, pero la lista todavía no es tan extensa como la de Xamarin.

«Flutter tiene una lista decente de componentes de UI y otros complementos de excelente apariencia, pero no es tan rico como los complementos que puedes encontrar para Xamarin. Las opciones son limitadas, y muchos complementos son antiguos, no se mantienen, y tal vez ya no funcionan con las versiones actuales de Dart / Flutter. Algunos componentes (especialmente los que no son de interfaz de usuario, las funciones específicas de la plataforma de mapas) solo están disponibles para iOS o Android, pero no para ambos (por lo general, son compatibles con Android porque los desarrolladores de Android están más con Flutter que los desarrolladores iOS en este momento, ya que Flutter proviene de Google).»

Marco Bellinaso
Texto traducido del ingles

Opiniones en la caja de comentarios.

Manejo de recursos

En Xamarin, dependiendo la plataforma en la que estés trabajando, necesitas colocar los recursos que vas a utilizar en folder específicos para el manejo de las resoluciones entre múltiples dispositivos. Claro, con Xamarin también tienes la opción de reutilizar recursos en tu proyecto compartido y dependiendo del recurso tendrás que utilizar alguna configuración extra.

En Flutter tienes los archivos en un lugar (con subfolders si quieres) descritos en un archivo yaml. Otros archivos, como icono de lanzamiento y configuraciones de la plataforma, también al igual que otros Frameworks deberán estar dentro de una carpeta especifica.

managment

Ahora bien, en términos de mantenimiento, actualización, y sincronización de archivos a nivel de productividad Flutter es realmente útil ya que la mayoría de los recursos lo maneja en un solo lugar.

Herramientas

El Hot Reload es una característica que se ha hecho muy útil y llamativa para los desarrolladores, ¿y porque no? Esta incrementa enormemente nuestra productividad.

El hot reload es uno de los detalles que sobresalta en Flutter, entre las comunidades. Flutter tiene algunas herramientas muy interesantes que puedes ver aquí, mas allá de estas y algunas extensiones en VSCode no encontré nada llamativo. Ya hablaremos de las herramientas de testing más adelante en la sección de testing.

Xamarin tiene varios Hot reload provenientes de herramientas de terceros, algunos con algunas características interesantes. De igual manera, ya se anunció el hot reload oficial antes de finalizar el año.

Por otro lado, en Visual Studio, Xamarin.Forms tiene XAML Previewer que te permite ver como se verá tu página en las plataformas iOS y Android (Recordando que los controles son completamente nativos). Tiene un Toolbox para usar Drag and Drop de controles y un panel de edición de propiedades para tu XAML.

En este articulo hablo de algunas herramientas, paquetes y extensiones de terceros relacionadas al diseño en Xamarin.Forms. De igual manera, Xamarin dentro del entorno de Visual Studio tiene otras herramientas muy interesantes que pueden ver aquí. Estas últimas, las detallaremos en la sección de testing más adelante.

Para Visual Studio hay muchas extensiones interesantes que nos pueden ayudar en temas de productividad. En el entorno de Visual Studio tenemos herramientas como IntelliCode (Desarrollo asistido por AI) y por parte de la comunidad tenemos  Multilingual App Toolkit (nos ayuda con los servicios de soporte de varios idiomas en nuestras app), por mencionar algunas.

Tiempo de lanzamiento

Cada plataforma nativa cuanta con algunas configuraciones específicas que se deben llevar a cabo antes del lanzamiento de una aplicación. Sin importar el framework que utilices (o por lo menos tomando en cuenta los actuales) estas configuraciones siempre serán las mismas, lo único que cambia es el proceso de hacer estas configuraciones entre Frameworks.

Según vi en la documentación oficial de Flutter (Android/iOS), todos estos procesos de configuración se hacen manual.

Por otro lado, con Xamarin + VS (Android/iOS) este proceso de configuración es muy intuitivo porque todo se maneja gráficamente. Es bueno mencionar, la documentación de Xamarin en este apartado es más extensa y detallada, teniendo algunas configuraciones adicionales que podrían ser de interés en ciertas ocasiones.

Código compartido

Una aplicación en Xamarin puede compartir más del 95% de código, mientras que en Flutter se puede llegar a compartir hasta un 70% de código. Es bueno aclarar que estos porcentajes pueden variar dependiendo de la complejidad y personalización del proyecto.

En cierta media también dependerá de las funcionalidades nativas de la aplicación. Por suerte, para el entorno de Xamarin se tiene un conjunto de componentes y librerías, entre la más destacada Xamarin.Essentials, que como su nombre lo indica, contiene las APIs multiplataformas esenciales para nuestras aplicaciones móviles. Otras librerías la pueden encontrar en Nuget y otras pueden encontrarse en la comunidad, algunos ejemplos de ellos en Xamarin Universal Library.

cross-platform-apps

Dentro del entorno de Flutter podemos encontrar algunas librerías interesantes que cumplen el mismo objetivo. Estas en su mayoría por algún motivo están en Developers Preview. Por otro lado, por parte de la comunidad encontré un repositorio, que tiene por nombre Awesome Flutter, que contiene librerías, tutoriales, Frameworks, etc.

Ambos entornos cuentan con características similares, aunque en las listas de Flutter muchas de las librerías mostradas todavía están en preview. Igual ustedes echen un vistazo y me dejan saber sus opiniones.

Nota: Analizado en agosto del 2019

Actualización: La reutilización del código en Xamarin no es solo entre dispositivos móviles, sino que también puede reutilizarse el código entre el servidor y el cliente. Las clases de DTO, solicitud y respuesta junto con la lógica de negocios se pueden compartir. Ahora que, todo .net va hacia bibliotecas estándar .net, el ecosistema Xamarin será más capaz.

Subodh
From comments

UI/UX

Componentes de UI y APIs de desarrollo

Este es uno de los apartados más difíciles de valorar, ambos Frameworks ofrecen grandes cantidades de componentes para crear cualquier tipo de aplicación. Muchos de estos son completamente diferentes y la API varía mucho.

Si evaluamos en base a cantidad, Xamarin soporta más plataformas que Flutter por lo que Xamarin tiene una ventaja clara en este enfoque.

De igual manera, si evaluamos en base a madurez, aunque Flutter tiene muchos componentes a estos le faltan madurez. Según la investigación que he hecho, muchos de los componentes de Flutter tienen muchos errores (para ver esto solo hay ir a su repositorio)  abiertos desde hace tiempo, algunos básicos para algunos componentes.

Mas sobre el tema en este hilo.

Por otro lado, Flutter te permite jugar un poco más con los componentes con la única idea de facilitar el área de diseño a los equipos de desarrollo. Se puede decir que una de las ventajas que ofrece Flutter es trabajar el diseño con una simplicidad increíble. Trabajar en un equipo pequeño sin un diseñador a tiempo completo parece ser una bendición.

Yo lo dejo ahí, ustedes comenten sobre este peculiar caso.

Experiencia de usuario

Dentro de este apartado hay mucha controversia porque hay diferentes puntos de vistas y opciones que analizar.

Cuando se desarrolla aplicaciones móviles multiplataforma, la compatibilidad con los componentes nativos puede ser la clave. Sin el soporte para componentes nativos, en muchas ocasiones nuestra aplicación no se sentirá como una aplicación nativa. Es muy importante que el framework tenga una API para acceder a los componentes nativos sin ningún problema.

Lo bella y hermosa que sea una aplicación no cambia el punto de percepción descrito anteriormente. Si usted ha trabajado en equipos corporativos de desarrollo de aplicaciones o al menos tiene en mente llegar a trabajar en uno algún día, deberías saber lo importante que es la experiencia de usuario (UX) para ellos. Te puedo decir que hay equipos que solo se dedican a crear UX, porque si el usuario no se siente cómodo el producto que se ofrece puede ser un fracaso.

Dentro del ambiente de Flutter podemos encontrar gran cantidad de componentes que realmente ayudan bastante a nivel de diseño y efectos. Sin embargo, aunque en Flutter los controles parezcan nativos, no lo son. Igual he encontrado varios artículos donde se muestra como introducir un componente nativo dentro de una vista de Flutter con un poco de personalización extra, un ejemplo aquí.

Lo digo porque hay muchos de estos componentes que necesitan madurar un poco más, por ejemplo, aquí pueden ver uno de los  hilos que encontré mientras hacia la investigación.

Ok, pausa.

Algo curioso que quiero comentar es que he hecho una búsqueda sobre la consistencia de los diseños de interfaz de usuario en aplicaciones móviles y he encontrado un artículo que menciona algo que me llamo la atención.

La consistencia en el diseño de la interfaz de usuario (UI) tiene que ver con garantizar que los elementos en una interfaz de usuario sean uniformes. Se verán y se comportarán de la misma manera. Esto ayuda a probar constantemente las suposiciones de un usuario sobre la interfaz de usuario correcta, creando una sensación de control, familiaridad y confiabilidad.

Para desarrollar coherencia en el diseño de la interfaz de usuario, se debe intentar ser coherente con las pautas y comportamientos de la UI del dispositivo, otras aplicaciones y con su propio diseño. Las diferentes plataformas tienen diferentes IU y pautas de usabilidad que debes observar al diseñar.

MARIA DE LA RIVA
Traducido del ingles

Muchas personas se confunden entre la consistencia del diseño y la consistencia entre plataformas. Estas son totalmente diferentes.

Ok, continuemos.

En el caso de Xamarin los componentes parecen nativos porque lo son. Esto quiere decir que cumplen con todos los requerimientos de la interfaz de usuario (UI) y la experiencia de usuario (UX).

Igual me gustaría que me dejarán sus comentarios sobre que piensan sobre este apartado. Es un tema que se puede escribir solo un artículo sobre él, pero yo ahí se los dejo.

DevOps

Integración y Entrega Continua (CI/CD)

Hay muchas herramientas que aportan valor a CI/CD dentro de ambos entornos. Algunas de ellas se utilizan en ambas plataformas, como es el caso de Azure DevOps o Jenkins.

Dentro del entorno de DevOps con Xamarin podemos encontrar algunas herramientas bastantes interesantes como App Center y HockeyApp. Por otro lado, dentro del entorno de DevOps con Flutter se pueden apreciar herramientas como fastlane y Codemagic.

Tomando en cuenta las herramientas oficiales, Visual Studio App Center ciertamente hace muchas de las cosas que hace Fastlane, pero depende completamente de su caso de uso individual para poder comparar fastlane con App Center.

Con App Center se puede contar con:

  • Soporte para: iOS, Android, Windows, React Native, Xamarin e incluso más aplicaciones
  • IU intuitiva pero poderosa
  • Integración con GitHub, BitBucket y VSTS
  • Notificaciones push
  • «Los informes de bloqueo son tan buenos que casi querrás que tu aplicación se rompa».
  • Una gran cantidad de análisis y gráficos.

Lo que obtienes con Fastlane:

  • Alrededor de 170 integraciones con otros servicios.
  • Proyecto 100% de código abierto bajo la licencia MIT
  • La solución local, para que sepa dónde están sus datos, no necesita preocuparse por la seguridad de los datos (excepto su propio je)
  • Integración con todas las principales herramientas de CI
  • Soporte para aplicaciones iOS, Mac y Android.
  • Ilimitadas posibilidades de personalización
  • Despliegue desde cualquier lugar

Testing

Dentro de este apartado ambos ambientes están muy completos y capacitados. En esta ocasión, les voy a mostrar algunas herramientas de estos ambientes para ustedes puedan comparar.

Flutter tiene algunas herramientas muy interesantes que puedes ver aquí. Veamos algunas a continuación:

  • Flutter Inspector: es una herramienta para visualizar y explorar los árboles de widgets de Flutter.
  • Timeline view:  muestra información sobre los fotogramas (frames) Flutter.
  • Memory view: permite ver cómo un aislamiento está usando la memoria en un momento dado.
  • Performance view: permite grabar y perfilar una sesión desde su aplicación Dart.
  • Debugger: DevTools incluye un source-level debugger, soporta breakpoints, stepping e inspección de variables.

De igual manera, Xamarin tiene algunas herramientas muy interesantes que pueden ver aquí. Las mismas les describo algunas aquí:

  • Xamarin Inspector: Herramienta que permite visualizar tus controles en 3D para inspeccionar, depurar y diagnosticar su aplicación en ejecución.
  • Xamarin Profiler: Herramienta que sirve para analizar el comportamiento (snapshots de memoria, estadísticas, arbol de llamadas, asignaciones, perfil de tiempo,  etc.) de las aplicaciones.

Dentro de Visual Studio hay muchas herramientas incorporadas (Android debug log, Android device monitor, Debuger, etc.) y otras de terceros que nos ayudan bastante. En este articulo hablo de algunas relacionadas al diseño.

App size

Parece que mientras nuevos Frameworks se lanzan es más notable el tema del tamaño de las aplicaciones. Este fue uno de los problemas más comentados a los inicios de Xamarin, hoy en día parece que Flutter está lidiando con este tema también.

Igual en la documentación oficial de Flutter podemos ver lo siguiente:

En julio de 2019, medimos el tamaño de descarga de una aplicación mínima de Flutter (sin Componentes de material, solo un widget de Centro, construido con Flutter build apk –split-per-abi), incluido y comprimido como APK de lanzamiento, para ser aproximadamente 4.3 MB para ARM y 4.6 MB para ARM 64.

Por otro lado, dentro del entorno de Xamarin nos podemos encontrar con un «Hola mundo» de 2.9MB. Ya anteriormente había hablado de este apartado un poco más a detalle, te dejo el articulo aquí.

Performance

El performance de una aplicación depende enteramente de los desarrolladores que la trabajen. Sin embargo, hay algunos tips o detalles que marcan una pequeña diferencia. Entre Frameworks muy posiblemente ni siquiera pueda ser notada, pero con las herramientas necesarias se puede ver la información más contrastada.

Toda la investigación y datos mostrados en este articulo fueron obtenidos del gran y maravilloso mundo del internet. Lamentablemente, no pude encontrar ninguna estadística o prueba similar con estos Frameworks.

Si ustedes saben de alguna prueba me dejan saber, yo analizare la veracidad de los datos y actualizare el artículo de ser necesario. Si quieren hacer una prueba, igual me dejan los detalles y lo publicamos.

Soporte de la comunidad

¿Como podemos medir el soporte de la comunidad?

  • ¿A través del repositorio de GitHub? Flutter tiene 72k estrellas, con 424 contribuidores. Mientras Xamarin tiene 6.6k estrellas, con 367 contribuidores (Xamarin.MaciOS 1.7k estrellas, 86 contribuidores + Xamarin.Android 1.3k estrellas, 70 contribuidores + Xamarin.Forms 3.6k, 211 contribuidores).
  • ¿A través de las aportaciones (componentes, herramientas, etc.)? Aquí solo podemos hacer suposiciones.
  • ¿A través de la madurez de estas? Suponiendo que no es cantidad, es calidad. ¿Como medimos esto?
  • ¿A través de los grupos de comunidades? Esto varía dependiendo la localización, pero igual ¿Como medimos esto?

Todos los comentarios son bienvenidos para este apartado.

Plataformas soportadas

En estos tiempos, Xamarin es el framework que soporta más plataformas hasta el momento. Con un total de seis (6) plataformas, Xamarin soporta Android, iOS, Windows, MacOS, Linux y Tizen.

Algo que me sorprendió encontrar fue el soporte de Xamarin.Forms para web, el cual pueden ver en este repositorio. Este no es oficial y al parecer no tiene una versión estable todavía.

Pareciera que no, pero cuando trabajas en equipos de desarrollos para empresas con alto volúmenes de solicitudes el desarrollar para diferentes plataformas agrega mucho valor al equipo de desarrollo. Solamente no es Android y iOS, créanme cuando les digo esto.

Oficialmente Flutter solo soporta Android y iOS. Sin embargo, según declaraciones oficiales tienen en mente soportar Windows, MacOS, Linux y Web.

Precio / OpenSource

Ambos Frameworks son completamente gratis y de código abierto.  ¡Fin!

Futuro

Ciertamente, el futuro es incierto. Lo que funciona hoy, quizás no funcione mañana. Esto es parte de la evolución, y más en estos tiempos donde la tecnología avanza muy veloz.

analytics

Hoy en día, en el área de desarrollo general, se está tomando muy en cuenta la agilización dentro de los procesos de desarrollo y es aquí donde Flutter introduciendo su concepto de widget simplifica mucho una parte del desarrollo de aplicaciones móviles.

Por otro lado, Xamarin siendo una herramienta más madura, también está introduciendo conceptos nuevos como Shell que están agilizando el tiempo y reduciendo la complejidad del desarrollo de aplicaciones móviles.

Conclusiones

Como he dicho en varias ocasiones, la única persona que puede decirte si una herramienta es buena o es mala eres tú mismo. Busca, analiza, prueba y saca tus propias conclusiones. Muchos piensan que haciendo un hello world pueden ver el verdadero potencial de una herramienta, ya en varias ocasiones les he dejado algunos criterios de evaluación para que los tomen como guía de partida.

Si se fijan, nunca he dicho que una herramienta es mejor que otra. Al final, a mí no me pagan para que ustedes utilicen una determinada herramienta. Solo me gusta compartir información, mis opiniones, conocimiento y experiencias que creo que puede ayudar a la mayoría de los que entran a este blog a consultar.

A mí me gusta dar valor a todos por igual. Lo que quiero con este artículo es que se deje de desinformar, que se muestren los puntos claros, las fuentes, los autores, etc. Hay muchas personas que están compartiendo información errónea en las comunidades, pero no podemos juzgar a estas al final ellos están enseñando lo que aprendieron.

La verdadera Ignorancia no es la ausencia de conocimientos, sino el hecho de rehusarse a adquirirlos.

– Karl Popper

Mi opinión no es el resultado final

De igual manera, me gustaría que validen todos los puntos que he mencionado y si hay otros déjenmelos en los comentarios. Siempre me ha gustado escuchar las opiniones de los demás.

Si tienen alguna información extra que pudiera servir para agregarla a la evaluación, la pueden dejar en la caja de comentarios sin problemas, con gusto las tomare en cuenta.

De interés…

Muchas gracias por leer esta publicación! 
Flutter vs Xamarin: Una opinión de un análisis
5 (100%) 3 votes

Otros

feedback

Te invito a dejar tu opinión en la caja de comentarios. Si quieres que hable de un tema en específico o que detalle un poco más algunos temas, déjame saber. Los temas más interesantes serán agregados en mi lista de publicaciones futuras.

¿Te gustan las publicaciones como esta? Entonces, suscribete y activa las notificaciones push para recibir actualizaciones. Nos vemos en la próxima!

2018-12-06T21:47:26-04:00

6
Dejame tus comentarios

avatar
3 Hilos de comentario
3 Respuestas de hilos
0 Seguidores
 
Comentario más reaccionado
El hilo de comentarios más caliente
4 Comentarios de autores
Luis MatosAnthony Will Solsol SoplinFrank MorenoFelix Manuel Comentarios de autores recientes
  Suscribirte  
Nuevos Viejos Mas votados
Notificar de
Felix Manuel
Invitado
Felix Manuel

Pero como puedes hacer una evaluacion si ni siquiera has hecho una instalacion de Flutter. Para evaluar hay que probar.

Frank Moreno
Invitado
Frank Moreno

Errores en este artículo: – Errores de redacción y gramaticales en muchas partes. – Referencias de Noviembre del 2018 que ya no son válidas desde el 4 de diciembre del 2018. (https://medium.com/asos-techblog/flutter-vs-react-native-for-ios-android-app-development-c41b4e038db9) – Difunde miedo a la consola cuando es la herramienta que más ayuda en el desarrollo. – Si uno gusta, no requiere de consola para Flutter si se configura su IDE. – El seguimiento a la evolución de Flutter es muy pobre. – Un desarrollador Flutter difícilmente llega a ver código en Java/Kotlin o Objective-C/Swift, una gran mayoría solo usará Dart y nada más que Dart. Solo cuando… Leer más »

Anthony Will Solsol Soplin
Invitado
Anthony Will Solsol Soplin

No me parece correcto que alguien que tenga tanta experiencia en darle uso a una herramienta lo compare con otra que no se atrevió nisiquiera a instalar, así se haya investigado no es suficiente si no lo has llegado a probar, claramente habrá un sesgo de aceptación así no se quiera. Por ejemplo, tus investigaciones dicen que Flutter usa la consola y código nativo, lo cual es cierto, pero es una opción más en realidad. VS Code y Android Studio te ofrecen todo gráficamente para continuar tu proyecto y realmente es muy difícil que te topes con código nativo por… Leer más »