Home » Análisis » Novedades en iOS 10 de Cocoa Touch y UIKit (I)
iOS 10 Cover

Novedades en iOS 10 de Cocoa Touch y UIKit (I)

UIKit, y en general, todo el conjunto de Cocoa Touch. La piedra angular que más interesa a los desarrolladores, para realizar apps. Un conjunto de librerías que han evolucionado con los años y que ahora, con la llegada de iOS 10 y Swift 3, dan un salto evolutivo, tal vez uno de los más importantes de los últimos años. Vamos a repasar en una serie de especiales qué nos espera en la nueva versión de iOS y todos sus cambios. Y lo haremos en varias entregas, una por semana, porque es un contenido muy denso y es mejor verlo punto por punto.

Las novedades que ya no son

Durante este año, desde que se presentó iOS 9, Apple ha trabajado mucho y redefinido muchas experiencias. En cuanto a Cocoa Touch ha presentado el 3D Touch, los nuevos iPad Pro que duplican el refresco de pantalla a 120Hz (240Hz en caso de usar el Apple Pencil) y el nuevo teclado. El lápiz y el touch tienen APIs que permiten ser gestionadas de una manera sencilla y también otros como UIKeyCommand para configurar atajos de teclado.

Si analizamos, nos encontraremos que tenemos tamaños y resoluciones de pantalla muy variados y ahora, más que nunca, el diseño adaptativo que utiliza las clases de tamaño (size classes) tiene más sentido que nunca. Un diseño que nos permita adaptar (de ahí el nombre) los elementos de nuestra app a cada tipo de dispositivo, allí donde el auto-layout no tiene la capacidad de llegar por sí solo.

Nueva UI para manejar las clases de tamaño en Xcode 8

Por ese motivo, Xcode 8 ha cambiado y hecho más intuitivo el trabajar con las clases de tamaño, permitiendo que nuestras interfaces tengan en cuenta desde el dispositivo más pequeño al más grande, en un solo diseño y sacando el máximo partido a cada pantalla.

Swift 3

El principal cambio en Cocoa Touch, el más importante, es Swift 3. Porque Swift ha cambiado la forma en que se traducen las llamadas a las clases, métodos, propiedades… el cambio es radical y completo pues pocas funciones de UIKit (y de muchos otros frameworks como SpriteKit, para juegos) no han cambiado. Pequeños cambios como los que incorporan el uso de enumeraciones en vez de constantes en muchos casos ( CGPoint.zero en vez de la constante CGPointZero) o la eliminación de expresiones superfluas en clases o métodos ( UIColor.blackColor() ahora es UIColor.black() y se elimina la repetición de la palabra color).

El nuevo Cocoa Touch en Swift 3 cambia la forma general de desarrollar, a mejor, y fácilmente adaptable si aplicamos un poco de coherencia y las ayudas contextuales que el propio Xcode 8 nos irá dando.

Incluso hay librerías como Core Graphics o Grand Central Dispatch que han cambiado su propia idiosincrasia, pasando de ser un conjunto de funciones a tener una orientación a objetos que mejora ampliamente su entendimiento, eficiencia y uso.

Sin duda el cambio es a mejor, y en el caso de Grand Central Dispatch, la librería que permite gestionar las operaciones y procesos en diferentes planos, ahora es mucho más fácil y comprensible incorporándose flujos de trabajo propios de la orientación a objetos. Pasamos, al igual que Core Graphics ha invocar objetos en vez de funciones que en muchos casos resultaban confusas y poco evolutivas.

El nuevo Grand Central Dispatch es capaz, por ejemplo, de empaquetar cada item de trabajo en un conjunto de elementos con propiedad de autorelease (que se liberan solos al finalizar) que aumenta bastante su productividad.

UIPasteboard

UI de espera del control UIPasteBoard

Una de las funciones estrella del trabajo entre dispositivos es el portapapeles universal entre iOS 10 y macOS Sierra. Podremos copiar algo (incluso imágenes) en un dispositivo y copiarlo en el otro. La forma de manejarlo es la misma que hasta ahora, usando la API UIPasteboard pero hay que tener en cuenta el factor asíncrono. Es probable que cuando queramos copiar algo, veamos un diálogo del sistema advirtiéndonos que el contenido del portapapeles universal se está cargando.

En ese caso, tenemos una serie de nuevas propiedades en UIPasteBoard como hasStrings, hasURLs, hasImages y hasColors que nos permiten determinar el tipo de adjunto en el portapapeles. E igualmente, podemos restringir aquello que copiemos al portapapeles con dos nuevas opciones de UIPasteBoardOption que son expirationDate para fijar una fecha como punto de caducidad de un contenido o localOnly para que dicho contenido no se propague por el portapapeles universal entre dispositivos.

Gestión del color

El iMac 5K y el nuevo iPad Pro de 9,7″ son dispositivos que funcionan en una versión extendida del espacio de color sRGB, usando lo que llaman un gamut extendido o amplio que corresponde a la norma DCI-P3. Este nuevo espacio de color, está basado en la gama de colores de una lámpara de proyección digital de cine con luz de xenon y es usado en Hollywood como estándar en los últimos años para todas las películas. Ahora, con iOS 10, vamos a poder crear colores usando valores RGB de este nuevo espacio de color con cualquier objeto UIColor, cambiando simplemente de inicializador.

