Apple se prepara para la primavera y estamos siendo testigos de una auténtica semana fantástica, con una presentación de producto por día. El lunes iPad Air y Mini, el martes los iMac, hoy los AirPods y todo parece indicar que mañana podríamos tener el rumoreado nuevo iPod touch y el viernes el AirPower que tanto tiempo llevamos esperando.
Pero aparte de esto, Apple también está haciendo cambios en el App Store para que las apps, tanto antiguas como nuevas, estén preparadas para sus dispositivos más nuevos y nuevas versiones de iOS. Una forma de garantizar que podamos disfrutar de las apps de la mejor forma posible sacando el máximo provecho, aprovechando que según datos de Apple, el 80% del total de dispositivos iOS activos ya cuenta con iOS 12.
A través de una nota de oficial en el portal de desarrolladores de Apple, la compañía ha informado de una serie de cambios de obligado cumplimiento, en un movimiento que no había efectuado hasta ahora y que garantiza como objetivo máximo la satisfacción de los clientes y luchar contra la desidia de muchos desarrolladores, así como empresas o colectivos responsables de herramientas que permiten realizar apps o juegos para iOS.
SDK base iOS 12.1 o superior y Xcode 10.1
El primero de los grandes cambios tiene que ver con la obligación de utilizar la versión 10 de Xcode para subir las apps al App Store, y más concretamente, con proyectos que usen como SDK de base la versión 12.1 del sistema. Esto no quiere decir que ningún dispositivo con versiones anteriores pierda la compatibilidad con las apps a partir de ahora. Cuando nosotros escogemos una SDK base, estamos diciendo qué versión de las librerías será usada para construirlas. Pero ese dato es diferente al dato del target SDK que implica la versión mínima que un dispositivo ha de tener para ejecutar dicha app y que ahora mismo tiene como valor mínimo en Xcode 10 a la versión 8 de iOS.
Al usar la SDK de iOS 10.1 como base, Apple se garantiza que las versiones de los componentes, librerías y demás partes del sistema sean las últimas posibles con soporte de los nuevos iPad con Face ID, aunque luego por retrocompatibilidad funcionen para dar soporte a dispositivos con versiones más antiguas. No obstante, los desarrolladores tienen que controlar qué funciones no se soportan en según qué sistemas y acotar aquellas partes de código que necesiten versiones superiores.
Selección del target SDK en Xcode 10.1
Por ejemplo, yo puedo hacer una app con la SDK base de iOS 12.1, dar soporte a partir de iOS 9, pero si quiero usar descarga de contenido de películas con DRM para verlo offline, la librería oficial de Apple solo soporta esta función desde iOS 10, por lo que tendría que acotar esta funcionalidad en mi código para que las versiones antiguas o no la usen o utilicen una forma alternativa que sí esté soportada.
Swift 3 como mínimo
Otro cambio que implica pasar a Xcode 10 es el soporte de Swift y sus versiones. La versión 10.1 de Xcode será la última que soporte Swift 3 y esta ya no soporta Swift 1 y 2. Por lo tanto, si alguna app sigue en versiones anteriores tendrá que migrar de forma obligada, como mínimo, a la versión 3.
Pero esto va más allá, porque Xcode 10.2 que saldría a partir del próximo día 25 tras el evento de Apple de presentación de servicios "It's show time", tampoco soporta Swift 3: solo la versión 4. Y además viene cargada con Swift 5 como ya informamos aquí hace un tiempo cuando se incorporó. Esto implica que más les vale darse prisa a los desarrolladores en pasar todas sus apps a Swift 4, como poco, porque el siguiente paso probablemente sea en septiembre cuando Apple obligue a usar iOS 12.2 como versión base y no la 12.1 actual.
¿Por qué haría eso? Porque iOS 12.2 incorpora Swift 5 cuya librería estándar es binaria estable (como ya explicamos en el artículo que tenéis sobre estas líneas) lo que supone que una app que use esta versión de base SDK y se ejecute en un dispositivo con un versión igual o superior a esta, no tendrá que incorporar la librería binaria del lenguaje entre sus recursos. Algo que reduce drásticamente el espacio que ocupan las apps y mejora su rendimiento ampliamente.
Adaptación a las pantallas del iPhone XS Max y los iPad Pro de 11" y 12,9"
Además de las normas ya explicadas, hay otra cosa muy importante y que es una pesadilla para muchos desarrolladores y diseñadores que usan librerías híbridas (basadas en HTML) para construir la interfaz, así como aquellos que siguen haciendo interfaces de forma programada sin usar archivos XIB o storyboard (las herramientas que Apple recomienda). Hablamos del soporte nativo de las pantallas del iPhone XS Max y iPad Pro de última generación.
Cuando Apple lanzó el iPhone X creó un nuevo elemento dentro de las vistas normales donde colocamos elementos llamado Safe Area o área segura. Esta zona delimita la vista que ocupa todo el lienzo donde puedo trabajar, marcando solo los márgenes utilizables: es decir, descartando la zona del notch y la zona de la barra inferior del Home.
Ejemplo de área segura no usada correctamente en un iPad Pro de última generación.
Si tenemos una app cuyos elementos estaban tomando como referencia la vista completa del dispositivo (que está adaptada a todo el tamaño del mismo incluyendo las esquinas redondeadas y las zonas superior e inferior) solo tenemos que cambiar las constraints o restricciones al área segura, y con ello nuestra app queda preparada para cualquier futura actualización.
Si hicimos nuestra adaptación así, bastará compilar con la SDK de iOS 12.1 para que cualquier app que soporte el iPad se adapte sola para los nuevos márgenes que incluyen los nuevos iPad sin botón Home. Pero si usamos elementos puestos de forma programada y estamos calculando el tamaño de la pantalla de forma fija, o usamos una librería híbrida y no preparada (estas normalmente trabajan también con tamaños fijos de pantalla en muchos casos), prácticamente tenemos que ajustar a mano todo.
Tenemos ejemplos muy claros, incluso de grandes empresas como Youtube, que no han sido capaces de crear su app de forma correcta sin pisar la barra Home (y así lleva casi 2 meses). Solo tenemos que ver la imagen sobre estas líneas y cómo la barra de Home pisa la zona de la tab bar. Si Google no corrige esto en su librería Flutter (con que está hecha la app) Apple podría rechazar nuevas actualizaciones de la misma a partir del día 27 de marzo.
Si nuestra app no se muestra correctamente y no se ajusta, usando modos compatibles, Apple la rechazará obligando a que esté bien presentada y ajustada a estas zonas seguras.
Y si tenemos un juego que usa todo el tamaño y algunos elementos se recortan por las esquinas redondeadas de los nuevos iPad, también será rechazada hasta que no ajustemos para no usar las zonas de los márgenes.
El componente Canvas Scaler de Unity nos ayudará a ajustar la UI a cualquier dispositivo iOS
En muchos casos, como por ejemplo en Unity, basta usar una última versión de la herramienta y tener la UI con el componente Canvas Scaler en modo Scale with Screen Size, además del Screen Match Mode en Expand. De esta forma, todo contenedor que contenga elementos de UI se adaptará solo a cualquier pantalla recolocando elementos según su posición relativa y bastará tal vez mover un par de elementos para que todo se vea bien.
WatchApps adaptadas al Series 4 y usando la SDK de WatchOS 5.1
También todas las apps para el smartwatch de Apple deberán usar una última versión como base, en este caso la versión 5.1. Y de igual forma, los nuevos Series 4 también tienen área segura ya que las esquinas redondeadas eliminan parte del contenido y crean unos márgenes que las apps han de tener en cuenta.
Zonas seguras del Apple Watch Series 4
Si a partir del 27 subimos cualquier nueva app o actualizamos alguna que no soporte el nuevo Series 4 y vaya en modo compatible (mostrando menos información en pantalla), Apple la rechazará igualmente pues debemos adaptar nuestras apps y usar el área segura de la interfaz para ajustar y aprovechar el tamaño de las nuevas pantallas de los nuevos modelos. De nuevo, bastará ajustar al área segura nuestras constraints para garantizar, no solo que se vean bien las apps en el Series 4, si no que nos garantizamos cualquier futuro cambio de resolución en futuros dispositivos del reloj inteligente de Apple.
Metadatos y memoria
Por otro lado, los metadatos de las apps también han de ser actualizados y subidas nuevas capturas que soporten los modelos XS Max y los nuevos iPad Pro, respetando resoluciones y distribución. No podemos olvidar que el iPad Pro de 11" cambia su relación de aspecto a 3:2 con respecto a los 4:3 que tenían modelos anteriores. Y el iPad de 12,9", sigue siendo 4:3 pero el sistema usa una pequeña parte de la pantalla (en la zona inferior) para la barra del Home, por lo que igualmente la zona de uso de las apps se reduce levemente.
Y por último, pero no menos importante, si somos desarrolladores de videojuegos o de apps de carga gráfica, Apple nos obliga a hacer el cambio a iOS 12.1 como ya hemos comentado, que nos trae un cambio importante en el uso de memoria.
iOS tiene un limitador de memoria que funciona para proteger el sistema de un exceso de uso de la misma, y que puede provocar el cierre de una app si consume demasiados recursos o memoria. Dicho limitador, hasta iOS 11, no incluía en sus cálculos un tipo de memoria llamada purgable, no volátil, que era la que muchos juegos o apps gráficas usan para cargar texturas o contenido que tengan un peso especial en la memoria. Por lo tanto, si nos pasábamos usando esta, no contaba en el cómputo del limitador de memoria y la app seguía funcionando. Esto, obviamente, provoca estados de inestabilidad en el sistema e incluso reinicios o cuelgues no controlados de forma aleatoria (muy difíciles de detectar pues no son fallos per sé de la app).
Pero en iOS 12, este tipo de memoria ahora sí computa en el limitador de memoria, para mejorar la seguridad y estabilidad del equipo. Así que si nuestro juego o app de carga gráfica usa Metal (librería que guardaba hasta ahora cosas en esta memoria cuando se refería a contenido a tener precargado), tendremos que volver a probar la app, ajustar el uso de la memoria, los procesos de carga y limitar la app o juego para que no abuse y evitar que se cierre por el limitador. Y ya sabemos que un cierre por el limitador de memoria, supone la expulsión del App Store en sus pruebas (como cualquier otro cuelgue inesperado de una app).
Si usamos motores de juegos, aunque la mayoría de cambios los hará solos el mismo si usamos una última versión, no está de más reducir al máximo el tamaño de las texturas y elementos gráficos para bajar el peso y uso de la memoria en los juegos.
En caso que se nos resista, Apple ha habilitado una página donde podemos pedirles asistencia para que nos den un componente del sistema (un entitlement) que nos permita seguir usando el modo de memoria de iOS 11 de forma temporal. Solo tenéis que seguir este enlace.
Mejorando, poco a poco
Como podemos ver, son pequeños grandes cambios que nos hacen a los desarrolladores trabajar más, hacer mejor las cosas y ofrecer ese extra de calidad que Apple quiere para con sus sistemas.
Y todo ello, ha de estar preparado para el próximo día 27 de marzo, porque si no, supondrá rechazos sistemáticos de nuestra nueva app o actualización de una ya existente. Y este dato es importante de tener en cuenta porque si las normas afectan a partir del 27, puede que el próximo 25 NO veamos iOS 12.2 si no una breve versión final de pruebas (una versión Golden Master) que de paso al lanzamiento público el citado día 27 donde entran en vigor este nuevo cambio de normas, así como unos nuevos términos de uso del servicio de anuncios en las búsquedas de apps que Apple también ha enviado hoy mismo a los desarrolladores.
Todo con un objetivo: que los sistemas sean cada vez mejores, más estables y con mayores garantías para los usuarios. Como desarrollador y formador no puedo más que aplaudir a Apple por "apretarnos" las tuercas a los desarrolladores y empresas para estar a la altura.
Ver 17 comentarios