Dejando de lado los problemas de fragmentación, ¿qué separa el SDK de iOS del SDK de Android?

Ambos son SDK orientados a MVC, por lo tanto, si escribe código para uno, debería poder dibujar paralelos 1: 1 para los objetos que usará en el otro (iOS ViewControllers == Actividades de Android, etc.). Java y Objective-C, aunque sintácticamente diferentes, ambos surgieron de los esfuerzos para mejorar la orientación de los objetos en C (bueno, Java salió de mejorar C ++, que fue un esfuerzo para … sí). De hecho, algunos de los primeros desarrolladores de Java en Sun trabajaron en Objective-C con NextSTEP, por lo que se superponen características de lenguaje similares (protocolos ObjC == interfaces Java como alternativa a la herencia múltiple, mentalidad de todo-es-un-objeto, etc.).

La diferencia más notable entre el desarrollo de Android e iOS es cómo se construyen las interfaces, lo que se debe a la fragmentación del dispositivo.

La creación de la interfaz de Android es similar a HTML: esboza la estructura de una vista particular y mide elementos individuales en relación con los tamaños de visualización dinámicos. Es más literalmente como HTML en que estos se construyen a través de XML. Existen herramientas que le permiten hacer una construcción más gráfica, pero honestamente necesita comprender cómo los elementos de diseño subyacentes “fluyen” para crear buenas aplicaciones para dispositivos cruzados.

iOS, por otro lado, actualmente solo tiene dos resoluciones de dispositivo: 320 × 480 (y la escala Retina correspondiente) y 1024 × 786. Esto le permite posicionar elementos absolutamente, y también significa que las herramientas gráficas para construir diseños (Interface Builder) son mucho más útiles que cualquier herramienta de Android.

En mi experiencia, también puede crear vistas programáticamente mucho más fácilmente en iOS que en Android, que es lo que termina haciendo para la mayoría de las IU no triviales. Crear vistas en código en Android parece casi un ciudadano de segunda clase: casi todo lo que puede hacer mediante programación se puede hacer a través de XML, pero no al revés.

Por extensión, iOS también te permite hacer animaciones mucho más exactas y complejas en iOS que en Android. Es posible hacer cosas simples a elementos individuales en Android, como rotar, escalar y desvanecer, pero hacer cualquier cosa fuera de ciertos eventos codificados, como animar cambios de diseño completos, se vuelve un orden de magnitud más difícil. No ayuda el caso de Android de que las increíbles bibliotecas de animación y gráficos de Apple en iOS son las mismas que se han desarrollado y madurado durante la última década en OS X. Android 3.0 ha hecho algunas mejoras en esto, pero si está apuntando a En la mayoría de los dispositivos (2.1), eres un poco limitado.

Otras notas:

  • No hay un sentido definido de una “aplicación” en Android, ya que no se puede saber cuándo se inicia y cierra su “aplicación”. Solo puede detectar cuándo comienzan y finalizan los controladores individuales para su aplicación. Pero, de nuevo, esto significa que los controladores individuales también pueden ser invocados de forma remota por otras aplicaciones y procesos en segundo plano. En iOS, si desea abrir su aplicación directamente a una pantalla de “Mensajes”, se iniciará toda la aplicación y luego redirigirá a ese controlador. Entonces, suponiendo un buen diseño, puede hacer algunas cosas mágicas en Android, como abrir fácilmente una pantalla determinada en función de un tipo particular de notificación.
  • Puede ejecutar código arbitrario en segundo plano en Android, lo que no puede hacer / Apple no lo aprobará en iOS. Por lo tanto, puede abrir un hilo separado y mantenerlo funcionando incluso después de que la “aplicación” se haya cerrado, lo cual es bastante bueno. Pero hacer esto puede matar la vida útil de la batería y disminuir el rendimiento si no se hace de manera inteligente / responsable.
  • No hay sistema de notificaciones push en la mayoría de los dispositivos Android. Creo que Google agregó recientemente un sistema unificado en 2.2, pero si está ejecutando en dispositivos más antiguos, necesitará lanzar su propia encuesta o solución de inserción. Apple tiene una infraestructura completa de notificaciones push en la que puede integrarse sin preocuparse por los costos de rendimiento.
  • Múltiples opciones de idioma para Android. Dado que está en JVM (o Dalvik, más bien. No está 100% claro sobre cómo exactamente expresar eso), puede usar otros lenguajes JVM para escribir aplicaciones de Android: Scala, Clojure, JRuby, ¿qué tiene? Recientemente he usado Scala para escribir una gran aplicación de Android, y fue mucho más agradable que Java. Para iOS, puede usar C o C ++, pero si desea usar algo totalmente diferente, sus opciones son más limitadas / menos elegantemente integradas.

¡Espero que ayude! Agregaré más mientras pienso en ellos.

Clay trajo grandes puntos, lo único que me gustaría agregar es que copiar diseños anteriores en los que has trabajado con Android es más fácil (para mí de todos modos) que iOS. En iOS, tengo tendencia a usar el generador de interfaces, y no obtengo muchas reutilizaciones a menos que tenga que copiar todo el archivo .xib y eliminar todo lo que no quiero.

(Como NeXTSTEP y luego OS X), el sistema de clases y la API de iOS han estado en desarrollo durante más de 25 años. Esto da como resultado un nivel de madurez y pulido que los nuevos participantes tendrán dificultades para igualar, a menos que simplemente lo copien.