¿De qué manera es más difícil desarrollar y programar en Android en comparación con los dispositivos iOS?

Creo que las razones probablemente dependen de la aplicación y el desarrollador. No puedo hablar con Angry Birds o Skype, pero desde mi propia experiencia, aquí hay algunas cosas que se destacaron:

  • Hasta la introducción del iPad y iPhone 4, solo tenía una configuración de hardware consistente. Android puede ofrecerle pantallas y capacidades de múltiples tamaños (por ejemplo, Droid vs Droid Eris) y eso hace que sea un poco más complicado escribir código adaptable para la interfaz de usuario.
  • Hablando de interfaz de usuario, nos costó mucho más con las herramientas de interfaz de usuario para Android que el Creador de interfaces de Apple. Para nuestra aplicación que tiene muchas pantallas, fue una gran cantidad de trabajo adicional poner en tratar de hacer que cada pantalla sea correcta.
  • Nuestras aplicaciones de iPhone salieron primero, por lo que nuestras decisiones de diseño se tomaron con un ojo optimizado hacia esa plataforma. Entonces, cuando migra, algunas de esas decisiones no eran ideales para Android y debe elegir entre cambiar la funcionalidad o asumir la carga de desarrollo adicional.

Los puntos de Sandy Khaund son ciertos, pero agregaría algunas cosas más:

  • Al programar, hay un ciclo simple: arreglas algo, construyes tu proyecto, lo ejecutas, encuentras algo que está mal y arreglas lo siguiente. El Simulador de iPhone en el que prueba sus aplicaciones carga una versión revisada de su aplicación mucho más rápido que el emulador de Android, para que pueda trabajar más rápidamente. Durante meses de desarrollo, la diferencia puede sumar, especialmente si las pausas del emulador de Android tienden a convertirse en pausas en Facebook.
  • La documentación de Apple es mejor para poner en marcha a los principiantes. La mayoría de los sistemas tienen “guías de programación”, libros de programación en miniatura que explican cómo usar ese sistema sin atascarse en los detalles. Los más largos, como el lenguaje de programación The Objective-C de longitud de libro, están realmente disponibles en el iBookstore.
  • Cocoa Touch está diseñado de tal manera que escribes muy poco código, excepto las cosas que son personalizadas para tu aplicación. Podrías escribir una aplicación simple de lista de tareas con un par de cientos de líneas de código, dos imágenes de casillas de verificación y dos íconos, y encajaría perfectamente. De hecho, si no hicieras ningún trabajo de diseño personalizado, se vería al igual que la libreta de direcciones. * Las API de Android no manejan casi todo el trabajo, y el aspecto predeterminado es bastante feo.
  • Apple proporciona excelentes herramientas para analizar el rendimiento de una aplicación: averiguar qué partes son lentas o utilizar muchos recursos para que pueda mejorarlas. Las herramientas de rendimiento de Android son más difíciles de usar y no revelan tanta información como la de Apple.
  • Los juegos tienen que ser ajustados para diferentes chips. No solo hay menos dispositivos iOS, sino que comparten chips comunes, básicamente hay un conjunto de agallas de dispositivos iOS cada año. Eso significa que los desarrolladores de juegos solo deben preocuparse por unos pocos dispositivos para llegar al 90% de los jugadores. Por el contrario, llegar a la mayoría de los dispositivos Android es muy difícil: cuando Angry Birds se lanzó por primera vez para Android, recibieron quejas de que no funcionaba en diecisiete modelos de teléfonos populares.
  • Los usuarios de iOS también actualizan su sistema operativo antes que los usuarios de Android. ** iOS 5 y Android 2.3 se ejecutan en aproximadamente el mismo porcentaje de dispositivos iPhone / Android, pero iOS 5 tiene dos meses y Android 2.3 tiene más de un año. Las nuevas versiones del sistema operativo traen herramientas que hacen que los programadores sean más productivos, y el soporte de múltiples versiones puede obligarlo a escribir soluciones alternativas para errores antiguos. Debido a que los usuarios de iOS están más actualizados, los desarrolladores de iOS pueden usar más de esas herramientas y evitar menos errores.

* Las aplicaciones de listas de tareas reales requieren más que eso porque tienen más funciones: se sincronizan a través de la red, crean automáticamente elementos en un horario, le permiten clasificar y organizar elementos de varias maneras, y hacer todo tipo de otras cosas ordenadas. Muchas de las aplicaciones también personalizan el aspecto para que sea más hermoso que una aplicación estándar de iOS. Pero en todos los casos, el código se está escribiendo para hacer cosas personalizadas para esa aplicación, no se trata solo de lograr cosas comunes.

