¿Por qué algunas personas siguen aprendiendo Swift y Java para crear aplicaciones iOS y Android, (por separado), ya que saben que pueden crear la misma aplicación con menos tiempo usando Xamarin en C #?

Answer 1

Bueno, eso es un poco insultante para mí. ¿Crees que yo, y la mayoría de los desarrolladores de plataformas nativas, simplemente no sabemos nada mejor?

Te diré por qué.

• Actuación. Las aplicaciones nativas se desempeñan mejor y tienen una mejor apariencia que los híbridos. Los híbridos están basados ​​en la web, por lo que son naturalmente más lentos y dependen de una conexión a Internet. Las aplicaciones nativas son más confiables.
• Limitaciones de la API. Sí, en mi trabajo, usamos la oscura función Bluetooth LE, y apenas podemos arreglárnoslas con las API oficiales y su documentación de mierda. Imagina tratar de hacer esto en una plataforma híbrida. ¿Crees que Xamarin me permitirá manipular BLE mejor que las API nativas? De Verdad?
• Como corolario, ¿cómo usaría un híbrido el MetalKit de Apple, un motor de computación de gráficos de bajo nivel? ¿O el NDK de Google, con funcionalidad de bajo nivel Vulkan / OpenSL? ¿Cómo utilizarías las unidades de audio de Apple, su API de audio de nivel más bajo? Las personas que hacen un trabajo serio necesitan acceso a estas cosas.
• Seguridad. La seguridad es primordial en mi dominio. Supremo. Seriamente. Es un dispositivo médico. La seguridad es obviamente mejor en las versiones nativas.
• Limitaciones de hardware. Las aplicaciones híbridas no tienen el mismo acceso al hardware que las plataformas nativas. Si su aplicación requiere GPS, acelerómetro, Bluetooth, etc … buena suerte con un híbrido.
• Como corolario (y este plaga mi trabajo todos los días), la pila Bluetooth LE difiere entre los teléfonos. El iPhone 5S no es lo mismo que el Samsung Galaxy S6 stack. Cada uno tiene sus defectos respectivos que debemos tratar. ¿Cómo diablos es posible que un híbrido adapte su código para implementar las soluciones deseadas para cada plataforma? ¡Eso ni siquiera es posible!
• Apoyo. La documentación puede ser suficientemente mala en las plataformas nativas. El soporte para BLE es inexistente. Nadie en StackOverflow tiene los problemas de software que tenemos que resolver. Nadie. Este es un territorio desconocido en algunos aspectos. Solo es sensato mantenernos lo más cerca posible de las API oficiales, para que podamos obtener, al menos, un poco de soporte de Google / Apple / Nordic. Usar un híbrido haría las cosas aún más difíciles.
• Como corolario, todas las bibliotecas de terceros que utilizo en el trabajo o para proyectos personales, como cifrado, gráficas, procesamiento de audio … ¿honestamente crees que existe un puerto Xamarin para todos esos? La mayoría de las dependencias solo están diseñadas para la plataforma nativa.

Claro, si todo lo que haces es escribir aplicaciones que no necesitan ninguna funcionalidad real de hardware / bajo nivel, entonces hazlo. Incluso entonces, su rendimiento se verá afectado, por lo que si planea realizar cualquier tipo de almacenamiento de datos significativo, procesamiento de números o multimedia, entonces olvídelo. Native es tu única opción.

Tenga en cuenta que las únicas razones para utilizar híbridos son el código base singular. Eso es. Piénsalo. Nadie que favorezca algo como Xamarin tiene otra razón para usarlo que no sea el código base singular. Nativo es mejor en cualquier otra forma.

Los defensores de los híbridos a menudo dicen tener solo un desarrollador en una plataforma, en lugar de dos equipos en dos plataformas, pero esto no es un problema falso. Estamos hablando de software de calidad aquí. Contrata a ingenieros nativos por separado o contrata a alguien como yo que pueda hacer ambas cosas y le paga mucho dinero. Si no puede permitirse el lujo de tener desarrolladores nativos, no inicie un negocio en el que se requieran compilaciones nativas.

