Sin duda, la pasada WWDC nos dejó tal cantidad de información en todas sus charlas y eventos, que es complicado dar toda la información a la vez y la vamos procesando poco a poco. Debemos tener presente que fueron más de 100 charlas con información sobre cómo desarrollar apps siguiente las mejores prácticas, nuevos cambios, librerías... mi propósito es llegar a finales del mes de julio con todas ellas vistas y aprendidas. Algunas de ellas las he visto más de una vez (como las de SwiftUI) para asentar conceptos y conocimientos. Me siento como si volviera a mis años universitarios, aunque en esta ocasión disfrutándolo como un enano.
Una de las charlas más interesantes que se dieron (y de las más cargadas) es la que trata sobre las novedades en la modernización de las interfaces en iOS 13. Un compendio de cambios que redefinirán la forma en que trabajamos con las apps ahora mismo. Desde un punto de vista técnico, con cambios que solo verá el usuario en pequeñas mejoras de rendimiento o alguna nueva animación aquí o allá. Hasta funciones que cambian la experiencia y el look and feel del uso de las apps nativas.
En medio de todos estos cambios, Apple habló sobre algo muy importante: lo que llamamos en desarrollo, su roadmap. El camino, ruta o recorrido que seguirán en los próximos meses para obligar a los desarrollos a adaptarse a todos estos nuevos cambios que se han incorporado en las nuevas versiones. Y de eso vamos a hablar: de qué han de hacer los desarrolladores, en este caso, desde abril de 2020 (fecha de salida de la futura versión de primavera de los sistemas, más en concreto la versión 13.2).
Apps flexibles, la adaptabilidad completa de la UI
Uno de los temas más polémicos alrededor de las interfaces en las apps, siempre tiene que ver con su adaptabilidad: que sean capaces de adaptar su tamaño y maquetación a cualquier pantalla sea cual sea su tamaño. Trucos hay muchos: hay gente que crea una pantalla diferente para cada tipo de pantalla, otros que por código detectan el tamaño y ponen los elementos “a ojo”, gente que usa las interfaces independientes o XIB construyendo en base a una para los iPhone y otra para los iPad, o uno para todos, o usa Storyboards que permiten tener todo el flujo en pantallas en un mismo fichero... las soluciones son muchas y no todas son óptimas.
Si trabajamos con una librería híbrida, se nos une el problema que las interfaces están dibujadas con tecnología web (sobre una ventana de navegador camuflada). Por lo tanto el control que tenemos del tamaño y la adaptabilidad de los elementos no es tan flexible. Aunque usemos tecnología web responsive, las pantallas son tan diferentes que muchas veces es un cálculo complicado que todo se coloque bien en su sitio. Si tenemos un navegador que tiene sus barras de navegación y herramientas arriba y abajo, ayuda mucho. Pero cuando debemos usar todo el lienzo, la cosa se complica.
Hay que tener en cuenta que no solo tenemos varios iPhone con notch y diferentes tamaños (con una relación de aspecto extraña) donde no podemos pintar en las zonas superiores o inferiores... también una app híbrida multiplataforma tendrá que soportar Android y la cantidad de posibilidades de tamaños de notch, resoluciones o hasta agujeros en la propia pantalla (véase caso Samsung). Por lo tanto, muchas veces estos optan por casi hacer diseños que se adapten a cada tipo de pantalla de forma más manual que automática. O tal vez una construcción automática pero que luego haga determinados pequeños ajustes en función del tipo de pantalla detectado.
Pero estas técnicas más manuales que automáticas dejarán de ser válidas pronto. Todo va a cambiar en el desarrollo de apps para sistemas Apple desde abril de 2020. Apple cambia sus normas y a partir de esta fecha, todas las apps que no sean completamente flexibles en su UI e independientes del tamaño del dispositivo, ajustándose a pantalla completa desde el iPhone más pequeño hasta el iPad más grande, serán rechazadas. Incluso aquellas que tengan fallos en el layout y coloquen elementos en lugares incorrectos (como poner algo en una esquina de un iPhone XS y que se corte o colocar elementos encima de la barra del Home en un iPad Pro de tercera generación).
Por lo tanto cualquier cálculo manual o semiautomático, será detectado y rechazado. La propia Apple ha dado una pista de cómo comprobar nosotros mismos que las apps funcionan: activar el check de Project Catalyst en el proyecto, ejecutar la app en Mac y probar a redimensionar nuestra app “a las bravas” cambiando el tamaño de la ventana donde se ve libremente. Si la app se comporta y se adapta en tiempo real a cualquier tamaño de la ventana, hemos pasado la prueba. Si no, tenemos un problema y tendremos que adaptar la app usando las técnicas de auto-layout, diseño adaptativo o lo que nos ofrezca la librería que usemos para construir nuestra app (si es que lo ofrece).
Apple dejará de usar las adaptaciones automáticas a letterbox cuando una app no está adaptada a pantalla completa. Por lo que si no aprovechemos el total de la pantalla, automáticamente la app fallará, se cerrará y será rechazada.
Una norma cuyo objetivo es evitar los despropósitos de interfaces mal adaptadas, construidas o maquetadas y que cuando Apple saque un nuevo dispositivo con nueva resolución, las apps se adapten solas sin ningún problema. Además, no solo contarán en las pruebas los diferentes dispositivos: si la app soporta el iPad, deberá poder usar los diferentes modos split screen y slide over que las muestran más pequeñas para el flujo de trabajo multitarea.
Las apps de iPad deberán soportar la multitarea y el drag & drop
Otro cambio muy importante: a partir de Xcode 11 la estructura que da vida a las apps ha cambiado. Antes, el mayor control que teníamos sobre los procesos que lanzan nuestra app era el delegado de la misma: funciones que se lanzaban en estados concretos cuando la app entraba en segundo plano o volvía de él, cuando se cerraba completamente borrándola de memoria o si usábamos como entrada a la app un enlace profundo (o deep link) que viniera de una web, un email u otra app.
Ahora, las apps tienen una nueva estructura por escenas, donde también recibimos información cuando se crea una escena nueva o cuando se recibe información de otra escena de la misma app. ¿Qué son estas escenas? Las múltiples copias de una misma app que pueden estar a la abiertas a la vez en un iPad con iPadOS 13. Como ya vimos en su momento, ahora las apps podrán tener varias copias de sí mismas y pasar información arrastrando y soltando entre las diferentes copias. Como varias ventanas de Pages, de Notas, del cliente de correo o cualquier otra app.
Drag & Drop entre dos apps iguales en dos escenas distintas
Pues bien: desde abril de 2020, todas las apps de iPad deberán soportar estas escenas y la capacidad de poder abrir varias copias de una misma app en iPadOS 13, lo que significa que si hacemos un app para iPad deberemos usar Xcode 11 de forma obligatoria y utilizar la SDK de iOS 13 y no ninguna anterior (aunque luego podamos soportar versiones anteriores de manera voluntaria). Y no lo solo eso: todas las apps de iPad deberán soportar el flujo drag & drop (arrastrar y soltar) para poder intercambiar información entre las diferentes instancias de una misma app. De forma obligatoria o serán rechazadas.
Esto es un disparo en la línea de flotación de cualquier app de iPad que no sea nativa, donde otras librerías que soporten la tableta de Apple tendrán que buscarse la forma de implementar esto, bien a través de plugins, actualizaciones o cualquier cambio. Pero insistimos que si no, será rechazada.
Y ojo, porque no es ninguna tontería pensar que en iOS 14 (donde se prevé que esta función de múltiples instancias de una misma app llegue a los iPhone) haga algo parecido y que desde primavera de 2021, todas las apps de iPhone tuvieran que soportar abrir diferentes copias de sí mismas.
Estamos de acuerdo que pondrá en apuros a más de un desarrollador o equipo de desarrollo, pero desde luego lo importante (y lo digo también como desarrollador) es que nuestros usuarios se beneficien de estos nuevos flujos de uso y experiencias.
Splashscreens dinámicas a través de Storyboards
En los comienzos del desarrollo para iOS, la forma de poner un splashscreen (la pantalla fija que aparece al arrancarse tu app) era a partir de lo que conocemos como “imágenes de lanzamiento”. Una imagen fija (normalmente PNG) que debía tener diferentes versiones: una para cada tamaño de dispositivo.
Pero hace unos años esto cambió y se incorporó lo que hoy conocemos como un Storyboard de lanzamiento. Este no es más que un lienzo, como el que normalmente usaríamos para crear las interfaces para una app, pero completamente estático y sin interacción de ningún tipo. ¿Para qué? Para que usando las técnicas de auto-layout que permiten a cualquier interfaz adaptarse a cualquier tamaño de pantalla, se permitiera hacer una única splashcreen que funcione en todos los dispositivos.
Hasta hoy, se puede elegir el sistema antiguo o el nuevo. Pero a partir de abril de 2020, será obligatorio usar el nuevo con los Storyboards y el antiguo con pantallas de lanzamiento estará prohibido. Así que a partir de esa fecha, o tenemos splashscreen en blanco que no mostrarán nada o los diferentes motores o librerías de terceros tendrán que adaptarse y ser capaces de generar estos Storyboards, si aún no lo hacen. Será obligatorio para todas las apps que usen la SDK de iOS 13 (es decir, que usen Xcode 11), aunque soporten versiones anteriores hasta iOS 8.
Pequeños grandes cambios
No son muchos cambios, pero sí relevantes y dan a entender cómo Apple se toma cada vez más en serio la calidad de las apps de terceros en sus dispositivos y busca algo lógico: una experiencia unificada. No tiene ningún sentido que ellos se esfuercen en presentar nuevos cambios, funciones innovadoras y grandes adelantos y por culpa de empresas o responsables de equipos con poca visión se decidan usar otras herramientas o librerías que se salgan completamente de la experiencia del sistema.
Y digo esto tanto hablando de Apple como de Google con Android quienes también hacen un gran esfuerzo en conseguir una experiencia unificada en su sistema y nuevas funciones, y luego no se aprovechan y confunden al usuario con diferentes experiencias de usuarios y aspectos que desconciertan al usuario y no se pegan a la experiencia que todos esperamos de aquel dispositivo que hemos elegido para nuestra vida digital.
Ver 8 comentarios