** Esto no es porque los usuarios sean flojos o algo así. El problema son los fabricantes y los operadores: una vez que sale una nueva versión de Android, cada fabricante tiene que ajustarlo para cada modelo que venden, y luego cada operador tiene que aprobarlo. Muchos fabricantes simplemente no ofrecen actualizaciones para dispositivos antiguos, y algunos de ellos consideran un dispositivo “antiguo” después de seis meses. Por el contrario, Apple es la única compañía involucrada en el lanzamiento de una actualización de iOS, y tienen suficiente experiencia con su negocio de computadoras para darse cuenta de que realmente necesitan mantener actualizados los dispositivos antiguos.

Como desarrollador que ha desarrollado en ambas plataformas, yo diría que el desarrollo de Android es un PITA, en comparación con iOS. Aquí es por qué:

  • El IDE Xcode es mucho mejor que Eclipse + ADT. El último es un cerdo RAM, y también se bloquea con frecuencia; aunque las cosas deberían mejorar una vez que salga el estudio de Android.
  • El simulador / emulador. El simulador de Android no puede sostener una vela contra el simulador de iOS. El primero es lento, carece de características y es prácticamente inútil. Ningún desarrollador serio de Android querría usar el simulador, preferiría usar el dispositivo. Por otro lado, el simulador de iOS es rápido y fácil de usar. He desarrollado aplicaciones complejas completas en el simulador.
  • Rendimiento / depuración. Los depuradores en ambos son igualmente buenos, como lo es el análisis de código estático. El problema viene con la supervisión del rendimiento. Instruments para iOS es excelente para hacer perfiles de memoria / CPU / red; Las herramientas de Android DDMS son más o menos aquí.
  • Fragmentación. Esto crea problemas de dos maneras. Como otra publicación menciona, hay innumerables versiones de Android flotando, principalmente porque los fabricantes no actualizan todos sus teléfonos a la última versión. Por lo tanto, uno debe codificar a la defensiva para apuntar a todas estas versiones (errores Esp en versiones específicas que deben ser parcheados en el código de la aplicación). El otro problema es la personalización de los componentes principales del sistema operativo por parte de los OEM (Samsung, el OEM de Android más grande, es probablemente el peor culpable aquí). Esto a menudo resulta en algunos errores específicos del dispositivo maravillosamente difíciles de detectar; que de nuevo necesitan un parche de mono específico para el dispositivo. Todo esto significa que la sobrecarga de las pruebas también es mucho mayor, ya que debe realizar pruebas en varios dispositivos / resoluciones de pantalla / versiones del sistema operativo, etc.
  • El SDK Ambos están muy bien documentados. Android tiene un punto a favor aquí ya que el SDK principal también es de código abierto; así que obtienes mucha más visibilidad de lo que el código está haciendo realmente. Dicho esto, el SDK de Android tiene sus peculiaridades; especialmente alrededor de la IU. Pregúntele a cualquiera que haya intentado manejar una tarea en segundo plano (asynctask) con rotación de interfaz de usuario en Android, y obtendrá la respuesta sobre lo difícil que es hacer una tarea tan simple.
  • El tiempo de ejecución. iOS se ejecuta en un tiempo de ejecución Obj-C que utiliza el paso de mensajes. Si bien esto presenta demoras de aproximadamente 5 veces en comparación con el envío tradicional de vtable de estilo C ++, las flexibilidades que obtienes son enormes; esp wrt runtime dynamism (Lea sobre isa swizzling, método swizzling, clase de tiempo de ejecución posando para comprender lo que digo aquí). Las cosas cambiarán con rapidez ahora, pero el dinamismo de tiempo de ejecución de Obj-C fue tan bueno que no hubo necesidad de un marco AOP en absoluto. Las aplicaciones de Android (creadas con el SDK de Android) se ejecutan sobre la máquina virtual Dalvik. El rendimiento de esta VM es regular (aunque definitivamente ha mejorado mucho con los años, especialmente con la adición de JIT y mejoras en el compilador). Se espera que esto vuelva a cambiar con la introducción del tiempo de ejecución ART en Android L, que promete ser mucho más rápido. Sin embargo, el formato pequeño (código de bytes en el que se compilan las aplicaciones de Android) en sí tiene algunas limitaciones extrañas, como la aplicación puede tener solo un máximo de 65k métodos. Superarlos nuevamente requiere hacks sucios.
  • Corriendo en el fondo. iOS no permite que su aplicación se ejecute en segundo plano (excepto en algunos casos especiales; eso también en breves intervalos). Android permite que su aplicación se ejecute libremente en segundo plano. Esto es a la vez una bendición (puede hacer cosas como la sincronización de fondo para una aplicación de mensajería instantánea / correo electrónico fácilmente en Android) y una maldición (si no tiene cuidado con lo que está haciendo, puede agotar fácilmente la batería).