La lista de deseos de un desarrollador para la WWDC 2019

¿No te quieres perder nada sobre la #WWDC19? Nuestro director Pedro Aznar estará en California para contarnos todas las novedades, y en Applesfera haremos una cobertura muy especial durante toda la semana. Todos los detalles, en nuestra página especial de seguimiento.

Busca una lista de deseos para las próximas versiones mayores de sistemas operativos de Mac que se presentarán desde hoy en la WWDC 2019. La gran mayoría serán desde el punto de vista del usuario: que se puedan conectar discos duros en el iPad, el modo oscuro, mejoras en el control parental, que Siri funcione mejor, que mejore la autonomía del dispositivo.. un montón de deseos que mejorarían nuestra experiencia de uso. Pero, ¿y si le preguntamos a un desarrollador?

Preguntarle a un developer como yo tiene doble visión: primero porque se apuntará a todos esos deseos como usuario, pero después querrá más cosas no para él: para su trabajo. Ese es mi caso y por el que he planteado esta artículo. Enumerar qué cosas en el ecosistema de desarrollo de Apple deberían mejorar para facilitarnos nuestro trabajo en las próximas versiones mayores. Una lista que os invito a ampliar en los comentarios mientras esperamos el arranque de la WWDC 2019.

En mi lista estarían los siguientes puntos que paso a enumerar en apartados.

Criptografía

Aunque parezca mentira, el uso de la criptografía para cálculo de hash o cifrado de datos es algo que no es especialmente simple de implementar en un desarrollo. Si queremos que sea más fácil, desgraciadamente hemos de acudir a librerías de terceros. El motivo es porque la librería nativa de Apple, CommonCrypto, data en su última versión del año 2010 y en su mayor parte está hecha en C, por lo que si queremos usarla en Swift se complica especialmente por la conversión de los tipos de datos, debido a la interoperabilidad entre ambos lenguajes.

La criptografía es una funcionalidad muy importante hoy día para preservar la privacidad de los datos de los usuarios, pero irónicamente la implementación nativa de Apple (CommonCrypto) se ha quedado un poco antigua.

No obstante, con Swift 5 se han hecho una serie de mejoras en las conversiones de tipos que permiten una manera más sencilla de usar las librerías nativas, pero sí es cierto que se ha quedado desfasada en el soporte de las últimas implementaciones que incluso la propia Apple recomienda, como el método de cifrado AES256-GCM que no se puede usar directamente. Si queremos hacerlo, hay que incorporar una cabecera del proyecto de código abierto de la librería de Apple (en C) para acceder a las funciones privadas que usa el protocolo TLS de seguridad y así acceder a este modo de cifrado.

En conclusión: hay que dar muchas vueltas, es antigua, no está actualizada y dada la importancia de la protección de datos que da Apple a todo, debería sacar una nueva librería de criptografía o mejorar la actual para permitir un mejor uso con Swift, con una implementación más intuitiva y soportando los últimos estándares.

Por último, que permita que la base de datos local Core Data soporte cifrado por defecto en todos los datos con solo activar una opción. Algo que implementaciones de terceros como Realm ya incorporan, pero que si quieres poner en Core Data tienes tú que hacerlo a mano o buscar soluciones complejas.

Sincronización de datos

Una de las condiciones que todos los juegos de Apple Arcade deben tener es la obligación de persistir las partidas entre dispositivos. Si empiezo una partida en el iPhone, puedo seguir por donde iba en el iPad, continuar en el Apple TV y acabar en el Mac. Este ciclo de vida del dato de cualquiera de los juegos obliga, por razón lógica, a una implementación de lado servidor para hacerlo.

Apple Arcade, entre sus obligaciones, requiere de un backend como servicio integrado con el Apple ID. Pero la actual solución nativa de Apple, CloudKit, se ha quedado antigua y obsoleta en muchas funciones. Necesitamos un nuevo servicio para facilitar no tener que pedir un usuario por cada juego a los futuros jugadores.

Pero si implementamos nuestro lado servidor, hemos de identificar a los jugadores en nuestro propio juego. Les hemos de pedir usuario y clave, y tendrán uno por cada juego. Y con todo ello llevar el consabido fichero de datos, declararlo como parte de la GDPR, permitir que el usuario vea sus datos, pueda desistir de ellos o cambiarlos... un lío importante y además también para el usuario que debería tener un usuario y clave para cada uno de los más de 100 juegos que podría instalar con Apple Arcade. Como podemos suponer, no tiene sentido alguno.

Conclusión: Lo obvio es pensar que Apple Arcade deberá ir unido al Apple ID, y teniendo ese dato ya puedo persistir las partidas entre todos los dispositivos. Pero hoy día eso no puede hacerse de una forma fácil. La única forma de guardar datos en la nube a partir de nuestro Apple ID es usando la librería CloudKit, el servicio propio de Apple de backend como servicio, que no ha sido actualizado desde 2016. Y si hablamos de motores de juego como Unity o Unreal Engine, la mayoría de plugins que en su día soportaron CloudKit están deprecados o son tan antiguos como la propia última versión.

