Seguimos la semana del WWDC 2015. Tras analizar ayer las novedades de Swift 2 y detallando algunos de sus cambios más importantes a nivel de especificación, toca el turno de echar un vistazo a Xcode 7, la nueva versión de la herramienta de desarrollo de Apple.
El nuevo Xcode 7, mucho más depurado e inteligente que la versión anterior, incluye sustanciales mejoras además de incluir de serie el citado Swift 2 y dar soporte a tres sistemas operativos: iOS, OS X y el nuevo watchOS. Además, ha incorporado sustanciales mejoras en los diferentes asistentes, editores, componentes e incorporado un analizador de la calidad del código dentro de Swift sumamente práctico.
Una de las temas más importantes a tener en cuenta es que Apple ha actualizado su propia SDK así como la especificación de Objective-C, para que toda ella trabaje más fluidamente con Swift. Esto nos da un visión clara de lo importante que es Swift para Apple.
Las novedades incorporadas pasan por incluir el concepto de los genéricos en Objective-C, consiguiendo un sistema de intercambio de tipos de datos mucho más fluido entre Swift y Objective-C, pudiéndose enviar directamente tipos de un lenguaje al otro de manera directa y evitando tener que convertir especificaciones o tipos de datos como se hacía hasta ahora. Objective-C también incorpora la posibilidad de indicar la posible nulabilidad de un dato para así trabajar mejor con las opcionales en Swift cuando usamos código de ambos lenguajes en nuestro proyecto.
El formato de playground ha sufrido también importantes mejoras, como la incorporación dentro de la vista previa de elementos o en elementos en línea de casi cualquier objeto que pongamos, incluyendo todo tipo de imágenes o incluso sprites de un juego en SpriteKit.
En cuanto al formato, Apple sabe que los playground son una herramienta de enseñanza única y a las ya conocidas últimas funciones incorporadas como el cálculo gráfico, documentación enriquecida o la incorporación de recursos y código auxiliar en carpetas separadas, que ya analizamos en su día, ahora incorpora también páginas. De esta forma, podemos crear tantas páginas dentro de un playground como queramos, dándole casi un formato de libro interactivo con código incorporado.
La integración de los frameworks para pruebas de prototipos tanto de apps como de juegos es completamente limpia y se eliminan absolutamente todos los errores extraños que teníamos cuando queríamos usar esta funcionalidad. Ahora todo forma parte de una correcta integración.
Una de las principales características es que el nuevo Xcode 7 transformará cualquier watch app actual, estructurada con la lógica de la app en el teléfono y la interfaz en el reloj, de forma que se ejecute completamente nativa en el reloj.
En caso de necesitar conexión de algún tipo, el propio Apple Watch gestionará las conexiones y configuración.
Una de las principales características del nuevo Xcode 7 es lo relacionado a la subida de las apps a la App Store. Apple presenta un nuevo concepto de «adelgazamiento» de apps basado en tres partes básicas: Bitcode, Slicing y On-Demand Resources.
Bitcode es un cambio importante del que ya hablamos aquí, a través de arquitectura ABI. Xcode 7 subirá a la App Store un binario compilado en Bitcode (un código intermedio) y una vez llega a Apple, serán ellos los que generen el binario para cada plataforma necesaria, presente o futura, sacando el máximo partido de nuevas posibles funciones de optimización de sistemas o nuevas posibles arquitecturas. Cuando Apple publique una nueva versión de iOS (por ejemplo) usando nuestro Bitcode se generará un nuevo binario basado en esta nueva versión y así obtener todas las bondades de las nuevas arquitecturas sin tener que subir actualización alguna a la App Store.
Slicing, también es una importante novedad. Como ahora no subimos el binario montado, sino el Bitcode con los recursos, si hemos usado correctamente la gestión de assets del sistema, estos se dividirán automáticamente. De esta forma, si nuestra app tiene incluidos los sets de gráficos como recursos @2x para el iPhone 6 y los @3x para el 6 Plus, cuando un usuario de iPhone 6 baje la app la App Store le enviará nuestra aplicación incluyendo única y exclusivamente los recursos @2x que corresponden a su dispositivo, no incluyendo el resto y consiguiendo que las apps ocupen mucho menos en los dispositivos sin que nosotros tengamos que hacer nada para ello. Es todo trabajo de Apple y nuestra única responsabilidad será usar los assets para organizar nuestros recursos gráficos.
De igual forma ocurre con las arquitecturas de forma que si tenemos un iPhone 5 nuestra app recibirá solo el binario de 32 bits, pero si tenemos un iPhone 6 recibirá el de 64, con el consiguiente ahorro de espacio que ello conlleva igualmente. De igual manera funciona en iPad y ya nunca más tendremos los sets de gráficos Retina en un iPad que no lo sea (y viceversa). La gestión es automática y hecha por Apple desde la App Store ya que ahora es Apple quien genera los binarios de las apps y no nosotros.
También podemos configurar nosotros mismos la disponibilidad de recursos estableciendo los criterios por los cuales serán seleccionables por uno u otro dispositivo en función del tipo del mismo e incluso por sus características, como la cantidad de memoria RAM o la versión de Metal soportada por el dispositivo.
Por último, On-Demand Resources, es el componente perfecto de Slicing. Es la posibilidad que nosotros mismos establezcamos una serie de criterios de descarga que hagan que nuestra app no tenga por qué bajarse completamente en primera instancia, si no que se baje por partes en función de qué partes vaya a usar un usuario.
Pensemos en una app de guía de viajes con varias ciudades europeas: ¿es necesario que se baje la información de todas las ciudades incluyendo fotos o vídeos? No. Podemos hacer que la app se baje con lo básico y que cuando la persona acceda a una ciudad en concreto, se descargue en ese momento el paquete de datos de dicha ciudad y se coloque correctamente en su lugar dentro del Bundle del sistema como si siempre hubiera estado ahí.
¿Un juego? Podemos descargar los primeros niveles y cuando el jugador vaya avanzando ir descargando los recursos y datos del resto de niveles, consiguiendo que las apps ocupen solo lo necesario en función de la progresión del usuario sin tener que descargarlas por completo.
El truco está en el uso de una serie de etiquetas a través de los assets del sistema, que podemos usar para incorporar cualquier tipo de fichero, no solo imágenes. Podemos crear estructuras de carpetas, de recursos por dispositivos, de datos de todo tipo… y a través de etiquetas marcar qué archivos formarán parte de cada uno de los paquetes de recursos bajo demanda. De esta forma, cuando lleguemos a la parte concreta haremos un proceso síncrono que pedirá a la App Store el resto de datos necesarios y estos se descargarán.
Estas nuevas funciones y pruebas están soportadas por TestFlight para poder hacer pruebas del mismo y su funcionamiento es tan fluido en todo el sistema, que no tendremos más que preocuparnos de pedir la descarga de los recursos apropiados en el momento justo, y trabajar directamente con ellos (como hemos comentado) como si ya formaron parte de la app desde el primer momento.
private var resourceRequest: NSBundleResourceRequest?
func cargarRecursos(recursos: [String]) {
let request = NSBundleResourceRequest(tags: recursos)
resourceRequest = request
request.beginAccessingResourcesWithCompletionHandler{error in
if error != nil {
println ("Datos cargados")
}
}
Pero no acaba ahí la cosa. Los recursos bajo demanda también permiten marcar un grupo de recursos como «ya utilizado». Esto significa que si nuestro conjunto de datos ya ha sido usado y puede convertirse en prescindible (recursos para un nivel de tutorial de un juego, datos de una guía de viaje que el usuario hace semanas que no usa, etc) podemos marcar estos datos como no utilizables.
func liberarRecursos(recursos: [String]) {
let request = NSBundleResourceRequest(tags: recursos)
request.endAccessingResources()
request = nil
}
Esto hará que, si el dispositivo se queda con poco espacio de almacenamiento, el sistema sepa que estos datos pueden ser borrados de nuestra app y que en caso de volver a necesitarlos en el futuro se podrán volver a descargar sin problema. No se borran inmediatamente, pero quedan marcados como prescindibles.
En la estadística de ejecución, en la parte de disco, tenemos una nueva opción que nos permite ver cómo funcionan nuestros recursos bajo demanda y el propio simulador hace la simulación de las descargas y recursos que están en uso, como si realmente se descargaran de la App Store, pudiendo monitorizar que nuestra gestión funciona correctamente.
El nuevo Xcode incorpora datos estadísticos que se suman a los actuales de CPU o memoria que ya existían. Ahora podemos acceder a informes de gasto energético en tiempo real, para saber dónde y cómo nuestra app está consumiendo más energía de los diferentes componentes del sistema.
Además, Instruments incorpora nuevos medidores para Core Location para saber cuántas veces estamos usando la localización, o el rendimiento de Metal en nuestra app.
Otra característica importante es la denominada Address Sanitizer que nos permite localizar los problemas provocados por fallos de memoria en la app de manera mucho más precisa. Esta nueva opción, que activamos en los perfiles de compilación, activa un modo mucho más preciso en nuestro proyecto, con información de depuración extendida (la cual no puede ir incluida cuando subimos una app por motivos claros de seguridad) que permiten monitorizar los fallos provocados por desbordamientos de memoria, acceso a direcciones no existentes, descarga de elementos de memoria…
Address Sanitizer se integra dentro de la ejecución global y su depuración, instrumentalizando la app en tiempo real y parando justo en el punto de código que falla, en vez de hacerlo como es habitual muchas veces en el main de la propia app. Solo hay que activar este nuevo modo (mucho más lento en general) cuando queramos buscar un fallo y nada más.
Cuando activamos este, además podemos acceder a la pila completa del fallo con todo el código relacionado con el mismo y con indicaciones más precisas de por qué ha fallado la app, haciendo un seguimiento y marcado de las asignaciones y liberaciones de memoria y permitiéndonos localizar dónde está el problema en la gestión de las asignaciones de esta.
También tenemos a nuestro disposición el gestor de cuelgues o crashes donde podemos ver todos los fallos de cierre que ha tenido nuestra app, reportados por usuarios de la propia App Store o a través de TestFlight. Podemos ver qué ha fallado, dónde, la pila de procesos que falló e incluso podemos gestionar si la incidencia está resuelta o no, incluyendo división por versiones de estos fallos.
Otra novedad importante es que podemos hacer tests de interfaces que nos permitan grabar una serie de pruebas de ejecución de una interfaz, que cubran que funcionan bien, que cargan los recursos, que van donde deben, etc. Podemos grabar pruebas y cada vez que cambiemos el proyecto podremos volver a lanzar la automatización que volverá a lanzar la prueba y nos dirá si la pasa o no, por si algo que antes funcionaba (por algún cambio no calculado) ha dejado de hacerlo. De hecho, veremos cómo se ejecuta la app en tiempo real en dichas pruebas, como si fuera una macro.
Incluso podemos activar un nuevo modo que nos de estadísticas de uso de nuestro código y nos marque qué partes de este se usan más o menos en cada ejecución e incluso detectar qué código no es usado nunca.
Lo más importante de todo, es que el nuevo Xcode 7 incorpora muchas mejoras, muchas funciones que ya dan sensación de terminadas (no como hasta ahora que muchas cosas parecían de una versión beta). Como ya dijimos en nuestro último podcast, este año es el año del asentamiento, el año en que las cosas dejan de estar en una versión de prueba continua y donde el foco es la funcionalidad, la estabilidad y la seguridad.
Y el nuevo Xcode 7, aun en versión beta, es un gran paso adelante que incluso permite la prueba en dispositivos del código sin necesidad de cargar perfil ninguno. Solo conectamos el dispositivo y probamos, aunque no tengamos cuenta de pago de Apple. Para que la app funcione sin el dispositivo seguimos necesitando cuentas de pago y registrar los dispositivos como hasta ahora, pero siempre que tengamos el dispositivo iOS 9 conectado por USB, podremos ver cómo funciona nuestra app sin límite alguno. Para las cuentas de pago, podemos registrar ahora hasta 100 dispositivos de cada tipo para pruebas de apps, incluyendo iPad, Apple Watch, iPhone o… Apple TV… (???)
Sin duda, son muchas e importantes novedades y estamos solo al comienzo. Seguiremos informando porque el WWDC 2015 aun continua. Y como siempre, Good Apple Coding.