Versión corta: Porque desarrollar para Android es una mierda. Hace poco implementé una función en una aplicación tanto para iOS como para Android. En iOS, me llevó 23 líneas de código y unos pocos minutos. En Android, me llevó 567 líneas de código y 3 días.
Versión larga: En primer lugar, déjame decir que las otras respuestas que hablan de lo poco que se gana en Android son al menos parcialmente ciertas, pero (para mí personalmente) no es tan grave como lo pintan. Yo hago una cantidad no trivial de dinero con mis aplicaciones para Android, pero hago más del doble con mis aplicaciones para iOS.
Pero yendo al punto principal… Android apesta. Sé que esto suena como un argumento religioso, pero tened paciencia conmigo.
Para ser claros, como usuario de Android, probablemente nunca experimentarás nada que te haga pensar que Android apesta. Sin embargo, ser un desarrollador de Android es miserable porque el AndroidOS subyacente está generaciones detrás de iOS.
Apple trabaja diligentemente para hacer que iOS FUNCIONE muy bien Y se vea bien al mismo tiempo. Muchos de los trozos de caramelo visual que Apple incluye en iOS realmente ayudan a la usabilidad, no son sólo para mostrar. Comunican sutilmente la información al usuario para que éste entienda lo que está sucediendo y por qué están sucediendo las cosas.
Sin embargo, Google se centró principalmente en conseguir que los fundamentos de Android funcionaran porque valoraban la idea de la expresión individual de los desarrolladores, en contraposición a Apple, que quería que las aplicaciones tuvieran un aspecto y una sensación consistentes. (El problema es que la inmensa mayoría de los desarrolladores no están formados en usabilidad o diseño gráfico, por lo que sus aplicaciones tenían un aspecto tosco y funcionaban de forma tosca. En la época de Android 4.x, Google se dio cuenta de que tenía un problema real porque no había dos aplicaciones de Android que funcionaran de la misma manera porque cada desarrollador tenía un enfoque diferente. Empezaron a tratar de estandarizar la interfaz de usuario y pusieron a algunos de sus gráficos a tratar de hacer que los elementos visuales se vieran mejor. Pero aún así no era bueno.
Aquí hay un ejemplo concreto de la diferencia de esfuerzo desde la perspectiva del desarrollador. Tengo una función en una de mis aplicaciones para iOS y quería asegurarme de que esa función estuviera también en la versión para Android.
La función consiste en tocar+mantener pulsado un elemento de una lista/tabla y luego arrastrarlo hacia arriba o hacia abajo para reordenar los elementos de la tabla (arrastrar y soltar). En iOS, esto sólo me llevó 23 líneas de código porque esencialmente todo está ya incorporado en el sistema iOS subyacente. El objeto UITableView (las listas de desplazamiento que se ven en todas partes en iOS) ya sabe cómo responder a tap+hold y ya sabe cómo animar el movimiento de la fila a medida que se arrastra el dedo… y ya aplica una bonita sombra de caída mientras se arrastra la fila… y ya sabe cómo animar las otras filas de la tabla para que se aparten del camino a medida que se arrastra esta fila, etc. También tiene ganchos incorporados para que el sistema pueda preguntar a mi código: ¿Debe el usuario arrastrar esta fila? Puede el usuario soltar esta fila entre x e y? y me dirá El usuario acaba de arrastrar y soltar esta fila en esta nueva ubicación, lo que permite que mi código responda a ese evento.
Por eso mi código de iOS sólo tiene 23 líneas. Todo lo que tengo que hacer es escribir un código que diga qué filas son arrastrables y luego responder a que dejen caer la fila para que pueda actualizar los datos subyacentes. Implementé esta función en unos pocos minutos en iOS.
Pero Android no hace NADA de eso, por lo que mi código de Android tiene 567 líneas y me llevó 3 días conseguir que todo funcionara. Afortunadamente, en este caso particular, no tuve que escribir todo ese código yo mismo porque muchos otros desarrolladores de Android se habían quejado de la falta de esta característica increíblemente básica. En respuesta, Google había publicado un «código de ejemplo» que mostraba cómo crear manualmente una forma rudimentaria de arrastrar y soltar. Por supuesto, ese código estaba desactualizado porque estaba escrito para Android 4 y no funcionaba para Android 5, 6 o 7 (7.x es la versión actual en el momento de escribir este artículo).
Y su código de ejemplo no incluía ninguna función para comprobar si se debía permitir arrastrar ciertas filas de la lista/tabla. No incluía ninguna comprobación de si se debía permitir que una fila se dejara caer en una determinada ubicación. No incluía la capacidad de establecer un callback para que tu código pudiera responder a la reordenación. Tuve que tomar todo su código rudimentario y lleno de errores y tratar de mejorarlo para que hiciera algo más que la versión de jardín de infancia de la función.
Eso significó que pasé varios días para producir una función que ni siquiera funciona tan bien o se ve tan bien como la función que ya existe en iOS y me llevó sólo unos minutos. Tomé una captura de pantalla del código de ambas y las puse una al lado de la otra para poder usarla para explicar la diferencia. (Ver abajo. La captura de pantalla incluye los comentarios en el código, pero no conté los comentarios en mi recuento de líneas.)
Cada vez que tengo un cliente que quiere su aplicación tanto en iOS como en Android, les digo que la versión de Android tardará 4 veces más en producirse y sólo será un 80% tan buena. Cuando les doy el presupuesto, determino cuánto costará producir la aplicación para iOS y luego multiplico ese número por 2,5 para cubrir la versión para Android… lo que no paga -realmente- todo mi tiempo en la versión para Android, pero cobrar 4 veces la cantidad les parece ridículo porque no saben cómo es.
