5.888 oyentes
Terminada la WWDC23, la cantidad de novedades sobre SwiftUI y sus profundos cambios sobre arquitectura nos dejan una pregunta: ¿todos estos cambios solo van a funcionar en iOS 17?
Técnicamente, Apple tiene una herramienta capaz de permitir la retrocompatibilidad de todo lo presentado este pasado junio de 2023, usando las sentencias BackDeployed que permiten ampliar librerías ya existentes en versiones anteriores.
Os explicamos qué es lo que Apple tendría que hacer para convertir toda la API de SwiftUI en retrocompatible desde iOS 13 y nuestra teoría al respecto de si estará o no disponible en algún momento.
Convierte en un Maestro del Desarrollo iOS con el Swift Mastery Program 2025. Encuentra toda la información pulsando aquí.
Suscríbete a nuestro canal de Youtube: Apple Coding en YouTube
Descubre nuestro canal de Twitch: Apple Coding en Twitch.
Descubre nuestras ofertas para oyentes:
---------------
Consigue las camisetas oficiales de Apple Coding con los logos de Swift y Apple Coding así como todo tipo de merchadising como tazas o fundas.
Transcripción
Wanda, la comunidad de podcasts independientes en español.
Hola, y bienvenidos a un nuevo episodio de Apple Coding Daily. Hoy vamos a hablar de un tema que es cuanto menos polémico, polémico a nivel de desarrollo. ¿Por qué? Pues básicamente porque estamos hablando de la retrocompatibilidad Vamos avanzando a partir de la versión trece donde Apple lanza Suip UI llevamos la versión trece, catorce, quince, dieciseis, ahora la diecisiete, recién presentada por Apple, Y cada año, todo lo lanzado en Suip UI y todo lo lanzado en el resto de librerías del sistema, no es retrocompatible. Android funciona de otra forma distinta.
Android tiene una máquina virtual software y tiene una librería llamada Up Compact, que permite buscar la retrocompatibilidad entre nuevas funciones, porque al final todas esas nuevas funciones tienen una traducción a la parte de Java y por lo tanto no es tan incluída dentro del sistema operativo, que es lo importante, las APIs se traducen todas a través de la máquina virtual Java por lo que cualquier elemento que salga posteriormente podrá ser utilizado en versiones anteriores. Pero Apple no, Apple pone dentro del sistema operativo las distintas librerías por lo que una nueva versión del sistema operativo con nuevas versiones de la librería no van a ser compatibles con lo que serían versiones anteriores, por lo que si yo quiero hacer una aplicación en SWI hoy, tengo el problema de no saber cuál es mi versión target porque dependiendo de cuál sea mi versión mínima de sistema podré hacer las cosas mejor o peor Hay una solución para esto, sí, pero todavía está por ver si Apple la implementará, así que vamos a verlo.
Pero antes de hablar de ningún tipo de retrocompatibilidad, déjame te hable de algo que te interesa si estás dentro de un proyecto de transformación digital. Y es que, de nuevo, tenemos como colaborador a Ronstadt Technology, la división de consultoría IT del grupo Ronstadt que te ayuda con la gestión e implementación de servicios tecnológicos especializados y la automatización de procesos, la siempre compleja tarea de la gestión de datos. Con Randstar Tecnologist, tu empresa alcanzará nuevas cuotas de desarrollo y envergadura porque cuentan con más de quince coma cero profesionales especialistas a tu disposición que serán capaces de poner en marcha y ejecutar cualquier proyecto y te donde estés involucrado.
Y además recuerda que en
Randstad Technologies también seleccionan para ti profesionales cualificados que se adapten a la misma velocidad para seguir aprovechando todas las oportunidades con su propia metodología elección, su profundo conocimiento del mercado y por supuesto con las herramientas de evaluación de competencias que te garantizan que los candidatos que tu empresa necesita están ahí. En Ranstag Technology están preparados, pero la gran pregunta es, ¿lo estás tú entra ya en Randstadt.es y descubrelo. R a n d s t a d.es. Muchas gracias a Randstadt Technology, como siempre por colaborar con Apple Coding Daily.
Si hacemos un recorrido de SWI desde la versión trece veremos que la versión que salió con ellos trece. Veremos que SWI en esa versión pues era una beta. Básicamente, beta no confiesa pero una beta, ¿vale? Le faltaban un montón de había que hacer un montón de cosas directamente contra UAKID usando los elementos representables, etcétera. Mientras Apple ha ido evolucionando, Sui UI ha ido incorporando nuevos cambios, nuevas mejoras, nuevos elementos, todo perfecto pero siempre ha estado el problema que por ejemplo si yo quiero buscar la forma de usar los nuevos formateadores de datos que funcionan directamente sobre Swift sólo funcionan en años quince si quiero trabajar con el nuevo modo de navegación, el nuevo navegation stack, que permite navegación de manera programática, pues solo funciona a partir de iOS dieciseis, Esto es un problema, es un problema bastante importante porque al final está limitando la capacidad de desarrollo de muchas empresas, porque a ver, una cosa es que a mí, sinceramente, me parece mal por parte de las empresas que se de soporte a versiones demasiado, demasiado antiguas, pero también tenemos que tener presente, por ejemplo, a ellos trece, catorce y quince, están soportados por los mismos exactos dispositivos Por lo que no tiene ningún sentido que ninguna empresa hoy día se limite a soportar a partir de años trece o catorce, porque insisto, el cien por ciento de los dispositivos que soportan a ellos trece y catorce también soportan la quince, pero no podemos olvidar que hay dispositivos que se quedaron en las doce y tampoco podemos olvidar que hay dispositivos que no han llegado a las dieciseis.
Como los, por ejemplo, iPhone siete, siete plus, los iPhone seis, ese, etcétera. Y ahora, en iOS diecisiete se quedan fuera los Iphone diez y los Iphones ocho y ocho Plus, que claro, ahora ya sí es un número importante de usuarios. Yo puedo justificar en una empresa que soporten directamente a ellos quince porque todos los dispositivos que soportan la quince soportan catorce y trece es decir que el usuario no actualiza porque no quiere no porque no pueda pero a partir de la quince ya no puedo justificarlo porque la dieciseis deja fuera a usuarios que no es que no quieran, es que no pueden actualizar. Eso tiene una solución y técnicamente Apple la ha lanzado en swift cinco punto ocho la pasada primavera la opción de arroba backdeploy ¿Por qué? Porque técnicamente existe un problema que impide que, pues como ya hemos dicho, si yo tengo una versión de una librería y esa versión de la librería está cargada en el sistema operativo lo que no puedo hacer es ampliar la versión de esa librería, de las versiones antiguas, porque tendría que sustituir el propio sistema operativo.
Ese es el problema de la filosofía de Apple. Ellos por un lado cargan las librerías binarias en el sistema operativo, lo que hace que tenga un mejor rendimiento, que todo vaya mucho mejor, que el sistema sea mucho más eficiente, más seguro, etcétera, etcétera, pero tiene el problema que las opciones que tiene esa versión están limitadas a las que son y cuando hay una nueva versión que amplía versión que amplía capacidades pues obviamente como las versiones ya instaladas no lo soportan y Apple no va a hacer una actualización de versiones anteriores para incluir cosas que tienen las más actuales porque esas versiones más actuales probablemente dependan de cambios más importantes que no sean retrocompatibles, pues por eso no se puede hacer ese cambio. Insisto, la solución es poder ampliarlo. La solución la tiene Apple en la mano, la hizo con Async Await, async a Wade cuando fue lanzado en septiembre del año dos mil veintiuno con años quince, El cambio que se hizo fue bastante importante, porque fue un cambio de paradigma en cuanto al uso de las API, en este caso la API de concurrencia, sincronía, etcétera. Pero esta parte solo era compatible con Swift cinco punto cinco.
No lo era retrocompatible mente porque Assing away era un módulo aparte del propio lenguaje no formaba parte de la librería estándar del lenguaje que sí tiene una estabilidad binaria y garantiza que todo lo que se haga en el futuro funcione de forma retrocompatible porque Apple ha conseguido una manera de hacer que esos pequeños cambios en el lenguaje puedan ser aplicables a versiones anteriores a través de pequeños cambios a nivel binario, en fin. Cosas complejas que son más difíciles de explicar y una forma similar o parecida a cómo lo hace Android. En ese sentido, pero insisto, sólo para el lenguaje. Cuando hablamos de las librerías que son capaces de construir aplicaciones como Suip UI, esto ya no funciona así. Por lo tanto, en Async Await lo que Apple hizo fue que si estamos en la versión que soporta Await, pues ya está, simplemente pues unimos no a la versión que tiene el propio sistema operativo a partir de años quince y listo, pero a partir de trece y catorce Como Asignawait no existe, lo que apenas hace es crear una pequeña librería que carga dentro del ejecutable y que es la que tiene los enlaces del binario para que si Assingerwait existe en el sistema operativo, use la versión del sistema operativo y si no existe en el sistema operativo, carga esta pequeña librería y enlaza todo lo que es asignar Wait a esta pequeña librería que viene dentro del propio ejecutable.
De hecho SWIFT funcionaba así esta versión cinco. Todas las versiones uno, dos, tres y cuatro la librería estándar del lenguaje venía como un componente, venía como una dependencia dentro del binario porque si tú compilabas en la versión cuatro dos uno necesitabas la misma exacta versión cuatro dos uno en el en lo que es la parte ejecutable para que tu aplicación funcional a partir de las cinco, Swift ya va cargado directamente en el sistema operativo. Entonces, ¿Qué es lo que, qué es lo que Apple puede hacer a este respecto que ya hizo con Async away? Con la CINAWAYT nosotros tenemos toda la lápida, CINAWAYT salvourrelecesion.ched.data lo que es la instrucción exacta de Asinawait dentro de la API de URL session. ¿Por qué esa exacta instrucción no está retrocompatible dentro de ellos trece y catorce y tenemos que crearlo nosotros de manera programática a través de extensiones.
Pues porque lo que no es capaz de hacer el sistema es coger esos, coger una librería que ya existe y ampliarla a nivel binario. Lo que yo sí puedo hacer a nivel de código haciendo extensiones en Swift que amplíen cualquier tipo de tipo de dato, librería, etcétera. A través de las extensions, a nivel binario no se puede hacer ¿de acuerdo? No existe esa opción porque el lenguaje swift no lo soporta. No lo soporta hasta la versión cinco punto ocho con arroba back de Project.
A partir de ahí ya sí se puede hacer una ampliación, sí se puede hacer una extensión que amplíe Añadiendo nuevos métodos y nuevas propiedades calculadas, no almacenadas, en los binarios, es decir, se pueden hacer extensiones a nivel binario, por lo que si una librería en versión antigua no incluye x llamadas, ahora se pueden poner en el ejecutable y el sistema será capaz de usarlos del sistema si existe y si no existe usar las que hay en el ejecutable. Por lo que ahora, Apple puede técnicamente hacer que toda la API de Subi sea retrocompatible hasta ellos trece. Lo ha hecho, no. ¿Por qué? Pues probablemente, y esto es una teoría mía, no está basada en ningún tipo de información oficial al respecto probablemente porque no les ha dado tiempo.
Y tienen de aquí a septiembre para hacer este cambio incluso más adelante porque da igual que la nueva versión de ayos salga sin ser retrocompatible si en noviembre, iOS diecisiete punto uno incluye esta retrocompatibilidad, problema solucionado, porque a partir de ahí yo pongo como target de mi aplicación a ellos trece por ejemplo y con que use la versión de scope que ya incluye esta retrocompatibilidad, ya funcionaría todo Suite UI. Desde iOS trece toda la API, todos los cambios, de años catorce, de años quince, de años dieciseis y de años diecisiete. ¿Por qué ahora es esencial que esto suceda? Porque años diecisiete ha cambiado por completo la arquitectura de la API. Suite UI, la arquitectura del framework.
Suite UI, tenía una forma de funcionamiento basada en varios property routers. State, binding, Observe Doublehead, Stay Doublehead, EnvironmentObject, etc. Tenía varias formas de crear esa arquitectura, pues bien la ha cambiado por completo en años diecisiete la ha reducido a menos elementos la ha hecho mucho más simple de entender ha eliminado elementos como los publish, ahora basta hacer una clase que tenga justo encima arroba observable y automáticamente todas las propiedades de esa nueva nueva clase van a ser actualizables dentro de la interfaz reactiva, por lo que no vamos a tener que volver a poner ningún arroba publishing al aparecido. Además, SWIFT data la nueva versión, que mejora corre data, que crea una versión de gestión de datos, nativa en SWIFT, también cambia todo esto, basta poner en una clase arroba model y ya tenemos toda esa clase realmente activa y cualquier cambio es reactivo. Podemos usar Bindavos que son formas de poder traspasar instancias directamente elementos de tipo textil, yo puedo editar directamente en un textil el valor de un de un model del nuevo SWIFT Data, sea ese es el nivel el cambio es de un gran calado y lo que no tiene ningún sentido es que yo ahora si quiero hacer una aplicación en iOS diecisiete tenga que usar una nueva arquitectura mejorada, mucho más eficiente, mucho más simple de entender, mucho más práctica sin ningún tipo de doblef, ni ningún tipo de efecto secundario como solía parecer anteriormente que de pronto un observador que se distanciaba y perdidas el dato, te volvías loco y tenías que poner un stage, etcétera.
Ahora todo eso ha desaparecido. Nos hemos quedado con arroba State, arroba Bindable y arroba Environment. Ya está, no hay más. Ok. Y los arroba observables para las instancias de datos.
Queremos que sean observadas o el mobile si queremos usar el nuevo switch data. Entonces todo se ha mejorado muchísimo Pero si todas esas mejoras solo existen a partir de años diecisiete, yo tengo un problema, porque si quiero poder, si quiero hacer una app que tenga todo lo nuevo, la tengo que hacer solo para iOS diecisiete y me dejo fuera un montón de dispositivos, porque ahí fuera hay muchos iPhone diez todavía, o muchos iPhone ocho y ocho plus, y me los dejo fuera, igual que ya me dejé en su momento fuera a los siete, siete plus, seis, ese, entonces y a una serie de modelos de iPads. Entonces, No, esa no es la solución. Porque entonces yo tendré que hacer dos apps totalmente distintas. Tendría que hacer una app para iOS diecisiete con toda la nueva arquitectura, y una app para versiones anteriores con una arquitectura totalmente distinta y menos suficiente.
Entonces no tiene ningún sentido. El problema es que Apple es Apple y no cuenta nada, no adelanta nada ni asegura nada. Pero yo, entiendo, supongo que como técnicamente pueden hacerlo porque ya tienen las herramientas para hacerlo, es cuestión de tiempo que al final termine todo Suip Yoi por ser retrocompatible hasta iOS trece. Con esto que os he contado del back de Bloyd porque así yo puedo usar todas las nuevas herramientas y sobre todo lo más importante ya no es la nueva herramienta, la nueva formas. No, es que el gran cambio es Swiss Data y es el nuevo, la nueva arquitectura, basada en observables y por supuesto toda la parte que se ha incluido en años diecisiete de las macros que cambian radicalmente el trabajo con Swift y lo mejoran llevándolo a un nivel de posibilidades que no habíamos tenido hasta ahora.
Una macro es un elemento que se coloca a nivel de runtime, entre mi binario y el código compilado y que transforma los elementos incluso los puede evaluar a nivel runtime. Una Macros lo que ahora yo puedo hacer con un hash preview para poder tener las pre views de sub UI y que además también permite hacer pre views en UI y kit. Entonces, que todo eso yo no lo pueda tener, si no estoy en la última versión de años, no tiene ningún tipo de sentido, sobre todo cuando tenemos las herramientas para poder arreglar este problema. Así que bueno, pues esperemos que Apple esté trabajando en ello, como diría aquel, y tarde o temprano, veamos este cambio tarde o temprano nos anuncia que toda la API completa de Suip UI, más Suip Data, más los observables, más los elementos de las macros, etcétera, etcétera, pues son retrocompatibles, porque las macros forman parte del lenguaje swift y sí van a ser retrocompatibles. Pero lo que no tiene ningún sentido es que las macros que Apple ha hecho para la parte de programación propia suya para los frameworks de programación suyos cerrados no lo sean cuando las macros en sí sí lo son, ¿de acuerdo?
Por lo que En fin, yo entiendo que esto es cuestión de tiempo, Apple ha sacado muchísimas, muchísimas novedades este año en la WWC, entiendo que ha sido un trabajo titánico y entiendo que insisto como decía que él están trabajando en ello y que tarde o temprano tengamos este cambio. Se agradecería muchísimo por parte de Apple que alguien públicamente dijera sí, no os preocupéis, estamos haciendo este cambio y llegará todavía no sabemos cuándo porque es mucho trabajo pero va a estar vale eso haría que estuviéramos mucho más tranquilos Así que, a esperarse dice, se toca y a cruzar los dedos. Poco más, Y poco más, muchísimas gracias por estar ahí, por seguir pues estos podcasts tanto en formato de audio como en formato vídeos espero que les haya gustado pues lo que hemos contado espero que le hayan entendido creo que es un cambio muy importante es algo realmente espectacular todo lo que ha presentado Apple en iOS diecisiete, pero no podemos olvidar que como programadores no podemos dejar fuera a todos los usuarios que tienen dispositivos que quedan obsoletos porque son un número muy importante y porque ellos también tienen derecho a seguir recibiendo servicios y lo que no tiene ningún sentido es que yo tenga que prescindir de todos ellos por querer estar a la última y poder ofrecer las últimas herramientas a los desarrolladores.
Así que Insisto, espero que Apple esté trabajando en esto y esperemos que tarde o temprano aparezca, si es posible, más temprano, que tarde. Así que lo he hecho si les ha gustado por favor déjenos un like, un comentario, un lo que sea en ese sentido saben que pueden encontrarnos en redes sociales a mí personalmente como arroba jfmunoff o arroba papel barra godín en twitter también en twitch twitch punto v barrapelcodín todos los sábados a las seis de la tarde, y poco más, muchísimas gracias, un saludo, got, Applecover.
Puedes escuchar más episodios de Apple Godín en Cuanda.com La comunidad de podcasts independientes en español