¿Por qué la gente todavía crea aplicaciones móviles específicas de la plataforma, mientras que las aplicaciones móviles multiplataforma se pueden hacer con Xamarin, React.js, etc.?

La gente asume erróneamente que ese es el “mejor” enfoque y proporciona la mejor experiencia de usuario y proporciona pruebas basadas en evidencia al señalar las malas aplicaciones multiplataforma y las buenas aplicaciones nativas.

El problema es que esta es una “profecía autocumplida”, la mayoría de los desarrolladores aceptan eso y siguen eligiendo nativo para estar seguros e invertir más en nativo. Las personas que están dispuestas a reducir los costos para la plataforma cruzada de selección de costos (y también ahorrar en diseño, ingeniería, control de calidad, etc.) que resultan en aplicaciones de baja calidad …

Otro punto que la gente extraña es el costo total, construir una aplicación nativa suena barato. Puede hacer que un gran desarrollador cree una aplicación nativa para una plataforma en menos de 20K USD. Eso sin siquiera mirar soluciones de outsourcing lejanas donde el precio puede ser MUCHO más bajo. Al mirar esas sumas, la gente a menudo comete el error de pensar: “Puedo pagar 40K USD para obtener dos aplicaciones geniales y no es gran cosa”.

El problema es que las aplicaciones tienen valor solo a través del mantenimiento, debe ajustar y refinar constantemente una aplicación con actualizaciones / correcciones frecuentes. Ahí es donde todos esos esfuerzos cambian su costo, ese costo inicial de 20K debería terminar más cerca de 100K por plataforma a través de una aplicación exitosa de por vida. La mayoría de las compañías abandonarán la aplicación mucho antes debido a los costos de mantenimiento. Ahí es donde la plataforma cruzada realmente puede marcar la diferencia, ya que el mantenimiento es mucho más fácil en general.

El punto final es la suposición de que debemos apegarnos a los comportamientos de la plataforma. Android 2.x, iOS 6.xy Windows Phone fueron radicalmente diferentes. Hoy puede crear una aplicación para los 3 que se ve bastante similar y la mayoría de los usuarios no se darían cuenta. Pero la percepción de que existen diferencias permanece a pesar de que está arraigada en una era anterior a la convergencia de la plataforma del diseño plano. Escribí sobre esto más aquí.

Porque

• Inercia. Los desarrolladores que saben nativo no quieren aprender las nuevas formas de desarrollar aplicaciones.
• Superstición. Los desarrolladores ven aplicaciones con una interfaz de usuario o rendimiento terribles y suponen que eso significa que todas las aplicaciones escritas usando entornos de desarrollo multiplataforma apestan
• Ignorancia. Los desarrolladores simplemente no saben que Xamarin [1], NativeScript [2] y React Native [3] usan controles nativos, por lo que son aplicaciones nativas, excepto por el lenguaje que las impulsa. Algunas personas todavía afirman que estas aplicaciones no se ven tan bien como las nativas, por ejemplo, a pesar de que no hay una diferencia real. Y Ionic Framework crea aplicaciones que se ven geniales y también siguen las convenciones nativas.

Creo que los entornos de desarrollo multiplataforma son el futuro de la mayoría del desarrollo de aplicaciones móviles. Es posible que el futuro tarde mucho en llegar debido a lo anterior.

Notas al pie

[1] Cree una interfaz de usuario nativa de Android e iOS con Xamarin.Forms

[2] Inicio

[3] Reaccionar nativo | Un marco para construir aplicaciones nativas usando React

Las soluciones generalmente se eligen en base a criterios incorrectos. La mejor solución es realmente la mejor solución para usted, no para todos. Xamarin tenía sentido para mí debido a mi conocimiento de c # y el marco .net. Si no conoce c # y, en cambio, conoce obkjectivec, ¿tiene sentido que pase mucho tiempo aprendiendo c #? Por lo general, no, a menos que la plataforma cruzada sea uno de sus objetivos.

Elija un idioma basado en lo que tiene sentido para usted.

¡Buena suerte!

En el inicio del que soy parte ahora, decidimos crear aplicaciones nativas, aunque eso significa que estamos creando 4 aplicaciones, iOS, Android, Windows UWP y Mac.

Probablemente podríamos haber reducido eso a 1 o tal vez 2 aplicaciones, usando herramientas multiplataforma. Eché un vistazo a Xamarin y, aunque es impresionante, existe una “seguridad” para usar las herramientas recomendadas para cada plataforma. Si Microsoft saca una herramienta genial que queremos admitir (por ejemplo, Surface Dial), no vamos a tener un problema porque vamos por el camino recomendado por Microsoft. Lo mismo para Apple, digamos que queremos admitir Touch Bar, una vez más, tal vez haya una herramienta multiplataforma compatible, pero existe la seguridad de seguir el camino recomendado.

OK, son 4 aplicaciones, no 1, pero en realidad gran parte del trabajo es del lado del servidor, y gran parte del trabajo es contenido. El número real de líneas de código en cada aplicación es probablemente de unos pocos miles cada una.

Tampoco debe preocuparse de que las aplicaciones aparezcan nativas o no. Las aplicaciones que parecen nativas no son solo miradas , sino también cómo funcionan , la Mac tiene metáforas de la interfaz de usuario que simplemente no existen en las ventanas, como el modelo basado en documentos, o incluso simples popovers u hojas.

Las diferencias de UI en algunas plataformas no son solo visuales , sino cómo funcionan.

Creo que las herramientas multiplataforma tienen mucho sentido para muchas aplicaciones, y tal vez en un año miremos hacia atrás y pensemos que un enfoque multiplataforma podría haber funcionado para nosotros, pero en este momento, la opción de bajo riesgo es haciendo aplicaciones nativas.

Contestaré por Xamarin.

En primer lugar, hay dos formas de crear aplicaciones con Xamarin: Xamarin.iOS + Xamarin.Android y Xamarin.Forms. Si está pensando en Xamarin.Forms, la respuesta es simple: Xamarin.Forms se basa en elementos comunes de Android e iOS y, en la mayoría de los casos, no puede crear aplicaciones de calidad.

Xamarin.iOS + Xamarin.Android puede brindar una calidad muy cercana a las aplicaciones nativas, aunque incluso en algunos casos tampoco coincide (por ejemplo, en este momento no hay una forma oficialmente compatible para crear aplicaciones de Apple Watch) . Pero el precio es que no es probable que ahorre mucho más del 30% del tiempo para desarrollar la aplicación, ya que necesita escribir bastante código específico de la plataforma. Aparte de eso, necesita encontrar uno o dos desarrolladores que juntos tengan un buen conocimiento de Android, iOS y .NET (si desea elegir solo un desarrollador, será muy difícil, pero siempre puede elegirme 😀).

Entonces, el punto es que, si bien hay algo de ganancia, también hay algunas desventajas posibles y no es fácil encontrar personas adecuadas para trabajar productivamente desde el principio.

Porque esas plataformas proporcionan experiencias horribles para el usuario la mayor parte del tiempo. A mí, como usuario, no me gustan las aplicaciones no nativas porque se sienten mal. La única ventaja que tienen esas plataformas es la velocidad de desarrollo.

Sí, algunas API están más allá de su alcance, ya que la mayoría de su contenido permanece en WebView. Aún así, la capa nativa puede comunicarse con la capa web a través de su abstracción y enviar datos como coordenadas GPS, información de contacto y más para el desarrollo de aplicaciones móviles.