Por cierto, no sé por qué mencionaste los idiomas en absoluto. Los desarrolladores actuales no se preocupan por los idiomas. El lenguaje es el menor de nuestros problemas. Tenemos que aprender nuestro dominio, aprender las API móviles gigantes y los conjuntos de herramientas complejas, y resolver problemas de software. El lenguaje es probablemente la parte menos importante de todo esto.

En general, su premisa es falsa. De hecho, es bastante risible. Si crees que puedes crear la misma aplicación utilizando un marco híbrido en lugar de compilaciones nativas, entonces estás muy equivocado.

Buena suerte desarrollando software de síntesis de audio usando Xamarin 😉

Answer 2

Porque no pueden.

No sé qué pruebas tiene de que Xamarin puede acelerar el desarrollo de aplicaciones móviles.

1-Aún necesitas desarrollar tu aplicación dos veces

Debe desarrollar su aplicación en la plataforma específica C #, una para iOS y otra para Android. Haciéndolo absolutamente inútil. Un buen ingeniero veloz y uno de Java serán igual de eficientes.

2-La comunidad es ridícula.

En comparación con Swift y Java, que tienen miles de marcos y son nuevos puestos en github cada mes.

No he visto nada nuevo sobre Xamarin en un año o eso creo.

3-La cantidad de ingenieros en el mercado es inexistente.

Encontrar un buen desarrollador móvil es difícil, encontrar un Xamarin es más difícil. La compañía necesita alta volatilidad, no un solo hombre para un solo trabajo, o 50 cazadores de cabezas para encontrar un solo hombre.

4-Tooling está roto

Espero que no estuvieras hablando de “Formas de Xamarin” que es el equivalente de “Formas de Visual Basic”. Está diseñado para el desarrollo rápido de aplicaciones y aplicaciones de negocios, no para redes sociales o plataformas.

Xamarins no hace que el desarrollo de aplicaciones sea más rápido o más simple.

En realidad es probable que sea lo contrario. [1] [2] [3]

Editar:

No sé dónde leyó Ivan Ičin que utilizo “opinión” en lugar de “hecho”, sabiendo que puse 3 enlaces para probar mis puntos.

Nunca dije que las “aplicaciones híbridas” son malas, Xamarin no es híbrido .

Fortune 500 compró Xamarin porque tenían el ecosistema de Windows, las bibliotecas de C # y Engineers.Back End se pueden compartir en diferentes idiomas y no tienen nada que ver con eso.

Sorprende cómo las personas pueden ser activadas e inventar cosas cuando una respuesta no complace su visión .

Notas al pie

[1] Algunos pensamientos después de (casi) un año de uso real de Xamarin

[2] Lo bueno y lo malo de Xamarin Mobile Development

[3] Simplemente, la peor experiencia de desarrollo que he tenido …

Answer 3

Suspiro. Xamarin tiene algunos méritos. Pero NO es un reemplazo para el desarrollo de aplicaciones nativas.

Android y iOS tienen diferentes convenciones de UI / UX, todavía debes cumplir con eso o tu aplicación se verá mal.

Xamarin tiene limitaciones en SDK también. Puede “pasar a ser nativo” y superar eso, pero luego está haciendo un trabajo adicional para integrarse en Xamarin, lo que ya existe en el entorno nativo.

Xamarin necesariamente se queda atrás del nativo. Primero, la plataforma (iOS o Android) introduce algo, luego Xamarin tiene que adoptarlo.

Xamarin es un “denominador común” de los dos sistemas. Esto significa que las características comunes pueden estar allí, pero las características específicas de la plataforma son MUCHO más difíciles y generalmente requieren código nativo.

Las aplicaciones más grandes y complejas a menudo requerirán aplicaciones nativas, ya que son más específicas del dispositivo y requieren más rendimiento.

El entorno de compilación debe utilizar tanto el Xamarin como el nativo, se vuelve más complejo.

No es la misma aplicación, no para nada más que aplicaciones relativamente simples.

Answer 4

De Verdad? Entonces, ¿qué hay de usar Delphi en lugar de C #? Delphi es un producto que cuenta con más de 2 décadas de experiencia en la plataforma Windows y se originó como Turbo Pascal en algún lugar alrededor de 1982. Puede usar Delphi para crear aplicaciones para Windows, Linux, MacOS, iOS y Android con una herramienta RAD con décadas de experiencia detrás de diseño.

