Gracias por la A2A, Romain Barbey. He estado fuera del juego de iOS por un tiempo, pero dudo que las cosas hayan cambiado radicalmente desde entonces. Aquí están mis conclusiones después de haber trabajado en proyectos de iOS y Android (a menudo para la misma aplicación).
Experiencia de desarrollo
Hemos visto cientos de aplicaciones multiplataforma que funcionan perfectamente tanto en iOS como en Android. Para la mayoría de los desarrolladores, la paridad de la plataforma les permite proporcionar la misma experiencia a todos los usuarios.
- ¿El desarrollo multiplataforma se hará cargo del desarrollo nativo en los próximos años?
- ¿Necesitas ser un experto para hacer una aplicación?
- ¿Cuáles son las herramientas de integración continua para el desarrollo móvil utilizadas por las principales compañías de telefonía móvil?
- ¿Qué son las pruebas móviles?
- ¿Cómo se puede usar una aplicación móvil para administrar el proceso de lavado?
Existen excepciones para fines de investigación y otros subgéneros gracias a la naturaleza más “abierta” de Android. Pero en su mayor parte, ambas plataformas satisfacen bien las necesidades del usuario.
En el lado del desarrollo, la historia es un poco diferente. En iOS, puede llegar a un MVP antes de lo que puede hacerlo con Android. Desafortunadamente, las razones para esto son abundantes, dolorosas y algunas palabras clave.
– ¿Qué hay de puntero?
Los NPE, o excepciones de puntero nulo , son los precursores de las terribles horas de codificación que siguen. Si no está familiarizado con los NPE, el tiempo de ejecución de Java los arroja cada vez que su código intenta acceder a objetos que no existen.
Los NPE representan la mayoría de los bloqueos que surgen durante el desarrollo de Android. Bloquean su aplicación y requieren que detenga lo que está haciendo y que los arregle antes de continuar con un trabajo más importante.
Si bien algunos NPE son soluciones de una línea, otros son terriblemente difíciles de rastrear. Después de cientos de horas de desarrollo, MyKeypad aún lanzó un NPE sobre el mismo objeto aproximadamente una vez al año, como un trozo de carbón en nuestro stock de Navidad de informe de accidente.
Y cada año, fallamos en encontrar una solución. En cambio, acabamos de pegar este bloque de código en un lugar completamente nuevo:
if (dontBeNullYouBastard == null) {
log.e ("MyKeypad", "¡Oh, maldita sea!");
regreso;
}
Lo has adivinado, eso no fue una solución. Este código simplemente evitó que el diálogo de bloqueo apareciera en la pantalla del usuario. Y eso significaba que el usuario podía seguir creyendo en cosas tontas como que nuestra aplicación no era una basura completa, que existía el hada de los dientes y que su casa de verano era una gran inversión.
Pero en iOS, las cosas eran diferentes. Objective-C eliminó los NPE. Técnicamente todavía los tenía, pero no bloquearon la aplicación. De hecho, si invocó un método en un objeto faltante, obtendría un resultado vacío basado en el tipo de valor de retorno que esperaba su código.
Por ejemplo, imagine que invocó: (BOOL) es Válido en un objeto que no existía. En lugar de una excepción, obtendría NO como resultado, un tipo BOOL válido. Y si la idea de los objetos fantasmas que devuelven valores más allá de la tumba te asusta, debería.
Este comportamiento dificulta determinar la ubicación y la causa de las pérdidas de memoria. Así que las compensaciones aquí son claras: Java castiga sus errores con demoras en el desarrollo y fallas frecuentes en Android.
Mientras que iOS los supera para mantener una mejor experiencia de usuario (incluso si la aplicación comienza a comportarse mal, Apple lo ve como una mejora en lugar de fallar). Pero ese comportamiento hace que sea difícil rastrear errores. Afortunadamente, eso no sucede con tanta frecuencia en iOS …
– Asignación de recursos
La forma en que las plataformas asignan recursos sigue siendo la diferencia más fundamental entre los dos. Los cambios se han reducido con las recientes iteraciones de iOS, pero en principio son fuertes contrastes entre sí.
En iOS, la aplicación orientada al usuario domina los recursos del dispositivo. Y cuando el usuario cambia las tareas, el sistema operativo cierra la aplicación por completo (con algunas excepciones) para dejar espacio para la siguiente.
Por el contrario, en Android, la aplicación orientada al usuario comparte recursos con todas las aplicaciones en segundo plano que se ejecutan simultáneamente. Y el sistema operativo Android no impedirá que una aplicación se ejecute en segundo plano a menos que los recursos alcancen una sequía crítica o el usuario haya restringido el procesamiento en segundo plano para esa aplicación.
Por defecto, las aplicaciones de Android tienen permiso para hacer lo que quieran a todas horas del día. Incluso cuando no está en uso, Instagram puede acceder a su micrófono y escuchar sus conversaciones para mostrarle anuncios dirigidos. ¿Suena paranoico? Puede ser, aunque he experimentado algo así y, al menos, soy cauteloso al otorgar acceso de micrófono a cualquier aplicación.
Pero, ¿cómo afecta esto al desarrollo? Dado que iOS proporciona recursos tan abundantes para su aplicación, su poder se siente ilimitado. ¿A quién le importan las pérdidas de memoria cuando obtienes un gigabyte para ti o más?
Y lo que es más importante aún, su aplicación iOS puede manejar la CPU por sí sola; eso es como aparecer en Disney Land y no hay colas, todo es gratis y sorprende que seas Walt Disney. Puede agradecer a este patrón por ofrecer la notable diferencia de rendimiento entre dispositivos iOS y Android.
Sin embargo, de vuelta en And-land, debemos monitorear la actividad de nuestra aplicación con un ojo crítico de Sauron que todo lo ve. Incluso en dispositivos de gama alta, seguimos compartiendo nuestro valioso tiempo de CPU con aplicaciones molestas en segundo plano. En los dispositivos de bajo presupuesto, tenemos la suerte de ejecutar a 30 FPS.
Esto se traduce en más trabajo para el desarrollador de Android que quiere crear una gran aplicación. Encontré esta dicotomía de primera mano cuando cambié del equipo de Android al equipo de iOS en Words With Friends . En iOS, WwF era un maldito monstruo de proporciones bíblicas.
¿Pérdidas de memoria? No, más como inundaciones de memoria del tamaño de Noah que podrían hundir el Arca, el Titanic y la carrera de Beyonce. Incluso durante el uso de prueba, WwF iOS consumió cientos de megabytes de RAM mientras realizaba sentadillas de poca calidad.
Y en el miserable lado de Android, la aplicación arrojaba errores de falta de memoria … a 25 MB. Puedes imaginar cómo esto impactó el desarrollo. Android nos requirió codificar cuidadosamente y limpiar después de nosotros mismos.
Eso significaba que pasábamos más tiempo (piense días, incluso semanas) optimizando y caminando sobre cáscaras de huevo mientras los desarrolladores de iOS arrasaban las calles y asesinaban bebés sin reprensión. A la larga, el enfoque de Android parece correcto, pero el enfoque de iOS gana.
iOS gana porque los desarrolladores pueden moverse más rápido y romper menos cosas. iOS también gana porque el usuario es el rey, y la experiencia en iOS sigue siendo difícil de superar para los dispositivos Android. Finalmente, con la línea Pixel de Google, existe un teléfono cuya latencia podemos comparar directamente con un iPhone de primera línea sin que nos saquen de la sala.
Herramientas
Por último, voy a hablar sobre herramientas. Xcode es un IDE desarrollado por Apple, una compañía que ha diseñado el bombeo a través de las venas de todo lo que construye. A veces es un mal diseño, pero no obstante, se lo considera en gran medida.
Luego tienes Android Studio, el spin-off de Google del Intellij IDE. Entonces, es una herramienta hecha originalmente por nerds, luego bifurcada por los nerds más nerd del planeta, para ayudar a otros nerds a hacer cosas nerd más rápido. Es nirvana, pero para nerds. Nerdvana Ahí lo dije.
Perfilador de memoria de Xcode.
Rastreador de asignación de DDMS de Android … Sí
Podría perdonar a Android Studio por mucho … si fuera rápido. Google lo ha optimizado con cada iteración, pero el rendimiento no puede mantener una vela a Xcode. Las compilaciones de Xcode son, en promedio, mucho más rápidas que las de Gradle (sistema de compilación de Android Studio).
La velocidad de compilación es crítica porque representa cuánto tiempo espera después de hacer clic en “Ejecutar” hasta que la aplicación se inicia en su dispositivo o simulador. Cuanto más tiempo transcurra, más lento será el proceso de desarrollo. Para iOS, mis aplicaciones se iniciaron en segundos en mi simulador. Compare eso con Android, donde estaba acostumbrado a esperar minutos.
Cuando vi lo rápido que Xcode lanzó una aplicación en mi MacBook, me eché a llorar. Aunque recientemente supe que puedes realizar muchos ajustes para acelerar las compilaciones de Gradle para Android. Pero estos ajustes no son intuitivos y tienes que buscar en la documentación para descubrirlos. Si no eres tan inteligente, obtén un buen crucigrama para trabajar mientras esperas a que se desarrollen tus aplicaciones.
Hablando de compilaciones, hablemos de simuladores. Android proporciona emuladores , que son básicamente máquinas virtuales que imitan la arquitectura de un dispositivo dentro de su computadora. En cambio, Apple proporciona un simulador de software, donde usan código para imitar el comportamiento de iOS dentro de macOS. Puede que no lo sepas, así que te contaré el secreto: los simuladores son mucho más rápidos que los emuladores.
Sin embargo, los emuladores proporcionan una predicción mucho más precisa de cómo se comportará su aplicación en un escenario del mundo real. Parece que estamos golpeando los mismos ritmos nuevamente aquí: Apple se enfoca en la velocidad y Google se enfoca en la propiedad.
Sí, los emuladores proporcionan una forma adecuada de realizar pruebas sin un dispositivo disponible. Pero también tardan mucho tiempo en iniciarse, consumen una tonelada de recursos y corren más lentamente que un perezoso en Xanax. Con Apple, su simulador se inicia instantáneamente, incluso en las viejas MacBooks, y funciona tan rápido como su computadora puede soportar, a menudo a velocidades que exceden el rendimiento real del dispositivo.
¿Quién es el ganador aquí? De nuevo, es probable que sea iOS porque Apple se ha esforzado mucho para reducir el ciclo de desarrollo. Desarrolle más rápido, pruebe más rápido y libere más rápido en iOS. Hablando de liberación …
Experiencia editorial
Es hora de darle algunos puntos a Android. El proceso de publicación de la App Store de Apple es infame. Es posible que haya escuchado sobre los largos tiempos de espera para que el personal de control de calidad de Apple revise su aplicación antes de que pueda lanzarla oficialmente, pero la miseria comienza mucho antes.
– Certificados
Cuando te registras como desarrollador de Apple App Store, debes pasar por el proceso de generación de certificados. Estos certificados lo califican para trabajar en aplicaciones iOS, punto. Ni siquiera puede comenzar a probar su aplicación en dispositivos sin estos certificados.
Bien, ese no es un gran aro para saltar, tienes razón. Simplemente regístrese, descargue el certificado, cárguelo en su almacén de claves, luego boom, Xcode lo encuentra y todos estamos contentos, ¿verdad? Incorrecto.
Cuando me añadieron al equipo de iOS para Words with Friends , consumí uno de los 50 espacios limitados para desarrolladores asignados a nuestra cuenta (a menos que quisiéramos pagar muchísimo más efectivo a Apple). Lo peor es que al agregar un nuevo desarrollador, invalidamos el certificado existente .
Eso significaba que todos en mi equipo tenían que volver al portal del desarrollador y descargar el nuevo certificado antes de poder continuar trabajando. Eso es algo real que sucedió de verdad. Y podría suceder 49 veces.
En Android, tal cosa no existe. Pagas $ 25 una vez y tu cuenta está viva para siempre. Cualquier número de personas puede trabajar en su aplicación porque Android Studio es completamente de código abierto y la única protección de su aplicación es su archivo de almacén de claves (que puede entregar como mejor le parezca).
A nadie le gusta lidiar con los certificados de Apple, pero lo soportaron porque Apple.
– App Store vs Play Store
Para obtener su aplicación en la App Store, debe saltar a través de aros adicionales. La configuración bancaria es extraña. Y tiene que completar y firmar digitalmente un montón de acuerdos EULA y ToS y Dios sabe qué más. En poco tiempo te tienen tan legalmente FUBAR’d que un genio en Apple tiene poder sobre tus riñones.
En Google Play, agrega algunas capturas de pantalla, algunas ilustraciones promocionales y, en pocas horas, su aplicación está activa. No hay mucho más que decir aquí, simplemente funciona y lleva poco o nada de tiempo. Y la ventaja adicional aquí es que para Android, existen mercados alternativos de aplicaciones.
Puede publicar prácticamente la misma aplicación en la tienda de aplicaciones de Amazon y docenas de otras para maximizar su alcance. Con Apple, estás atrapado luchando con millones de aplicaciones en la App Store. Buena suerte con eso.
Conclusión
Esto puede haber parecido un festival de volcado en Google, pero desarrollar para Android sigue siendo divertido, desafiante y gratificante.
Lo mismo puede decirse de iOS. Pero la conclusión es que, si la velocidad es importante para usted (velocidad en el desarrollo, las pruebas y el rendimiento de la aplicación) y usted es un principiante, iOS es absolutamente la mejor opción.
Respuestas relacionadas:
- ¿Por qué debería uno aprender el desarrollo de Android en 2016?
- ¿Cuáles son los requisitos básicos para un desarrollador de Android?
- y ¿Cuáles son las cosas más difíciles sobre la transición del desarrollo web al desarrollo móvil?
Si consideró que esta respuesta es valiosa, vote por ella o Apple revocará mi certificado de desarrollador.
Además, parece que su feed podría usar respuestas más divertidas. Entonces, ¿por qué no me sigues ? Ni siquiera cuesta $ 25 y lo aprobaré de inmediato.
