Déjame compartir algo contigo. Me gusta la idea del desarrollo multiplataforma. La capacidad de utilizar un conjunto de herramientas para todas mis tareas es un sueño. ¿Quién no querría usar solo una herramienta para completar con éxito sus tareas? Escribir una vez, correr a todas partes? Yo quiero!
También me gusta la idea de una sociedad utópica. Una sociedad donde todos respetan las creencias de los demás, tiene argumentos significativos / lógicos / razonables y establece la tarea de ser mejor de lo que eran ayer. Sin embargo, el mundo real rara vez es tan perfecto.
Quiero admitir que siempre he querido discutir la disputa entre el desarrollo de aplicaciones nativas, multiplataforma e híbridas. No por falta de motivación, sino por la esperanza o el deseo de que algún día aparezca un conjunto combinado de herramientas que abra las puertas y brinde el mejor valor para crear aplicaciones móviles. Todavía estoy esperando este día, y este artículo debería ayudar a explicar mi apego al desarrollo nativo.
¿Nativo, multiplataforma, híbrido? Que?
Podría dar más detalles sobre las diferencias de cada tipo de desarrollo, pero dado que las comparaciones entre ellos se pueden hacer durante mucho tiempo, intentaré acortar esta parte.
Desarrollo nativo
En el desarrollo nativo, utilizamos herramientas especializadas para crear aplicaciones para iOS o Android. Es decir, hay una base de código para cada plataforma. Los kits de herramientas generalmente incluyen Swift / Objective-C + Xcode / AppCode para iOS y Kotlin / Java + Android Studio para Android.
Desarrollo multiplataforma
Utilizamos una plataforma / herramienta que traduce / compila / ejecuta su código como si fueran componentes nativos. El proceso difiere según las herramientas que use, pero el resultado final es que se ejecuta el mismo código y funciona casi igual en las plataformas Android e iOS.
Algunos ejemplos de herramientas: Xamarin, React Native, Flutter
Desarrollo híbrido
En el desarrollo híbrido, utilizamos una plataforma / herramienta que lanza un WebView, que luego aloja su aplicación. Básicamente, esto significa que su aplicación es un sitio web que se ejecuta desde su propia aplicación. Una plataforma / herramienta generalmente también proporciona acceso a sus propias funciones, como una cámara, a través de complementos.
Ejemplos de instrumentos: Cordova y Ionic
Características primarias vs esenciales
Para comprender correctamente mi elección, necesito explicar dos tipos diferentes de características de la herramienta.
Durante muchos años, se ha debatido sobre por qué una herramienta es mejor que otra. La mayoría de los artículos discuten características obvias de la herramienta, como el tamaño de la base de código, el tiempo de desarrollo, la cantidad de plataformas para las que puede desarrollar aplicaciones, etc. A estas comparaciones, me gusta llamar las "características principales" de cada caja de herramientas. Las características principales de la herramienta son las más directas para compararlas con otras herramientas, ya que generalmente puede ver las diferencias empíricamente (es decir, velocidades de desarrollo, tiempo de construcción, etc.). Estas características suelen ser motivo de preocupación para la mayoría de las personas, pero no revelan la esencia.
Para comprender completamente las consecuencias de elegir una herramienta, debe considerar las "características inherentes". Estas características son generalmente más sutiles y su impacto es más difícil de evaluar que las características principales. Desafortunadamente, la comprensión de la influencia de estas características generalmente ocurre solo después de que se selecciona una herramienta y se invierten grandes fondos en ella. Estas características son la integridad y claridad de la documentación, la disponibilidad de herramientas convenientes, etc.
Tomar la decisión correcta sobre una herramienta de desarrollo requiere una comprensión de sus características inherentes.
¿Por qué elijo desarrollo nativo?
A lo largo de los años de desarrollo de software, he tenido la oportunidad de utilizar varias herramientas para diferentes proyectos. Por lo general, la elección de las herramientas de desarrollo fue hecha por un ingeniero técnico o administrativo. Tan pronto como me cambié a freelance, decidí decidir sobre la pila tecnológica.
Al final, mi decisión final se redujo a considerar no solo los factores de las herramientas, sino también cómo las características inherentes afectarán a cada uno de mis proyectos en diferentes situaciones a lo largo del tiempo y aquí están mis conclusiones.
1. Popularidad constante
Cuando comencé a programar en 2013, había muchas voces exageradas como Cordova y Appcelerator. Unos años más tarde, Hype se cambió a Xamarin. Unos años más tarde ya era React Native. Ahora? Flutter está ganando popularidad.
He descubierto que la popularidad de la herramienta también representa el soporte que recibe. Si la herramienta pertenece a una empresa privada, la popularidad se equipara con las ventas, lo que lleva a un aumento en los costos de soporte. Si la herramienta es de código abierto, la popularidad depende de cuántos desarrolladores activos mejoren la base de código. La popularidad puede ir y venir e influir en todo el ecosistema de desarrollo en torno a esta herramienta.
Eche un vistazo a este gráfico de Tendencias de Google, que muestra varias herramientas multiplataforma a lo largo del tiempo.
El gráfico de Tendencias de Google muestra aproximadamente los resultados de la cantidad de consultas de búsqueda para varias tecnologías móviles multiplataforma.
Aunque este gráfico es una estimación aproximada de la popularidad (ya que solo representa los resultados del número de búsquedas), proporciona una idea de lo que experimenté como desarrollador. Las empresas y los individuos tienden a usar lo nuevo. Esto no significa necesariamente que la herramienta sea mejor o peor (ya que muchos artículos argumentarán a favor o en contra, independientemente de la fecha de lanzamiento), pero las personas siempre cambian a algo más nuevo.
Cuando se lanza una herramienta, generalmente es promovida por la comunidad de desarrollo y se ve como un "futuro". Esto puede hacer que las herramientas más antiguas tengan menos soporte y se atrofien lentamente con el tiempo.
Compare esto con el desarrollo nativo, que garantiza recibir soporte. Si bien Apple es compatible con iOS y Google es compatible con Android, el desarrollo nativo siempre será relevante. Es por eso que el desarrollo nativo tiene el ecosistema más grande de desarrolladores; solo duró más tiempo y fue consistente en su popularidad.
Otra consideración a realizar es la transferencia del proyecto. La probabilidad de que el próximo desarrollador tenga al menos algo de experiencia en el campo del desarrollo nativo es bastante alta. Incluso si no funcionan principalmente con herramientas nativas, la mayoría de los desarrolladores al menos de alguna manera se relacionan con estas herramientas, lo que es mucho menos probable con soluciones multiplataforma.
2. Valores comerciales / visión
Raramente escucho a muchas personas hablar sobre el valor comercial al comparar herramientas de desarrollo. Le pregunté a varios desarrolladores e incluso propietarios del negocio técnico sobre esto, y lo que recibí a menudo fue una mirada vacía. Es importante comprender cómo el valor comercial se correlaciona con una herramienta en particular y cómo puede proporcionar ese valor.
Por ejemplo, tome Xamarin. En febrero de 2016, Microsoft compró Xamarin por alrededor de $ 400-500 millones. En ese momento, la visión de Microsoft estaba relacionada principalmente con el desarrollo de aplicaciones móviles. Hicieron un progreso significativo con esta herramienta e incluso la incluyeron como un complemento listo para usar para Visual Studio y Visual Studio para Mac. Avancemos unos años, y la visión de Microsoft se ha desplazado a la inteligencia artificial.
A lo largo de este cambio de visión, trabajé en un proyecto con Xamarin. Durante este tiempo, me familiaricé con una plataforma con la que tuve que cambiar de un conjunto estable de herramientas a una que se degrada lentamente. Cada actualización de la herramienta parecía un intento, al menos para no romper nada. En el mejor de los casos, todo funcionó como debería. En el peor de los casos, pasó horas o incluso un día o dos retrocediendo actualizaciones e intentando que su entorno volviera a un estado saludable.
Esta lenta degradación no está documentada en la página de inicio de Xamarin (lo cual es comprensible), pero si busca información en los foros, puede sentir que algo ha cambiado con el tiempo. Los mensajes sobre cosas que solían funcionar fuera de la caja ahora simplemente no funcionan, o sobre cómo ha cambiado la experiencia del desarrollador con esta herramienta. Todo esto afecta directamente el costo de desarrollo, no solo por las horas brutas, sino también por la calidad del código.
Lapeado durante la transición a una nueva herramienta conduce a un aumento en los costos generales y la pérdida de ganancias
Admito que el desarrollo nativo también tiene sus problemas aquí. Por ejemplo, Apple generalmente intenta que los desarrolladores se desarrollen de cierta manera (por ejemplo, usando Storybords o la plantilla MVC). El kit de herramientas tampoco siempre es perfecto, por lo que en realidad uso AppCode para la mayor parte de mi desarrollo de iOS. Sin embargo, tanto Apple como Google gastan una gran cantidad de tiempo y dinero para garantizar que los desarrolladores se sientan cómodos desarrollando soluciones nativas. Solo mire Android Jetpack, SwiftUI, o incluso actualice a Kotlin y Swift.
En última instancia, Google o Apple no tienen la mejor visión del mundo, pero son consistentes. Hay una probabilidad mínima de que las empresas de la noche a la mañana se nieguen a apoyar sus herramientas.
3. Ahorro de tiempo
Oh si, ahorrando tiempo. El santo grial de la efectividad del desarrollo. Este tema muy debatido sobre CUALQUIER herramienta de desarrollo puede crear o destruir un negocio. Este tema está a la vanguardia de cualquier proyecto, ya que afecta directamente el costo. Pero demos un paso atrás y hagámonos una pregunta.
¿Qué podemos hacer para ahorrar tiempo?
Te lo explicaré. Al igual que con el software empresarial, generalmente hay varias formas de resolver un problema. La decisión proviene principalmente de la situación de una persona o empresa en particular. Esto significa que el enfoque de "una solución para todos" es peligroso; también se acerca mucho a la mentalidad de "siempre lo hicimos". Desafortunadamente, cuando se trata del desarrollo móvil, un enfoque común para ahorrar tiempo es elegir una herramienta multiplataforma. ¿Pero es tan bueno? ¿Podemos, por ejemplo, encontrar otro método para resolver el problema? En los negocios, hay un dicho "Las personas están por encima de los procesos, por encima de las herramientas".
Personas por encima de procesos, por encima de herramientas
Esto es exactamente lo que debe considerarse al tomar una decisión. ¿Cómo funciona el tiempo de desarrollo entre elegir una herramienta y crear procesos / procedimientos o incluso crear un enfoque diferente para el desarrollo?
¿Una herramienta capaz de resolver una mala mentalidad durante el desarrollo?
¿La herramienta agiliza el proceso de desarrollo?
¿Puede un proceso o mentalidad ligeramente modificado conducir a mejores resultados que ahorren tiempo?
¿Podemos usar la infraestructura para resolver nuestros problemas?
Todas estas son preguntas correctas que también muestran la complejidad de la solución. No es tan simple como elegir el próximo marco multiplataforma en lugar del desarrollo nativo. ¿Qué es lo correcto para usted o su negocio? Solo tú puedes hacer esta elección.
Dado que el desarrollo nativo producirá un producto de mayor calidad de forma predeterminada y será compatible casi hasta el infinito, elegiré este conjunto de herramientas. Mis valores personales determinan esta elección (luchar por la excelencia). El desarrollo propio realmente lleva más tiempo (cuánto más varía). ¿Hay alguna manera de ahorrar tiempo? ¿Debo ahorrar tiempo? ¿Debo buscar proyectos donde el presupuesto no es un problema?
Una forma de resolver el problema de ahorrar tiempo es crear código que pueda reutilizarse. Cree código reutilizable de alta calidad que pueda integrarse e implementarse rápidamente en múltiples proyectos. Como elegí un kit de herramientas para mayor durabilidad, puedo estar seguro de que mi código reutilizable será utilizable durante algún tiempo.
4. Otras inferencias
Finalmente, saqué muchas otras conclusiones antes de elegir un desarrollo nativo. Muchas de las cuales he hecho en toda mi carrera, probando varias herramientas, procesos y enfoques. Una descripción de todo esto haría que este artículo sea increíblemente voluminoso. Por lo tanto, por brevedad, daré tesis de algunos de ellos.
Cosas que consideré antes de elegir un desarrollo nativo:
1. Tiempo para el desarrollador de incorporación
2. Infraestructura de apoyo
3. Tuberías CI / CD
4. El costo de apoyar proyectos heredados
5. Capas de abstracción = más margen de error
6. Disponibilidad de desarrolladores (número de desarrolladores que usan la herramienta especificada)
7. Jerarquía empresarial (Airbnb tiene una gran serie de blogs que trata este tema)
8. Dependencia de la plataforma en complementos
9. Felicidad del desarrollador al usar la herramienta
10. Costos de diseño: la necesidad de diseñar de tal manera que sea compatible con ambas plataformas
11. Estructura personalizada del proyecto
12. Recursos de conocimiento: la cantidad de áreas de conocimiento necesarias (por ejemplo, Xamarin requiere: + Plataforma Xamarin Api, C #, funcionalidad específica de Android, funcionalidad específica de iOS y conocimiento de las características de cada plataforma y cómo interactúan a través de Xamarin).
13. Licencia + costo
14. El panorama de los sistemas operativos móviles. Por ejemplo: ¿cuánto durarán solo 2 plataformas principales?
Conclusiones
En los últimos 2 años, ha estado utilizando el desarrollo móvil nativo como su conjunto principal de herramientas. Una de las muchas razones por las que estoy contento con mi decisión es que me tomé el tiempo para considerar tantas sutilezas como sea posible para cada herramienta. Conozco los pros y los contras, y me da ventajas.
Espero que este artículo te ayude a hacer las preguntas correctas al elegir una herramienta. No tome el marketing al pie de la letra y, POR FAVOR, no siga el bombo publicitario. Excavar, ensuciarse y pensar críticamente.