Si el dispositivo no soporta este nuevo gamut, el sistema buscará la equivalencia aproximada de valores RGB en el espacio actual sRGB, pero si tenemos un nuevo iPad Pro de 9,7″ o un iMac de 5K (y entendemos que todos los futuros dispositivos de Apple usarán este nuevo espacio de color) podremos conseguir unas reproducciones de color mucho más fieles.

Renderizado de imágenes

Cualquiera que haya trabajado en profundidad con la interfaz gráfica de Cocoa Touch, ha usado en algún momento los métodos UIGraphicsBeginImageContext y UIGraphicsEndImageContext. Pero esta API tiene varios problemas de base, entre ellos que es solo de 32 bits, no es extensible y cualquiera que haya trabajado con ella sabrá que es muy propensa a errores.

En iOS 10 existe una nueva API que sustituye a la actual. Una nueva UIGraphicsRenderer que tiene funciones tan interesantes como permitir un total control de los colores, basarse en bloques (o closures), permitir hacer subclases no solo para imágenes si no también para archivos PDF y poder controlar el ciclo de vida del contexto.

Como vemos, el cambio es bastante sustancial y ahora tiene mucho más sentido, no solo por la clara orientación a objetos del renderizador, si no porque aquello que devuelve se realiza mediante closures que se pasan como parámetro a los métodos de la clase.

Y otra gran ventaja, es que el nuevo renderizador es capaz de trabajar y capturar con cualquier contexto, no solo en apps, si no también si trabajamos con alguna tecnología de juegos que se apoye en OpenGL ES o Metal.

Gestión de los assets

Otra importante mejora es la gestión de los assets del sistema. No solo tenemos las incorporaciones que ya hubo en iOS 9 donde incluso podíamos crear atlas de texturas para juegos. Ahora, los assets pueden estar determinados a uno o varios espacios de color. Además, se permite compresión en los mismos e incluso direccionalidad para tener assets que se configuren para mostrar de izquierda a derecha o de derecha a izquierda.

La gran ventaja del uso de espacio de color, es que como opciones podremos elegir que los assets funcionen para cualquier espacio de color que tenga el dispositivo o elegir que nos cree assets separados para el espacio sRGB y para P3. De esta forma, el sistema creará por separado dos assets diferentes (uno para cada espacio de color) y se integrará a la perfección con App Thinning, lo cual significa que si uso esta opción y mi app se descarga en un iPad Pro 9,7″, la app incluirá los assets creados para el espacio de color Display P3 en vez de sRGB. Esto permitirá sacar el mayor partido a las nuevas pantallas que Apple empezará a poner en sus dispositivos a partir de ahora (y la del actual iPad Pro de 9,7).

Otra cosa que podremos hacer es aprovechar las capacidades de cada dispositivo para acceder a funciones de compresión de los assets. Podemos elegir una compresión por defecto sin pérdidas, que sea automática o elegir entre varios tipos de compresión lossy o con pérdidas. La ventaja, es que aquí estamos volviendo a hablar de un proceso de App Thinning, por el que cuando elegimos una compresión automática (ya sea con o sin pérdida de datos) lo que vamos a obtener es una serie de assets generados automáticamente por la propia App Store cuando subamos nuestra app, que comprimirán para cada dispositivo en función de sus capacidades de GPU y potencia.

Una GPU de última generación en un chip A9 o A9X de un iPhone 6s o un iPad Pro, será mucho más eficiente a nivel de procesamiento que la que pueda tener un procesador de gama anterior o incluso con el Apple TV, que cuenta en su último modelo con el A8 de los iPhone 6. Y también podemos elegir compresión con pérdidas a nivel básico, que de la mejor calidad en función de la GPU o que de la mayor reducción de tamaño, también en función de la propia GPU. Por lo tanto, como hemos dicho, cuanto más actual sea el dispositivo mayor y mejor será la compresión de los assets y menos ocupará nuestra app. Y esto incluye, también, a los juegos que usen atlas de textures dentro de los propios assets.

En cuanto a la direccionalidad, podremos proveer de assets específicos para lectura izquierda-derecha o derecha-izquierda, de forma que así se descargarán de la App Store de los países cuya direccionalidad en la lectura sea de una forma u otra. Podremos elegir un modo espejo o, en casos necesarios, imágenes separadas.

Conclusiones

Como podemos ver, tenemos muchas nuevas incorporaciones que depuran aun más el sistema, que lo amplían y lo llevan a nuevos niveles. Como complemento a este artículo, sería bueno que repasaran los cambios en la fundación de Swift pulsando aquí, las nuevas opciones de accesibilidad pulsando aquí o cómo funcionan las nuevas notificaciones en iOS 10 que pueden leer en este otro enlace. También les recomendaría echar un vistazo a SiriKit.

La próxima semana tendremos una nueva entrega con más cambios que se han incorporado en iOS 10 y, si el calendario no falla, lo haremos con la beta 2 de iOS 10 (y el resto de sistemas) ya presente. Prueben, experimenten y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Swift 4 Cambios

Los cambios en Swift 4 que harán tu código incompatible: 3 por ahora

El cambio de versión de Swift 3 a 4 es algo que provoca miedos e inseguridades. La memoria del pesado cambio a la versión 3 nos trae malos recuerdos, pero nada más lejos de la realidad en este caso. A fecha 31 de mayo, solo 3 cosas harán nuestro código incompatible. Descúbrelas en este análisis y cuales serán las simples soluciones en caso que esto nos afecte.