¿Quiere decir eso que CloudKit es malo? Nunca lo ha sido. Es una buena opción para guardar datos en la nube y sincronizarlos entre dispositivos a partir del Apple ID, pero es muy limitado hoy día si lo comparamos con otras soluciones de backend como servicio, al estilo de Firebase (la más extendida en su uso).

Podríamos ver como algo claro que Apple estaría trabajando, y eso espero porque es uno de mis deseos, en su propia solución de almacenamiento y sincronización de datos y documentos en la nube para sus apps. Su propio nuevo backend como servicio que además tenga compatibilidad con motores de videojuegos de terceros y no solo con apps nativas de sus propios sistemas. La compra y liberación del código FoundationDB, como os contamos hace unos meses, podría ser una de esas sutiles señales para pensar en positivo en este aspecto.

En Applesfera

Apple libera el código de la capa FoundationDB Record, el corazón de CloudKit

Ventanas NO modales en el iPad.

Hoy día hay una enorme limitación a nivel de construcción de apps para el iPad: los desarrolladores no podemos realizar de forma nativa con la librería de Apple una ventana no modal.

Es decir: abran Pages, empiecen a escribir y quieran mostrar la ventana de formatos con el icono de la brocha. Tenemos negrita, subrayado, tipo de letra... y el cursor sigue parpadeando detrás. Pero si empezamos a escribir desaparece. Incluso si intentamos mover el cursor. Volvemos a darle, si tocamos en alguna opción de ella (porque he elegido antes un texto) aplicamos pero vuelve a cerrarse. Si está abierta y toco fuera, se cierra. Es imposible que la barra quede visible como una toolbar.

Esto es porque todos los paneles o PopOverPresentationController que podemos poner en iPad unidos a un botón de una toolbar, son modales. No permiten la interacción con los elementos bajo esta, ni tampoco moverla de sitio. Y si tocamos fuera de la ventana, una de dos, o se cierra o no nos deja hasta que la cerremos nosotros con una opción específica.

Hace falta una evolución: paneles flotantes y no modales. Que pueda anclarse esa vista a un lado de la pantalla y quede permanente abierta para tocar en otro lugar sin que se cierre. Que la pueda mover de un lado a otro, que la pueda poner incluso flotante encima de la app. Flotante encima de la ventana de otra app en Split Screen sin dejar de ser parte del sistema... que pueda crear una estructura Split Screen con trozos de la app.

Que se puedan apilar varias ventanas una debajo de otra y tenga un gesto para cambiar entre ellas. Necesitamos un nuevo componente que permita toolbars complejas más allá de las que existen ahora que son una simple barra en la parte inferior o superior de la pantalla. Ese control daría nueva vida a las apps de iPad y permitiría diferenciarlas del iPhone. Permitiría que el iPad volara a unas cotas productivas con apps más cercanas al escritorio. Permitiría que nosotros los desarrolladores pudiéramos crear apps mucho más completas y versátiles. Este es sin duda, un gran deseo.

Integración continua

Hace ya más de un año que Apple compró BuddyBuild, un servicio de integración continua, pruebas y distribución de contenido. Según todos los rumores llegaría hoy, así que podríamos tener una nueva forma (mucho más cómoda) de subir apps al App Store: a través de nuestros repositorios Git.

En Applesfera

Apple adquiere la herramienta de desarrollo de aplicaciones Buddybuild

De esta forma, cualquier commit que se subiera al servidor, haría que el cliente de integración continua saltara, bajara el código, se compilara y ejecutara los test unitarios del proyecto o de interfaz y con ello que no hiciera falta un Mac para generar proyectos. Sí, sí... han leído bien. Subir proyectos al App Store sin necesidad de contar con un Mac para ello.

No es ninguna fantasía ya que hoy día ya puede hacerse con varios servicios como Azure, que usan Macs en la nube para realizar la compilación y demás. BuddyBuild además traería capacidad de distribución de contenido para empresas o centros escolares, conectado a TestFlight para pruebas en beta, con capacidad de tomar capturas insitu en la prueba y enviarlas en directo. También con un vídeo de los últimos segundos de ejecución de una app antes de un posible cuelgue.

Sin duda es todo un deseo: que cambie el modo de subir las apps al App Store a un modelo más actual de CI/CD como muchos servicios de otros.

Conclusiones

Este año estoy seguro que los desarrolladores vamos a tener que trabajar más que ningún año. Para aprender a manejar nuevas librerías, adaptar nuestras apps (tanto a Marzipan, como el modo oscuro, como poco) y tendremos un buen número de nuevas funciones que podremos incorporar a nuestros desarrollos.

Como ya dije en algún podcast, este año la Navidad de los desarrolladores de Apple comienza hoy.