O bien, ¿por qué no usar C ++ en su lugar, ya que C ++ se compila para casi cualquier plataforma, incluidas las que no admiten Xamarin?

El hecho es que las personas usan las herramientas que mejor se adaptan a los problemas que necesitan resolver. No hay balas de plata que puedan resolver todos y cada uno de los problemas. Xamarin es una buena herramienta y me gusta usarla, pero está lejos de ser perfecta. Siempre está detrás de los últimos desarrollos en las plataformas Android e iOS y el uso de bibliotecas nativas de esas plataformas es un poco difícil de emular en un lenguaje de programación diferente.

Si elige un lenguaje de programación para resolver todos sus desafíos de programación, descubrirá que está intentando colocar regularmente una clavija cuadrada dentro de un agujero redondo. Puede que no se ajuste o deja demasiado espacio que aún debe completarse. Con Xamarin, tiene el mismo problema.

Entonces, a veces Swift o Java es mejor. Y ocasionalmente, C ++ es incluso mejor que todos los demás. En otros casos, Xamarin podría ayudar. O Delphi. O una de las muchas otras herramientas de programación que existen para todas estas plataformas.

La herramienta debe coincidir con el problema, no al revés …

Answer 5

Pensé en no responder, pero Quentin Homareau me hizo responder porque su respuesta fue parcialmente correcta, pero usando un lenguaje tal que no quiere entregar ningún hecho sino una opinión.

Así que para decir dónde tiene razón, se pueden hacer grandes ahorros solo con Xamarin.Forms, y sus casos de uso son bastante limitados y pueden limitar seriamente la utilidad de algunas aplicaciones (que si desea compensar puede llevar a un trabajo adicional aún mayor que ahorros).

Lo que claramente no quiere decir (aunque estoy bastante seguro de que lo sabe) es que Xamarin.iOS y Xamarin.Android aún pueden generar ahorros significativos al tiempo que mantienen la calidad de la aplicación. Puede mantener el backend común y debería reducir el tiempo del proyecto entre un 20 y un 30% (edición: después de que Quentin Homareau editó su respuesta, supongo que podría no ser consciente de esto, ya que dice que lo mismo puede hacerse en aplicaciones nativas, y no no puede: el código de backend no es un código de servidor en este caso, pero la lógica de la aplicación no está conectada directamente a la IU y se puede compartir (como escribir en el disco, la base de datos, la configuración, etc.).

No quiero poner mi experiencia más allá de la suya, pero seamos sinceros: a Xamarin se le cobraron 1000 $ al año y se los han ganado vendiendo a grandes compañías, muchas de las compañías Fortune 500 son sus usuarios. Si quiere decir que no tienen conocimiento en este tema, probablemente debería considerar primero cuál es su nivel de conocimiento.

Creo que hay dos razones por las que las personas no usan Xamarin: racional e irracional.

La razón racional es que muchas empresas en realidad van primero a iOS, luego a Android, y es perfectamente normal. La mayoría de las aplicaciones no son rentables y reducir los costos es razonable: es probable que falle y desee reducir los costos de las fallas al no administrar el negocio a largo plazo, y Xamarin puede hacer eso.

La razón irracional es que se propaga ampliamente, como en esta respuesta, que las aplicaciones híbridas son malas y, como se dice con frecuencia, incluso en Xamarin. Las formas son malas en cierta medida. Como hay muchos casos que lo respaldarán, la gente no quiere probar Xamarin y arriesgarse.

Answer 6

Las plataformas cruzadas siempre se retrasarán después de las lenguas nativas, ya que dependen de ellas. Además de la apariencia de las plataformas cruzadas, por lo general no es lo mismo que las nativas.

Lo último no importa para los juegos que no tienen el aspecto y la apariencia, por lo que no tiene sentido utilizar una plataforma cruzada.

Answer 7

Justo aquí para recomendar la respuesta de Kevin Ossia.

Si quieres la mejor aplicación posible, necesitas ser nativo.

Answer 8

Religión.