¿Y qué hago yo con esta app tan antigua?

00:00 /2h30

Arturo y Julio vuelven a la carga con un nuevo Caffè Swift para contarnos la actualidad del mundo del desarrollo y hacernos meditar compartiendo sus experiencias como desarrolladores.

En esta ocasión hablamos sobre todas las novedades que nos trae la IA y el plan de Apple a futuro, os contamos cómo será el unit testing en Swift a partir del próximo año con una nueva librería o las mejoras en el motor WebKit en cuanto a su compatibilidad con los estándares abiertos.

Y por supuesto, hablamos en la parte de un tema clave contestando una pregunta de uno de nuestros oyentes: ¿qué hacer en caso que nuestra app se quede vieja? ¿Cómo gestiono una app de varios años que representa un problema de coste y tiempo muy importante para ser mantenida o puesta al día? ¿Qué estrategias puedo seguir afrontar ese reto? 

A través de su experiencia de muchos años, Arturo y Julio nos dan su opinión cada uno y cómo han afrontado ellos ese problema en el pasado.

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 para seguir el podcast también en vídeo: Caffè Swift en YouTube

Arturo Rivas

Julio César Fernández

Transcripción

Cuonda, la comunidad de podcast independientes en español. Bienvenidos a CAFÉ SWIFT, el podcast donde hablamos del lenguaje de programación SWIFT de Apple, solo no. Hablamos de programación, de herramientas para desarrolladores y de distintas experiencias, pero siempre desde el punto de vista de desarrolladores en entornos Apple y del lenguaje SWIFT. Y esos desarrolladores somos Arturo Rivas y Julio César Fernández.

¡Comenzamos! Hola hola hola, hola a todos, bienvenidos a otro CAFÉ CON SWIFT. Ya tercera temporada, ya un poco rodada y hemos dicho, vamos a aprovechar que Tim Cook anda por Madrid para que, por supuesto, no se venga a CAFÉ SWIFT. No, a ver, quería venir, pero le hemos tenido que decir, no mira Tim, nos pilla mal y tal, tenemos obligaciones, ya si eso quedamos otro día, etcétera. Entonces, bueno. Estamos mucho con lo de la programación y ya sabemos que a ti te van otras cosas.

Exacto, sí, sí, comer cocido y tal. Le vas a aburrir al pobre señor aquí dándole la chapa con SWIFT, no venga. Totalmente, totalmente. Agradecemos que haya querido venir. Es un detalle, es un detalle por su parte, la verdad, se agradece, Tito Tim. Y nada, pues estamos aquí otro día más con un café como siempre cargado, o sea, no sé cuándo haremos un café ligero y no me lío más porque, como siempre, tenemos

un montonazo de cosas de las que hablar, así que empezamos con nuestra primera sección en la que os contamos qué hemos estado haciendo. Bueno, de hecho, por darle tiempo a que termine la cabecera musical, hoy lo que vamos a hacer es dedicarnos a responder dudas que teníamos ahí acumuladas de gente que las envía a Cafeswift con dos Fs, arroba gmail.com. Así que si tenéis cualquier tipo de duda, pregunta, cuestión que queramos que tratemos

en el programa, pues podéis enviarlo y podemos hacer como ahora. Entonces, yo creo que ahora ya sí habrá acabado la música de cabecera. Pero es que no soy yo profesional de los podcasts. Sí, bueno, es que es cuestión de medición, tiene que, para que dé tiempo a que se acabe, así que… Los enviados digitales también me han echado la broca a veces por cosas de estas. Nada, nada, esto no tiene… si no, yo me… ya has visto que no tengo capacidad de enrollarme

sin ningún problema. Así que ahora sí, comenzamos. Pues cuéntanos Arturo, ¿qué has estado haciendo durante estos días desde la última vez que grabamos? Pues muchas cositas, porque yo creo que lo comenté, que ya volví otra vez al trabajo después de las vacaciones y la gente con muchísimas cosas que hacer, con nuevas versiones de EOS y hoy os voy a contar mis penas, también tiene que ver con las versiones de EOS, pero

más con la nueva versión de Xcode. Xcode 15, qué bonita. Efectivamente, qué bonita. Pues yo soy muy de, en cuanto se puede, obviamente depende del proyecto y hay que tener en cuenta más cosas, pero yo soy muy de actualizar y sobre todo porque yo me gusta también actualizar mi ordenador al siguiente sistema y en Sonoma, que sale oficialmente en un par de días, pues no funciona la versión anterior de Xcode, la 14.3.1, solo funciona Xcode 15.

Entonces, claro, digo, pues lo primero que tengo que hacer es que mis proyectos compilen todos en Xcode 15 sin problemas. Y este aquí que me encuentro, me he encontrado tres problemas, empiezo por el primero. No, I can't believe it. El primero y que más o que más esperable era es que el gran gestor de, bueno, gran no, el gestor de dependencias Coco Pods no se había actualizado, ¿vale? Me pinchas y no sangro.

Pues la última actualización creo que era de abril, ¿vale? Y pues tenía varios problemas. Había workarounds, cambiando cosas en el pod file, pues eras capaz de hacerlo, ¿vale? Pero no me convencía mucho esta solución. Y ayer por la noche creo que fue, o antes de ayer, ya han compilado, vale, una versión, ya hay una, lo digo de memoria, una 13.1 creo que es, que ya tiene este parche, ¿vale? De hecho, había una, el github es abierto, ¿vale?

Es un proyecto open source y tal, que estoy viendo que cada vez tiene menos apoyo. Una de las cosas por las que no estaba actualizado y yo fui uno de los que escribí un comentario de todavía, porque había varias personas pidiendo que lo actualizasen y ya de repente me llegó la notificación de que habían contestado, habían cerrado esa issue de github diciendo ya he puesto a compilar en cuatro horas o así y estará disponible la versión K.

O sea, corrégeme si me equivoco, ¿vale? El martes día 12, el martes día 18, no, perdón, el lunes día 18 fue cuando salió Scope 15, versión final en el App Store, ¿vale? Que al que le dio a descargar probablemente hoy domingo ya tiene que estar terminando y, pero no funcionaba, es decir, que con la versión final en la calle han tardado X días en corregir que se pueda usar CocoPods en Scope 15.

Como lo has dicho, Julio, es... Ya sabéis, niños, no uséis librerías de terceros y, sobre todo, no uséis la librería que permite instalar librerías de terceros. Pues bueno, tenemos un primer culpable, CocoPods. Vamos a por el segundo culpable. El primero, sospechoso habitual, me lo esperaba. Segundo paso. Pues de repente consigo compilar con el walkaround este que os comenté del podfile y explota la...

Me pongo a navegar un poco por la aplicación y explota. Jope, ¿qué será? De repente veo que al acceder al perfil, digamos, del usuario en la aplicación, explota, ¿vale? Y veo que explota con algo de... con una imagen que utilizo el renderer porque se puede renderizar o bien la imagen, ¿vale? Si hay imagen, es una vista un poco extraña, pero bueno, renderiza si hay imagen. Y si no, lo que hace es renderizar la vista como imagen, ¿vale?, para trabajar siempre

con formato de imagen y es las iniciales del nombre del usuario, por si el usuario todavía no ha subido la foto. Y resulta que la librería que estaba utilizando o una función de la librería que estaba utilizando estaba deprecada. Pero lo que me mosquea es que el proyecto compila sin problemas, pero casca en la versión... Cuando lo compilas contra el SDK de iOS 17. Pues eso no es un deprecado, eso es un obsolete, o sea, eso es que lo han quitado directamente

y se les ha olvidado marcarlo como obsolete para no dejarte compilar. La idea es esa, que no te deje compilar, ¿por qué? Porque imaginaros que yo no pruebo eso y la saco así porque digo, a ver, esto me compila. La idea es que se puede haber un gliss de alguna vista que no se dibuje, cosas que empañen un poco el uso, pero que explote directamente debería ser algo contemplado antes de... O sea, en tiempo de compilación, ¿vale?

Entonces el segundo culpable es Apple, que no diría... Que a veces hace estas cosas, no es el punto habitual, pero... Es el problema. Ya sabemos que, por ejemplo, en SwiftUI este año ha habido bastantes cambios de deprecación. Por ejemplo, en SwiftUI, por sin ir más lejos, ¿vale? De pronto han decidido que las Toolbars ya no se llaman Navigation Leading Bar o algo así, Navigation Trailing Bar, sino que ahora se llaman Top Bar Leading y Top Bar Trailing,

¿vale? Y por qué patata. Han decidido, que es mi favorita, que el Corner Radius ahora ya no se puede usar y haya que usar el Clip Shape, entonces donde antes ponías una instrucción muy corta, ahora tienes que poner una instrucción bastante más larga. En fin, tonterías, pero al final una deprecación es algo que sigue funcionando, pero que Apple recomienda que te cambies porque en algún momento, en futuras versiones, pues ya no

será usable. Te pone un warning en Scode, que a mí me da TOC. Sí, sí, no totalmente. Me da un obsesivo compulsivo brutal, yo no puedo tener ni un solo warning en mi código. Por eso... Claro, pero te pasan cosas como que cuando migraron al Split View o el Navigation Stack, yo tenía un montón de Navigation View que tienes que dejar, porque en Nios 15 no existe el Navigation Stack. De hecho, el Navigation View Content, si está, o sea, el Navigation View Content no está

deprecado. Están deprecados la clase y está deprecado todos los inicializadores del Strut, salvo el Navigation View Content, porque efectivamente, si tienes Nios 15, tienes que hacerlo con Navigation View. No con este Navigation Stack. Pues eso, tendremos que convivir con esos warnings. Sí, pero bueno, a mí lo que me preocupa es eso, que estés usando una función que teóricamente, bueno, que vale, que está deprecada, genial, pero si compila es porque

sigue estando. Por lo que, en fin, eso es un problema bastante, porque colgar una aplicación de Swift es bastante complicado, ¿vale? O sea, colgar una app de Swift ya tiene que ser algo muy gordo, pero, hombre, en fin. Y ya, esta te la pasé indignado, porque de repente digo, jope, como que veo que las fuentes que son negritas, luego nos dejan en el Storyboard, porque esta aplicación utiliza Storyboard,

luego no son negritas, me las cambia, luego entro a una de esas vistas, vuelvo a asignar la fuente, vuelvo otra vez a la aplicación y pone la correcta, pero en otra vista hago lo mismo y no pone la correcta, y me da por buscar por internet a ver qué dice la gente y me llevan a una captura de los, de la Release Note, que siempre salen en las versiones de, tanto en las betas como en las versiones finales, y en el apartado de conocido por todos y temido

por todos llamado Known Issues, para los que no sepáis inglés, eso, Problemas Conocidos, aparece que quizás no se resuelvan, como es, que quizás no aparezcan correctamente las fuentes definidas en el Storyboard. Y yo, no, me estás vacilando. Y sin ningún workaround ni ninguna manera, porque me dices, no, entras y vuelves a setearlas, o yo qué sé, cualquier cosa.

No, no, que es así, entonces, cualquiera que tenga una aplicación con Storyboard no puede lanzarla compilada con Scouse 15. Lo que me lleva a pensar, Julio, es que yo creo que veremos un Scouse 10, o sea, 15.01, o incluso 15.1, lunes o martes antes de que salga Sonoma. Y Sonoma no salió justo a la vez que EOS, quizás por algo de esto, porque te obliga a utilizar Scouse 15 y Scouse 15 no estaba ya para utilizar.

Porque otros años han esperado octubre porque había nuevos Mac, este año lo han adelantado porque no hay nuevos Mac, pero ese decalaje de una semana respecto a EOS, no lo sé, es mis cábalas, mi bola de cristal más pequeña que la tuya. De hecho, ya estoy viendo aquí la captura que me enviaste, y efectivamente pone Interface Builder Documents, a los documentos de Interface Builder que usen fuentes de app personalizadas, podrían cargar incorrectamente la fuente

en ejecución. Workaround, pon la fuente manualmente en código. O sea, de verdad, voy a llenar, mira, he mentido, que he dicho que no había Workaround, pero es que qué Workaround es, me he metido en todas las vistas de la aplicación para hacerlo por código, en serio. Cuando lo tienes ya seteado perfectamente, eso te obliga a hacer outlets de cada componente, poner tal, o sea, es un show importante.

Pero eso me da a entender, yo en los últimos años he visto que Apple ha dejado de prestar atención a UIKit, y por ejemplo, tú sabes perfectamente que es muy normal que en las últimas versiones el renderizado de los Storyboards haga cosas raras, te cambie cosas, de pronto pones una constraint correcta y te hace una cosa súper extraña. Es decir, cuando yo he tenido que formar a la gente en UIKit, porque todavía en el Bootcamp formamos en UIKit, porque el Bootcamp al final es todo el espectro de formación, y por lo tanto no

podemos obviar la parte de UIKit. Pero cuando yo doy UIKit, me doy cuenta efectivamente que Apple es como que lo está abandonando poco a poco. Es mi impresión, no sé cómo lo ves tú. El error de este que se te queda el Storyboard con un error y no se reflejan bien, se queda así como raro.

Puedes seguir usándolo, pero se queda como raro. O que de repente le das a la vista de asistente y te aparece una vista no JTC, digamos de la clase en sí, no de tu clase especializada, si de la interface que tiene definido y tal, cada dos por tres. Hace dos versiones así, hicieron la de, mira ahora cargan más grande, perdón, cargan más rápido en proyectos en Storyboard grandes.

Pero yo creo que llevan ya por lo menos dos años haciéndole caso justo, pero a ver lo que digo yo, hazle caso justo. Pero tío, no me metas un error de estos en la versión final. Yo espero que mañana o pasado veamos cuando ya pongan, mira ya tenéis Sonoma, que tenéis lo que digo, obligatorio Scout 15, que es otra cosa que me extraña. Creo que otros años sí que cuando eran betas no funcionaban las versiones anteriores de Scout, pero en la versión final del sistema, en la Release Candidate, sí funcionan.

Porque si por lo que sea tú necesitas una versión antigua de Scout, deberías poder. Pero creo que se puede porque puedes parchearlo, es decir, puedes entrar dentro de Scout, cambiarle no sé qué cosa en el InfoPolis o alguna puñeta de estas y conseguir que funcione. Creo que se puede hacer, pero efectivamente yo recuerdo que el año pasado, el año pasado creo que fue el primer año en el que la versión nueva del Mac, yo no me la puse hasta el final porque dejaba de funcionar Scout 13.

Entonces yo no sé quién ha tomado esa decisión o el motivo de esa decisión, pero desde luego me parece una muy mala decisión. A ver, el motivo entiendo que es porque ahora las SDKs están por separado y entonces no puedes cargar la SDK de MacOS de la versión anterior de MacOS porque la SDK de MacOS la coge directamente del propio sistema operativo.

Pero si no, pues ponme la SDK de la versión anterior, me da igual o por lo menos en iOS. Había un workaround en otros años, porque claro tenía que poner a investigar, y era que cogías porque cada versión de Scout, si entras dentro de los archivos, tiene los runtimes de cada versión de iOS que tengas. Y podías coger la versión, porque uno de mis problemas era también que tenía un dispositivo de pruebas que se me actualizó. Supongo que no me di cuenta porque eso de que se me actualizó solo es mentira,

por lo que sea mejor me aparecieron ahí y le di. Lo actualicé a iOS 17. Entonces claro, un dispositivo en iOS 17 yo no puedo debuggear una aplicación con el Scout anterior, porque el Scout anterior no tiene el runtime de en este caso de iOS 17. Entonces yo miré y había como un truquillo otros años en que entrabas en las carpetas donde estaban todos los runtimes y cogías el del Scout nuevo y lo metías el 17.

En este caso lo copiabas y lo metías en el antiguo. Pero este año estaban todos en la versión de Scout 15 todos los runtimes hasta la 16.4, que creo que fue la última vez que cambió, pero no estaba el de iOS 17. No sé por qué ahora han metido lo de los runs. Supongo que por esto que comentábamos, que vienen los SDKs por separado, o sea, digamos los runs.

Bueno, sí, las dos cosas, los runtimes y los SDKs por separado. Y a lo mejor ya los meten en otro directorio, no tengo ni idea, pero ya no estaba ahí. Entonces uno de los Workaround que había, pues no lo pudo hacer. Pero bueno, Periplo. Todos los años creemos que estamos preparados junio, pero siempre con las nuevas versiones siempre hay algún drama para los desarrolladores.

Siempre, siempre, siempre. Sí, pero bueno, aún así tocamos madera, ¿vale? Es decir, yo he usado otros IDEs, como por ejemplo, sin ir más lejos, Unity, que tú también lo has dado ahí una formación. No sé si luego has tenido tiempo de dedicarle a Unity, pero Unity, el cambio de un proyecto a una nueva versión, puede ser un drama muy triste.

Me pasó que un día cuando estaba haciendo el curso, cogió y instalé el nuevo, no sé cuántos, y cogí y me volví a ver cómo instalar el antiguo, porque digo, para el curso este voy a perder más tiempo en pasarlo de una versión a otra que haciendo el curso.

Efectivamente, entonces bueno, y luego aparte no podemos olvidar algo que pasa con Scope 15 versión final, y es que yo sigo teniendo Scope 15 beta aparte de la versión final. Y diréis, ¿por qué? Porque la versión final desaparecen Vision OS SDK y Reality Composer, porque no están en la versión final.

Reality Composer Pro es una herramienta que pertenece a la SDK de Vision OS y todavía no está en versión final, por lo que tienes que tener o Scope 14. Es decir, si tú usas Reality Composer como herramienta, sólo tienes dos opciones y si estás en Sonoma, sólo tienes una. Si estás en Ventura, es tener Scope 14 y Scope 15. Para tener las dos versiones, lo único que tienes que hacer es renombrar el punto app, o tener la aplicación esta que se llama Scopes, que te permite gestionar, y una app que se llama Xcodes, que te permite

gestionar y tener varias instalaciones de Scopes a la vez. Entonces esa aplicación te permite tener varias y poder elegir cuál quieres usar, cuál tal, no sé qué. Si no, pues simplemente renombráis el Scope 14 como Scope 14 punto app, instaláis la 15, que se llamará Scope punto app, y podéis tener las dos a la vez.

Esa es la única manera de, en Ventura, tener Reality Composer. Pero como Scope 15 cambió Reality Composer por Reality Composer Pro, que es la versión que viene con Vision OS, y Vision OS todavía está en beta, pues Reality Composer Pro y Vision OS SDK no están en la versión final de Scope 15. Por lo que si quieres seguir trabajando en Vision OS, como es mi caso, tienes que dejarte la beta 8, que es la última de Scope 15 instalada, junto a la Scope 15 final, que es la que tienes a todos los efectos.

Yo entiendo que, porque esto lo estamos grabando el domingo 24, y Sonoma sale el martes 26, si no recuerdo mal. Entonces cuando salga Sonoma, como ha dicho Arturo, yo comprendo, entiendo, supongo, de hecho probablemente estéis oyendo este episodio y ya habrá salido, que habrá una versión de Scope que parchee cositas, ¿vale? Pero lo más importante, que salga la beta de la 17.1, porque la beta de la 17.1 debería de traer la beta 4 de Vision OS SDK, y por supuesto la beta de Reality Composer Pro, que yo entiendo

que es una aplicación que aún no está para ser lanzada, y por eso no se ha incluido en Scope 15, ¿vale? Por lo que si necesitáis esa herramienta, si necesitáis Reality Composer, pues eso es lo que tenéis que hacer. O ponéis Scope 14, o ponéis la beta de la 15 a la vez de la normal, ¿vale? Estas son las cositas que tiene Apple, ¿vale? Yo entiendo, supongo, que una vez salga Sonoma, pues no lo sé, habrá un, al menos un parche para estas cositas, ¿no?, de tal, y luego no

podemos olvidar que está todavía ahí, y que está en el aire, saber si se arreglará o no, el tema de la concurrencia de procesos en Swift Data, ¿vale? Que esto es una cosa que yo puse como fallo en Apple, que nadie me ha contestado, que nadie me ha hecho caso. Yo cruzo los dedos a que alguien lo haya leído, aunque no me hayan contestado, me da igual que no me contesten, me da igual que no me den crédito de nada, me importa poco, pero es un lío que incluso,

acuérdate, que hasta Sean Allen, el divulgador de desarrollo de Swift y tal, pues llegamos a cruzar tweets, ¿no?, preguntando cómo funcionaba y tal, porque él se dio cuenta de que pasaba lo mismo, de que Swift Data no funcionaba en concurrencia, que tú le decías que fuera concurrente, pero luego, a la hora de la verdad, siempre funcionaba sobre el hilo principal, y por lo tanto estaba bloqueando el hilo principal, porque aunque tú pusieras un task,

luego al final todo el proceso iba contra el main actor, y por lo tanto te paraba el hilo principal. Hacía un main actor ahí en el medio, un main actor punto RAM. Sí, sí, sí. Para correr eso. Porque tú lanzabas, o sea, tú ahora mismo lanzas, cuando te montas, claro, el principal problema es que el container de Swift Data solo te ofrece un context, que es un main context que está unido al main actor y que solo se puede usar dentro de un closure o dentro de una función que

es arroba main actor, ¿vale? Por lo tanto, lo que estás haciendo es elevar el permiso de eso. Como ya hablamos aquí, cuando tú, hasta la beta 6 creo que fue, cuando se actualizaba un contexto en segundo plano de Swift Data, la interfaz no se daba cuenta, no se actualizaba. Tenías que cerrar la app y volver a abrirla.

En la beta 7 lo arreglaron, pero con la coña marinera de que lo que hicieron fue elevarlo todo al main actor, ¿vale? Entonces ahora lo hace todo en el hilo principal para que así Swift UI sea consciente de ese cambio. Pero claro, lo que han hecho así es tropear la concurrencia de Swift Data. Entonces ahora todo Swift Data, si tienes procesos normalitos que no consuman mucho, bueno, pues la interfaz no se va a dar mucha cuenta.

Pero si tienes procesos concurrentes en batch, como tengo yo, de mil, mil y pico registros que se cargan al inicio de la app, pues es que te has metido en un lío importante. Entonces, en fin, es un poco de aquella manera, ¿vale? Entonces, en fin, hay que tener... Bueno, pues esperemos que arreglen esto de alguna manera, porque si no, en fin, yo no sé cómo puede ser, ¿vale? Y luego, aparte, hay otra cosa con Swift Data que es, de nuevo, la vuelta del mismo problema.

Y es que todo el mundo no quiere poner las queries en las views, ¿vale? Ya era un problema con CoreData, porque los FedRequest había que ponerlos en la view, porque si no, no capturaba el contexto que estaba inyectado como dependencia en toda la app. Y, por estructura, se sigue funcionando igual con el nuevo ArrobaQuery, por lo que el ArrobaQuery tenéis que seguir poniéndolo en la view.

No os gusta, lo siento, pero no hay otra forma, ¿vale? Porque tiene que conectar con el contexto que está inyectado a nivel de dependencia. Y como lo hagáis vosotros dentro de un Observable, da igual. Cuando ese dato se actualice, la vista no se va a enterar y no tenéis los datos refrescados en tiempo real. Así que...

Y esto es algo que, pues, no creo que lo arreglen en ningún momento, porque... Bueno, pues, ¿por qué no? A pesar de tener el ArrobaObservable, que está bastante bien, ¿vale? Pues sí, menudo galimatías de scodes, de versiones, y por si fuera poco, Julio, pedimos en su día un suite data, pero se nos olvidó decir que lo hicieran bien. No pusimos ese pequeño matiz. Se daba por supuesto, macho. Claro, no, no. Ese es el problema, que lo dábamos por supuesto. No hay que dar por supuesto.

Así que, nada, esos son mis dramas. Si no hubiese sido drama esta mañana, Julio, encontrar un puñetero cable por casa que funcionase con CarPlay en el iPhone 15... Porque eso es. Cuéntanos, porque tienes nuevos dispositivos, ¿vale? Entonces, vamos a un poco de salseo, ¿vale? Porque al final es parte de lo que has hecho, ¿no? O sea, tienes...

Has renovado flota, ¿no? Enséñanos qué has renovado. Sí, pues, nada, me he lanzado a los nuevos iPhone, ¿vale? Como tenía un 14 Pro, pues, he cogido directamente un 15 Pro, porque el 15 Pro Max me parece demasiado grande y yo tampoco soy muy amante de las fotos. Pero precisamente en el tema de las fotos es donde me está gustando mucho, porque a mí lo que me gusta, y iPhone creo que tiene mucho de eso, es lo saco del bolsillo, he hecho una foto y ya está.

Y quiero que esa foto salga las mayores veces posibles bien, ¿vale? Que luego no la esté mirando y diga, joder, vaya mierda de foto que he hecho y me he perdido de hacer una foto buena en ese momento. Y me está gustando muchísimo. Por la noche estoy alucinando porque noto muchísimo menos grano, porque siempre notaba en la cámara del 14 Pro, sobre todo por la noche, pero también de día depende de lo que estuvieras haciendo fotos o depende de los colores que tuviera, veía...

o sobre todo yo creo que al telefoto, el telefoto tenía bastante grano y ahora lo estoy notando bastante mejor. Y sobre todo otra cosa que me ha flipado es el modo retrato a posteriori, ¿vale? Ahora tiene modo retrato, pero también puedes hacer una foto normal y te aparece, si él detecta que hay una persona o un animal o tal, te aparece como la F para activar el modo retrato.

Pero si en el momento no lo activas, luego al editar la foto puedes escoger el retrato. Y un par de fotos en las que no había hecho retrato, le he dado el toque ese del difuminado y ha quedado muy bien. ¿Por qué? Porque yo creo que con el nuevo... las nuevas capacidades que tiene el chip A17 Pro han mejorado los algoritmos para hacer ese degradado... para hacer el degradado no, sino digamos para separar lo que degrada es de lo que no. La profundidad de lo que es lo que es la segmentación de la fotografía creando el

mapa de profundidad. Y lo pilla muchísimo mejor. La verdad es que no me lo esperaba que en esa parte, porque luego sí que me esperaba pues eso más más ligero, el bisel este de los bordes bien, menos menos... o sea se nota que es un poco más pequeñito, que eso está está guay, pero sobre todo el bisel este que sea más ligero lo hace más manejable, que eso ya lo esperaba, pero la foto me ha sorprendido gratamente.

Claro es que, a ver, hay que tener en cuenta que los iPhones nuevos con el A17 Pro tienen un nuevo motor neural que duplica, duplica la potencia de la anterior, ¿vale? La potencia de la A14 Pro era en el motor neural de 17 billones con B de operaciones por segundo, y el nuevo que tiene la A17 Pro sube a 35 billones con B de operaciones por segundo. Eso le ha permitido pues lógicamente tener un algoritmo de mayor precisión en lo que es la

división, lo que es el cálculo del mapa de profundidad, la segmentación de la fotografía, a través de Machine Learning, pero fíjate que me resulta muy curioso lo que me cuentas, porque las cámaras gran angular y ultra gran angular de los 15 Pro y de los 15 Pro Max son exactamente la misma cámara que el 14 Pro.

O sea, no ha habido cambio a nivel de hardware. Sin embargo, fíjate que el telefoto sí es nuevo. Pues el telefoto, yo creo que esas fotos son las que antes me salían con mucho grano y ha mejorado bastante. El telefoto sí es nuevo, el telefoto del tanto del Pro como del Pro Max, el del Pro Max es obvio que es nuevo porque tiene el tetraprisma, que es el que hace el tema del poder tener una profundidad de campo tan grande, pero el del 15 Pro, perdón, ese telefoto 3X sí es nuevo.

Por lo tanto, ahí aunque tiene la misma apertura que el anterior de f 2.8, pero es cierto que al ser mejor tener un sensor de más calidad, pues obviamente también repercutirá. Pero fíjate lo curioso que al final el ISP, el procesador de señales de imagen, que es el que se encarga de coger lo que saca la cámara y procesarlo para darte una foto que esté lo más bien posible, lo más bonita posible, ese cambio de ese chip hace que el mismo exacto hardware saque mejores fotos.

Esto es una cosa que es bastante... Como en su día las mejores fotos hacían estas comparaciones, no sé si fue... Bueno, hay algunas que son muy chorras, pero creo que fue Marques Brownlee el que hizo una comparación y creo que salía el Pixel que de aquí hace, te estoy hablando de hace cuatro o cinco años, el Pixel que era el único que tenía sólo una cámara y era el que mejores fotos hacía.

¿Por qué? Porque hacía procesamiento posprocesado en la nube con un algoritmo muy potente que conseguía que esa foto, con el peor hardware o un hardware peor que otros que tenían dos cámaras, saliese mejor el resultado. Esto es igual, con el mismo hardware consigues mejores resultados. Pues es curioso.

Yo tuve la ocasión de probarlo, de probar el 15 Pro, básicamente verlo. Y también el tema del agarre, el hecho de que las esquinas no sean totalmente rectas y tal, pues la verdad que le da un punto interesante. Y luego aparte también has hecho el otro cambio más. A ver, a ver, levanta, levanta. Tenemos ahí un Apple Watch Ultra 2. Cuéntanos cuáles son tus impresiones, porque vienes de un Series 8.

Series 8, o sea que has hecho un cambio del modelo normal. Del modelo anterior, bueno sí, del Ultra. Pero del Series 8 de Wi-Fi, o sea que vienes del de aluminio al titanio. Efectivamente, y la verdad que tenía un poco de miedo. O sea, yo cuando salió el Ultra dije, el Ultra a lo mejor no es para mí. Pero luego de hecho me picó, cuando hicimos el directo de la presentación, me picó María porque hablaba como muy segura y muy convencida de qué buena decisión.

Y dije mira, pues voy aprovechando que esto que tiene Apple, que lo puedes probar, no sé si son 15 días o un mes, digo mira pues voy a actualizar al Ultra y si no me gusta, oye, pues me vuelvo a un Series normal. Y la verdad es que estoy encantado, porque la pantalla se nota, se nota que es más grande. El brillo, no había echado de menos mucho brillo.

Sí que se ve muy bien, pero ahí te diría que normal. No es incómodo porque yo duermo con él, entonces tenía miedo de que me molestase. Para nada, la verdad es que es cómodo. Yo tengo una muñeca pequeñita, he cogido el modelo de correa, hay creo que tres tamaños, pues el más pequeño y lo que sí que he notado... Yo me flipa el más grande, o sea que... Pues me flipa lo de la batería.

O sea, yo lo utilizo mucho, pero muchas veces, por ejemplo, cuando salía fuera de casa, si salgo solo voy escuchando podcast siempre, entonces claro, si voy tirando del reloj, normalmente lo suelo intentar tener descargados, pero como utilizo la aplicación de podcast de Apple y no hay manera de decirle quiero tener descargados esto, sino le pones los últimos y él te va descargando, entonces hay veces que quiero escuchar un podcast que no tengo descargado.

Entonces claro, tira mucho de batería eso y muchas veces llevaba el móvil simplemente por el tema de escuchar podcast y ahora el dejármelo en casa, estar escuchando podcast, dándole una tiza, durmiendo con él y demás. Y es que creo que lo he cargado una vez en todo esto y porque estaba el 50%. O sea, lo de la batería es brutal. Lo que me hace todavía más Julio, que ya lo dijimos en su día, desear que haga un puñetero iPhone así.

O sea, un iPhone que le pueda meter toda la tiza que quiera y que llegue tranquilamente. O sea, el día lo pasan bien, salvo casos excepcionales, como por ejemplo unas llamadas de FaceTime, que ahora yo hago mucho FaceTime con las abuelas de mi hija y eso el FaceTime funde la batería de los puñeteros iPhone. Entonces me hace desear más un iPhone.

Las llamadas de FaceTime ahora usan mucho Machine Learning y todo ese tipo de cosas para el tema de la voz, efectos de profundidad, no sé qué, la transcripción que la puedes activar también, cosas así. Pues sí, entonces es lo mejor que le he encontrado. El salto de batería. Sobre todo, a ver, claro, en un iPhone a lo mejor no es tan importante porque cuando estás durmiendo el iPhone lo tienes conectado, cargando.

Pero claro, el Apple Watch, si lo utilizas para dormir, no te lo quitas en todo el día. Entonces, bueno, de hecho lo que he hecho es poner el cargador rápido en el baño para cuando me ducho. Porque sí que hay diferencia. Ya en el Series 8 lo notaba. Tengo un cargador rápido y de cargarlo con el rápido a cargarlo con uno normal se notaba un montón.

De hecho, eso, yo que no me lo quiero quitar, me lo quiero quitar el menor tiempo posible, pues muchas veces tenía que quitarme lo demás por eso, porque si no, no llegaba, no llegaba al final. Bueno, al final del día no, pero sí que hay días que como no estuvieras atento te podía no durar el día. Pero no has sentido la sensación, la premura en tu físico de ir a bucear o de hacer alpinismo o de cruzar sin mirar si está en rojo o no el semáforo.

Es decir, no has tenido esos impulsos. No, de momento no. He ido ayer a Faunia. No sé si cuenta como actividad de riesgo. Ostras, había un emú que venía con... Tenía mala pinta. Madre mía, mi vida. En fin, pues nada. Yo, como ya sabes, estoy esperando mi Ultra 2. Yo salto desde el Series 4, por lo tanto ya es un salto importante.

Y bueno, pues a ver si llega en algún momento y puedo empezar a disfrutarlo. Por cierto, antes de que nos cuentes lo que has estado haciendo, una de las cosas que has estado haciendo el viernes es salir a la calle a probar la demo que traen el iPhone 14 Pro para las llamadas por satélite que se han activado en España. Pues no.

Pues yo el único salí, salía a mirarlo en la calle en cuanto vi la noticia de que se había activado y dije, seguro que no soy el único tonto que está aquí mirando así para los lados. El que te dice, oriéntalo para acá, oriéntalo para allá a los satélites. Seguro que no soy el único tonto que está haciendo esto. No, no, de hecho ni le he prestado atención. Pero bueno, por si no lo sabéis, pues efectivamente se ha activado en España la cobertura de llamadas de emergencia a través de satélite.

De forma que si por lo que sea, esperemos que no, tenéis algún tipo de accidente, aunque sea en una zona sin cobertura, el teléfono va a ser capaz de hacer la llamada de emergencia a través de conexión satelital. Si no recuerdo mal, es un año gratis y luego hay que pagar, me parece. Me pillas. Creo que sí, creo que sí, que es un año gratis y luego si lo quieres seguir manteniendo tienes que pagar por ese servicio.

No sé, por el hecho de que al final es un servicio que a Apple no le sale gratis. Entonces pues eso te lo ofrecen el primer año y luego ya te lo cobran. Pero vamos, no sé, no lo he probado la verdad. Pues nada, muy interesante. Cuéntanos, Julio, qué has estado haciendo, que ya sabemos que no ha sido probar las llamadas satelitales.

No, pues lo que he estado haciendo ha sido, pues aparte de estar a pocos metros de Tim Cook sin saberlo, pues también he estado, pues obviamente como ya sabes, dando clase. Estas semanas han sido de nuevo de dar clase y lo que estamos viendo ahora es un poco lo que hablamos en el episodio anterior, el tema de las arquitecturas, en este caso de SwiftUI.

Este año he incorporado una nueva versión de la arquitectura que uso nativa, basada en Clean Architecture, en el que creo un interactor que es el que se encarga de inyectar lo que es el almacenamiento, digamos la persistencia de datos, ya sea en local o en red. Pues esa persistencia de datos se inyecta a las aplicaciones directamente a través de un protocolo. Es algo que ya probé en su momento, pero que ahora este verano lo he perfeccionado y lo he dejado de una manera, pues que al final está utilizando programación orientada protocolos,

para poder elegir para que el mismo exacto procedimiento que carga y envía, si es tanto local como red, pues sea el mismo a nivel de código, pero las fuentes o el lugar de donde procede esa información, pues pueda variar en cada instancia, pasando de tener la persistencia en una clase a tenerla en un strut, para que sea totalmente orientado a protocolos.

Entonces lo que hacemos es inyectar por dependencia ese strut, bien de producción, bien de desarrollo, de preview, de SwiftUI, directamente al ViewModel y directamente pues aquello funciona estupendamente bien. De hecho hice una masterclass la semana pasada en directo aquí en Twitch, explicándolo, que todavía estará colgada en Twitch, por si queréis verla.

De hecho, si Jobs quiere y me da tiempo, podré colgarla también en YouTube. Y bueno, pues ahí está ese cambio. Y luego el miércoles, que ha sido una semana muy Apple, el miércoles estuve de nuevo en las oficinas de Apple. Estuve en las oficinas de Apple en la Puerta del Sol, no en la tienda, sino en la parte de arriba, pues de nuevo dando una charla.

Apple, junto a la gente de iDutech, pues bueno, en realidad lo organiza iDutech y Apple pues colabora con ellos para ceder el lugar para dar estas charlas. Entonces fui como ponente de unas charlas que ya di en junio sobre inteligencia artificial generativa y básicamente pues bueno, pues una masterclass de una hora más o menos, donde explico la situación actual de la IA generativa, las herramientas que hay, de dónde venimos, hacia dónde vamos y luego pues una serie de conceptos fundamentales,

que es inteligencia artificial, que es Machine Learning, que es Deep Learning, distintos tipos de inteligencias, distintos tipos de modalidades de dichas inteligencias y luego pues explicar las redes neuronales y los tipos más básicos o en general una definición rápida de los distintos tipos de redes neuronales que tenemos.

Desde las redes neuronales más básicas, pasando por los transformers, los modelos de difusión, las redes, en fin, todo tipo de las redes NERF y tal. Bueno, pues explicando un poco cómo funciona todo eso pues para que la gente pueda entender a nivel de funcionamiento pues cómo va toda esta cosa. Entonces bueno, pues es algo que es interesante y que bueno, pues de hecho...

Ojo Julio, que no es fácil meter esto en una hora. Bueno, pues una hora hay algo, además meto medio vídeos, pues voy sacando, yo que sé, cuando hablo de NERF, que es el tema de los campos neurales de radiación, que es para poder sacar a partir de 2D, generar 3D, detectando lo que serían precisamente lo de las fotos que hemos hablado, lo del algoritmo de poder hacer la foto de modo retrato y poder cambiar y tal, eso es NERF.

NERF es a través de redes neuronales comprender una fotografía 2D y crearle un mapa de profundidad que te permita discernir los distintos campos que hay dentro de esa bidimensionalidad. Y entonces, bueno, pues les enseño, por ejemplo, cómo funciona el Object Capture de Apple, que ahora ya funciona en iOS, y de hecho hay varias demos de cómo hay apps de iOS 17 que son capaces de...

Tú te paseas con un vídeo alrededor de algún tipo de elemento 3D, lo capturas y te lo genera en tiempo real con texturas y con todo, y de hecho a veces es incluso indistinguible de él real, dentro de lo que es esa realidad aumentada, y bueno, pues todo lo que es el funcionamiento de transformes, etcétera, y varias demos de IA generativa, de cómo funciona el nuevo Microsoft 365 Copilot, etcétera, etcétera, que de hecho ahora también ya les comenté que saldría la versión de Inteligencia Artificial

de Windows, que ya ha sido anunciada, que fue anunciada el otro día, Windows Copilot, y bueno, pues Windows Copilot la verdad que es un adelanto de lo que vamos a ver en breve en todos los sistemas operativos, ¿vale? Es decir, Apple ya está trabajando en su propio sistema llamado Ajax, a nivel de nombre preliminar de producto, y será la IA que se integre en todos los sistemas. Me recuerda, Julio, el nombre, no sé quién lo habrá elegido, pero a mí me recuerda a un

framework que utilicé yo bastante en mis inicios de Javascript. Claro, sí, sí, ¿no? Es el típico framework de Javascript, es la forma de programación reactiva de Javascript, ¿vale? Tu poder, a través de Ajax, tú podías enviar y recibir peticiones, o sea, podías enviar peticiones post que devolvían una respuesta y no tenías que refrescar la página, ¿vale? Entonces, pues sí, lo han llamado así.

Entonces, pero bueno, el caso es que, pues la verdad que es interesante y esto es un cambio de paradigma que va a cambiar por completo la forma en la que usamos cualquier tipo de sistema, ¿vale? O sea, el año que viene vamos a poder invocar no solo apps, ¿vale? Porque hoy día yo le puedo decir, no sé quién, ábreme tal aplicación, ¿vale? Y te lo hace, ¿vale? No tienes por qué, pero al final no lo haces, ¿no? Pero a partir de la integración de estas herramientas con los nuevos sistemas como

Windows Copilot o el futuro Ajax de Apple, pues lo que tendremos es un control total, es decir, yo podré decirle al sistema abre OBS, ponme, confígurame la escena, ponme tal, arráncame la cámara virtual, ponme no sé cuántas e incluso, y aquí es donde está la gran diferencia, el trabajo con nuestros ficheros en local, nuestros ficheros en disco duro, ¿vale? El que tú le puedas decir, yo de hecho ya tengo una IA que estoy probando, que se engancha con GPT-4,

pero tiene la capacidad de ejecutar procesos en tu máquina, ¿vale? Entonces yo a ese sistema le dije, conviérteme este fichero que está en tal carpeta, ¿vale? A MP3. Y entonces fue a por el fichero, bajó las librerías que necesitaba para ello, lanzó el script para hacer la conversión y lo convirtió y yo no tuve que hacer absolutamente nada.

¿Sabes, Julio, que es que además Apple lo tiene ya en su sistema? Y justo te conté una cosa que hice esta mañana. Tiene atajos. La aplicación de atajos tiene un montón de acciones del sistema que tiene una API para que los desarrolladores den de alta esas acciones, que es una de las cosas que decía que por eso ha tardado Microsoft tanto en integrar la parte de Copilot, porque tenía que, digamos, mapear todas las acciones que se pueden hacer en una, o sea, para que esta inteligencia artificial pudiera,

o sea, este algoritmo de machine learning pudiera escogerlas, digamos. Pues es que eso Apple ya lo tiene con los shortcuts y esta mañana estaba creando uno precisamente para el botón de acción del iPhone 15 Pro directamente porque lo que yo quería era que me cambiase los modos de concentración, pero quería algo un poco más profesional, que era que si se hacía entre las siete de la, no, entre las diez de la noche y las siete de la mañana, me pusiera el modo descanso, pero si lo

hacía en otro, fuera de ese rango, que fuera el modo no molestar, ¿vale? Y, joder, es un poco arduo el tienes que sacar una variable con la, o sea, obtenerla ahora, sacar una variable con la hora, es un poco engorroso la parte de hacer de atajos. Si consigues que esos atajos, ya solo esto, que esos atajos te los haga con lenguaje natural el propio sistema, es que para mí, vamos, es un avance enorme porque es que luego encima, ¿qué me pasó? Ah, vale, me pasó que quería, muy bien,

yo le doy y me pone el modo, pero también quiero que si le doy al botón de acción del iPhone me quite el modo si está puesto, ¿vale? Pues también otro if ahí y es un poco engorroso y entiendo, a ver, y yo tengo un poco de lógica de programación, de trabajo con datos, lo que es un if, pero alguien que no tenga ni puñetera idea de esa lógica, entiendo que hacer un atajo en la aplicación de atajos es una tarea complicada y si tenemos algo que se lo decimos y lo hace, además,

también sería un campo de pruebas muy bueno porque, mira, yo te lo meto en la aplicación, te pongo esta guía generativa para hacer atajos, punto, ya está, no sale de aquí y te funciona mejor o peor, pero no sale de aquí, entonces no se arriesga tanto Apple. Yo creo que lo debería empezar a meter por ese punto, no sé cómo lo ves.

Sí, es que ese va a ser, yo creo que está clarísimo que ese va a ser el punto, el de cómo ya tiene automatizado, ya tenía gran parte del sistema automatizado a través de Apple Script y a través de la famosa antigua aplicación de Automator, ¿vale? Y ahora con lo que serían los atajos lo tiene igual, ¿vale? Entonces las automatizaciones están ahí, ¿vale? Es decir, la inteligencia artificial generativa que va a usar Apple es la misma inteligencia artificial generativa que va a usar Microsoft en el sentido

de inteligencias de texto e inteligencias de generación de imágenes, ¿vale? Y luego puede ser que haya alguna más metida. La diferencia es que gran parte de lo que va a hacer Microsoft Copilot, Windows Copilot, perdón, lo va a hacer en la nube, por lo que tus datos van a ir a la nube o tus datos ya van a estar en la nube porque los archivos con los que va a trabajar van a estar en OneDrive, ¿ok? Pero Apple lo que está haciendo es trabajar para poder cargar esos modelos en

local. Sabemos que Apple la nube no la curra mucho, no la maneja mucho. No trabaja ese artículo. No trabaja ese artículo y entonces pues eso lo que hace es que al final Apple lo que quiere es poder cargar el local que de hecho ya está trabajando con Stable Diffusion, que se puede cargar el local como un modelo de CoreML, se puede cargar Yama 2, el modelo de Facebook también en CoreML y utilizarlo como modelo generativo de texto.

Entonces basado en eso va a hacer un poco como lo que hace GPT-4, ¿vale? GPT-4 al final lo que tiene son pues la guía generativa de texto. De hecho ahora se acaba de anunciar Dalí 3 que va a estar integrado en GPT-4. Una de las cosas más problemáticas a la hora de manejar una guía generativa de imágenes es saber darle el prompt exacto para que te genere lo que tú quieres y hay que ser todo un artista, todo un prompt engineer para llegar a eso.

Pues bien, lo que ha hecho OpenAI es integrar Dalí 3 dentro de GPT-4 de forma que cuando tú a GPT-4 le pides de manera textualizada, de manera conversacional, la imagen que quieres, él traduce por detrás lo que tú le has dicho a un prompt que sea capaz de sacar lo que le has pedido, ¿vale? Es decir, te hace una traducción. Lo típico que hay mucha gente, que de hecho existe, ¿vale? Hay un montón de páginas donde tú puedes copiar todas unas instrucciones como contexto dentro de tu conversación de GPT y a partir de ahí le puedes pedir prompts

de mid-journey, por ejemplo, a GPT y te los da estupendos, ¿vale? Entonces, pues eso ya lo va a hacer de manera automática GPT-4. Entonces, insisto, esto es lo que hará Apple. Lo que tienes que hacer es que GPT-4, como ya hace GPT-4, esté conectado a un sistema de análisis avanzado que sea capaz de ejecutar scripts de Python para trabajar y procesar tus datos, ¿vale?, a nivel de análisis y también la inclusión de plugins, plugins que permitan, pues por ejemplo, como yo

hago con GPT, de darle una URL y que vaya a leer esa URL y luego me hable de ella y me diga, pues oye, este es el resumen, esto no sé qué, esto no sé cuál, ¿vale? Entonces, eso lo hará Apple también de poder utilizar cualquier tipo de contexto y, sobre todo y principalmente, los plugins que permiten ejecutar, que ese es el key de la cuestión, que permiten entender y ejecutar ciertas acciones, por lo que simplemente a la hora de pedirlo, pues lo cogería.

Y esto, antes de que alguien diga, pues como lo hago con Siri, porque no sé qué decir y... No, no, o sea, a ver, ¿por qué Microsoft... Claro, ¿por qué Microsoft mató Cortana antes de crear Windows Copilot? Para que la gente no pensara que eso era Cortana.

Windows Copilot es otra cosa distinta a Cortana, ¿vale? Pues bien, si yo fuera Apple, os lo digo en serio, si yo fuera Apple, dado el desgaste que tiene la marca Siri, unida a algo que funciona menos, que falla más que una escopetilla feria, yo me plantearía seriamente, y os lo digo de corazón, matar a Siri. Pero no matarla como tal, sino matarla como marca, matarla como elemento.

Es decir, no llamar Siri a lo que sustituya a Siri. Porque eso es lo que Apple viene haciendo en los últimos años. Siri ha tenido cuatro reescrituras. Hay un SiriKit... Es complicado. Pues que lo cambien de nombre. Me da igual, pero que no lo llamen Siri, aunque luego por dentro siga siendo Siri, aunque siga siendo la librería SiriKit, aunque sigan siendo los atajos de Siri, pero que no se llame Siri, se llame Paca, ¿vale? Y ya está.

Entonces, oye, Paca. Bueno, ahora ya no hay que decir oye. Bueno, no hay que decir oye, no. Yo no he sido capaz de invocarla sin el oye, ¿vale? Creo que lo del hey lo han quitado solo en inglés, pero en español sigue siendo oye. No lo he probado. No, no, porque el otro día se me pasó por la cabeza probarlo y no, sigue siendo igual, sigue siendo oye.

No escucha otra cosa, ¿vale? Pues sí, a ver, la verdad es que esto es el futuro. En este Microsoft lleva, digamos, un poco la delantera. Lo único que me surge, no sé si va a ser de pago o va a ser con la licencia de Windows, porque, ojo, cuidado. Windows Copilot. Esto que se ejecute en la nube. Windows Copilot, Windows, ¿vale? Va a ser gratis.

Pero va a ser gratis lo que es ponme el modo oscuro, arráncame no sé qué aplicación, hazme no sé qué cosa. Ahora, cuando ya trabajes con la parte de documentos, ahí ya, ojito, porque la parte de documentos... Es que tiene que ir a la nube, entrenarlo con tus documentos en la nube y eso, eso cuesta, cuesta dinero.

Claro, es que Microsoft 365 Copilot es algo distinto a Windows Copilot, ¿vale? Entonces Microsoft 365 Copilot es muy caro. Es el doble o el triple, no, no recuerdo exactamente, pero es más del doble de lo que vale Office a día de hoy. Y lo tienes que, bueno, ya sabéis que ya no se llama Office, pero bueno, pero tienes que pagarlo aparte.

Entonces, yo tengo la duda, porque eso es algo que a mí, por lo menos, no me ha quedado claro, de si el, por ejemplo, tú puedes coger un documento de tu disco y decirle, sumaráis, ¿no? Y que te haga un resumen. ¿Pero ese resumen es gratis o ese resumen tiene un coste? Porque lo que va a ser gratis es la integración de BIN con inteligencia artificial en el sistema operativo y que a través de ese, de ese BIN en el sistema operativo le puedas pedir cosas del sistema operativo, ¿vale? Pero, y eso será Windows Copilot,

pero ¿Windows Copilot va a meter el que tú hagas un resumen de tus documentos de Word y esté gratis? Porque yo creo que va a haber modelos distintos. Para eso que cuentas de lo del sistema, de pedirle que pongan modo oscuro y cosas de esas, yo creo que van a hacer un modelo pequeñito que se ejecute en la nube, pero digamos en máquinas más modestas y que cueste menos dinero.

Y luego la parte que ya será máquinas más pesadas, un modelo más grande y que encima se entrene con tus datos, irá en la licencia aparte. Es que es imposible, es imposible que de esto gratis, no puede. Sobre todo a los millones y millones y millones y millones de usuarios de Windows. Y la parte, a ver, ChatGPT...

Y sobre todo con Windows pirata. ChatGPT tiene Windows gratis, digo, tiene parte gratis, pero claro, primero que a veces está petado y no te deja entrar y demás, pero encima no entrena con tus datos. Es que entrenarlo con tus datos es mucho proceso, mucho tiempo que tienes ocupados esas máquinas virtuales, pero bueno... Pero es contexto, es decir, no es que esté entrenado con tus datos, sino que tú le mandas tu fichero y él se lo lee.

Pero claro, si tu fichero ocupa la misma vida, estamos hablando de contextos muy grandes y cuanto más grande es el contexto, más coste tiene. Y si encima, como dice Microsoft, todo funciona con GPT-4, que GPT-4 no es gratuito, ¿vale? Pues y de hecho, si lo usas GPT-4 en Bing, tienes una limitación de contexto de hasta 30 peticiones, pues en fin, a lo mejor lo hacen medio gratis al principio para que la gente se acostumbre, pero esto... Pero es que es medio gratis en algo como Windows.

Claro, entonces, si le pides cosas del sistema operativo, eso yo entiendo que será gratis, pero en el momento en el que tú tienes, yo que sé, que le digas cópiame tal fichero a tal carpeta o conviérteme este fichero a no sé qué, vale, entonces a lo mejor es gratuito porque al final son procesos que simplemente van a la nube, ven lo que tienen que hacer, vuelven y te lo hacen en tu máquina local, perfecto.

Pero... El resto no lo sé. Sin embargo, Apple, repito, Apple lo va a poner en local, va a ponerte un modelo de generación de texto en local en tu máquina, por lo que no va a haber limitación. A ver, la limitación va a ser la capacidad que tenga dicho modelo. Si ese modelo tiene una capacidad de 8000 tokens, pues si le quieres dar un documento que sea demasiado largo, pues te dirá, no, mira, te lo voy a tener que trocear porque no puedo leerlo entero, ¿vale?

Si le pone... porque claro, aquí también los contextos importan, ¿vale? No es lo mismo ahora mismo GPT-4, si no me equivoco, funciona con los 8000 tokens de contexto. Eso es, aproximadamente, unas 7000 palabras, ¿vale? En el momento en el que tú superas las 7000 palabras, GPT se olvida, ¿vale? A mí me ha pasado.

Yo he llegado a tener conversaciones muy largas con él y cuando le he preguntado por cosas que le hablé al principio, se había olvidado de ellas, porque había superado el contexto de las 7000 palabras. Entonces, claro, esas 7000 palabras son las que llegan al total, ¿vale? Que sí, que 7000 palabras es una burrada, ya lo sé, pero al final, entre lo que tú le dices y lo que él te contesta, tal. Claro, entonces, teóricamente, GPT-4 va a llegar a tener contextos de 32.000 tokens,

que serían unas 28.000 o 29.000 palabras, ¿vale? Pero, claro, en fin, hasta que lleguemos a eso, y cuanto mayor es el contexto, más coste tiene. Entonces, Apple lo que está intentando es hacer que esto funcione en local, ¿vale? Por eso no se ha metido todavía en todo este fregado. La gente dice, ¡ay, es que Apple llega tarde! ¡Ay, mi, mi, mi, mi, mi, mi! Pues lo normal, ¿vale? Pero no es que llegue tarde, es que lo que Apple no va a hacer es montar un servicio en la nube para quedarse

con tus datos y procesar tus datos, ¿vale? Porque Microsoft te está diciendo que no van a usar tus datos para nada malo y que para brindar el niño Jobs, pero tú tienes que creerlos, ¿vale? Entonces, ahora mismo, toda la IA está funcionando en la nube y toda la IA le está dando tus datos.

Y si tú vas a usar Microsoft 365 Copilot para que el Office haga virguerías, tú tienes que saber que toda tu información confidencial de tu empresa va a ir a la nube. Y la van a tener ahí, pues bueno, bueno, pues tú mismo, tú verás lo que hace, ¿vale? Si no te importa, pues genial. Dar un paquete para empresas, pero que es bastante más caro, en donde una de las cláusulas es que no sale.

O sea, que tendrán unos servidores dedicados, pero es muchísimo más caro, obviamente. Claro, entonces, al final, pues ¿qué pasa? Pues que Apple se enfrentó a este problema el año pasado, el hecho de que empezaban, se encontró, ¿vale? Que había varios desarrolladores que estaban usando GitHub Copilot y claro, Apple dijo, a ver señores, guay, pero los proyectos que aún no han salido no podéis usar GitHub Copilot, porque eso es secreto industrial, ¿vale? De hecho, sabemos que Apple trabaja con Git, con GitHub, ¿vale? Pero trabaja con GitHub cuando ya ha publicado un

elemento, pero cuando está en privado, trabaja con sus propios servidores. De que en GitHub, claro, tú le pones en Copilot, le pones Key o Sender Key y claro, y te puede dar una clave de API de algún usuario, del código de algún usuario. Y así se filtraban claves de API.

Por eso, entonces, es que no tiene... Entonces, claro, ahí no puede Apple permitirse. Entonces, Apple se puso a hacer su propia IA, ya tiene su propia IA generativa, que según dicen es igual de buena que GPT-4 y permite hacer auténticas virguerías, como ya estamos viendo, pero Apple tiene sus tiempos y Apple lo que quiere es cargar eso en local, en tu ordenador o en tu móvil o donde sea, para que todo sea privado y no tenga que salir fuera.

Y para eso, pues hace falta tiempo y hace falta que esté todo bien integrado. Entonces, bueno, pues todo esto llegará y va a ser un cambio brutal en los sistemas operativos, que llegará poco a poco y que las primeras versiones pues se harán un poco más arcaicas y lo iremos mejorando poco a poco, lo normal, pero llegará a un punto en el que casi la mayoría de cosas podremos hablarlas.

Yo podré llegar a mi ordenador y decirle, oye Paca, ábreme Logic, créame un proyecto de cuatro pistas de audio, pon la fuente tal en la pista primera y prepárate para empezar a grabar. Y que él me haga todo y me lo ponga a funcionar. Y luego de unos años ya que grabe el programa. Bueno, ya sabes que hay avatares virtuales que permiten hacerlo.

De hecho, yo me tengo a mí mismo hablando en varios idiomas. Y pues eso está a la vuelta de la esquina. Lo probó dotcsv. Cuando tú tienes un set como el que tenemos tú y yo, que es una imagen fija, yo me puedo ahora mismo ir a Heiyen, darle que quiere un instan avatar, coger y grabarme hablando durante dos minutos con este fondo e intentando no gesticular por encima de los hombros.

Entonces voy comentando, no sé qué, tal, tal, pipi, pipi, papapá. Grabo dos minutos de audio, subo el vídeo, se procesa y a los 10 minutos ya tengo un avatar mío. Entonces ahora cualquier audio que yo le dé a ese avatar va a ser yo con este fondo moviendo las manos, gesticulando y haciendo cambios, haciendo que mi avatar diga el audio que le he subido.

Entonces, si yo le subo un audio diciendo cualquier otra cosa, yo, por ejemplo, podría grabar el podcast como podcast y luego dárselo a este avatar para que lo genere. De hecho, hay canales 24 horas de venta en China donde las chicas que están vendiendo productos son avatares de IA, que las empresas están pagando mil dólares al mes y tienen un avatar que es capaz hasta de interactuar con los productos que tiene ahí.

Entonces es simplemente una mujer que se graba con unos minutos de referencia, se entrena y a partir de ahí, si ella se va porque está cansada o se va a dormir, se queda el avatar y sigue vendiendo y pueden llegar a hacer seis, siete, ocho, nueve mil dólares mientras está solo el avatar y nadie sabe que es un avatar, que no es real, ¿vale? Ese es el nivel en el que estamos ahora mismo, ¿vale? Entonces imagínate. Cada día es algo nuevo, la verdad.

Pues sí, entonces imagínate la posibilidad en Apple Vision Pro. Imagínate una aplicación, te lo digo así, el primero que se le ocurra la idea para vosotros, jugadores, de una novia virtual. Una novia virtual que tú la invoques cuando quieras, que le hables, que te cuente, que te diga, que te explique qué tal, qué para arriba, qué para abajo, que incluso si tienen los derechos.

Hoy día hay modelos a través de Telegram, por ejemplo, con la voz de Amuranz, ¿vale? En el que tú le puedes decir lo que quieras, lo que quieras a ese avatar. Bueno, la chica hasta que estuvo con... Y no te contesta Amuranz, te contesta una voz sintetizada que Amuranz ha grabado, pero que es absolutamente real.

Tú le escribes a través de Telegram y ella te manda una nota de voz contestándote. Y entonces tienes una conversación real con una IA que tiene la voz de Amuranz que es indistinguible de la voz real. La mujer de... Bueno, la mujer no, que estuvo con él o no me acuerdo. Estuvo con una cantante que tuvo... Creo que ha salido que ha tenido dos hijos con ella.

Grimes. Grimes. Pues ha creado con una IA su voz para que tú puedas hacer una canción con su voz y a cambio le tienes que dar, no sé, un porcentaje de lo que saques. Pues fíjate. Pues sí. Pues en la IA no dejan de salir noticias, Julio, pero en Swift y en Apple también hay algunas noticias. Así que si quieres pasamos a la siguiente sección. Tiramos.

Pues hay noticias curiosas, ¿vale? Noticias curiosas. Yo, la que más, la que más, la que más que he de reconocer que me dejó flipándolo es el tema del nuevo proyecto de Unit Testing basado en macros para Swift. Me parece una locura. O sea, me parece un cambio brutal, ¿vale? Un cambio brutal para definir cómo serían, cómo sería el Unit Test, ¿vale? Y esto no es quitar XCTest, ¿de acuerdo? O sea, estamos hablando de pues SwiftData.

¿SwiftData qué es? SwiftData es una capa de macros de Swift que cambia la forma en la que se construye CoreData para que en vez de ser Objective-C sea mucho más Swift. Pues bien, es lo que han propuesto en los foros de Apple, ¿vale? A través de una nueva aproximación en los testing, ¿vale? Estaríamos hablando de usar la macro adjunta arroba test para poder tener la capacidad de realizar test de una forma totalmente distinta.

Ya no habría que crear una función que empezara con el nombre test y que luego usara los famosos XCTest de pues el XCTAssertTrue, XCTAssertNotNil, XCTAssert lo que sea, ¿vale? Estaríamos hablando que yo, para definir una función que fuera de tipo test, ¿vale? Ahora lo que tengo que hacer, como ya sabéis, es dentro de un target de testing poner función test en minúscula y luego ya el nombre que lo añado lo que sea.

Y simplemente con que empiece con la palabra test en minúscula ya se incluye como un test unitario, ¿vale? Pues ahora lo que habría que poner arriba es arroba test. Entonces al poner arroba test le pondríamos la definición, ¿vale? De lo que es ese test, ¿de acuerdo? La definición a nivel de texto, ¿vale? De forma que luego le diríamos, por ejemplo, le podríamos dar, por ejemplo, opciones como que ese test sólo esté disponible cuando cierto valor de una variable esté correcta o no, ¿vale? Si yo

pongo simplemente arroba test, ¿vale? Y ya está, pues sería pues eso, arroba test. Y entonces pues yo le doy ahí la descripción y punto. Pero le puedo decir, activa este test sólo si el valor isAvailable está en tal instancia, ¿vale? Y entonces en ese caso entraría en el test.

O por ejemplo, a los test les puedo enviar argumentos, ¿vale? Argumentos que permitan recoger información que luego capturará ese test para poder usarlo como datos internos. Entonces cuando yo ya tengo el arroba test con esas entradas, debajo pongo la función, ¿vale? Entonces dentro de la función lo que cambia es que en vez de poner el xct, a, ser, xct, lo que sea, xct, xct, xct, lo único que vamos a poner es hashExpect, ¿vale? Se espera esto, ¿vale? Entonces yo pongo hashExpect que, por ejemplo, la cantidad de tal

dato sea igual a 20, o que el valor sea igual a 0, o que esto sea nil, o que, o sea, la comparación que yo le quiera poner, ¿de acuerdo? Simplemente hashExpect... Pero con el operador directamente, ¿no? Como argumentos, como se hace... Exacto, y ponemos el operador directamente y listo. Vale, esto es un cambio brutal, pero brutal.

A mí me ha parecido de una belleza la forma de describirlo, que me ha dejado muy loco. O sea, si esto lo tenemos el año que viene, que tiene pinta porque, en fin, sabemos que Swift funciona de esta manera y además sería una API multiplataforma, por lo que los tests en Linux o en cualquier otro sistema serían exactamente iguales. Bueno, esto es un cambio de paradigma, pero madre mía, porque facilitaría muchísimo la comprensión de los tests y, sobre todo, la velocidad a la que hacemos los tests, ¿vale? Yo no sé cómo lo ves

tú, ¿qué te parece? Pues yo también me ha volado la cabeza porque, a ver, la sintaxis es mucho más sencilla. Todo eso, todo el engorro este que teníamos en los tests, todo eso de creo una función por cada caso, no sé qué, pues esto al final te lo hace. Como dices, pues le pones los argumentos y te hace un test para cada, o sea, te genera el test para cada argumento.

Luego te, no sé, te quitas como toda la sobrecarga de, no, tiene que empezar por test y esas chorradas, entre comillas. Luego la parte de assets era muy complicada, ¿vale? Cuando miras a ver si cumple ese test, algo, pues eran funciones con parámetros, con tal. Pues aquí se supone que con la sintaxis puedes utilizar el propio Swift, ¿vale? Pues todas las funciones de filter, map, no sé qué, puedes utilizarlas, ¿vale? Y comparadores de los de toda la vida, pues igual, distinto, mayor,

menor, sin tener que utilizar una sobrecarga de una función que era más engorroso. Y no sé, me alegra porque esto en principio es algo que es de la gente de Apple, pues que tiene sus proyectos internos, ¿vale? Pues como Swift es de código abierto, pues de hecho el que lo explica, que está en el post que ha puesto en los foros de Swift, pues eso, que han hecho Open Source, una librería en la que estaban él y sus colegas, sus compañeros, trabajando.

Y nada, pues que la ponen Open Source porque todavía queda, ¿vale? No está, no está acabada ni mucho menos, pero bueno, ahora con la comunidad, pues si coge tracción, pues no creo que tarde mucho. A lo mejor en, no sé, en unos meses tienen algo, una versión preliminar y en medio año estamos ya disfrutando de esta, de esta librería.

O a lo mejor esperan a, porque a ver, Swift es Open Source, pero está el amo del Proud, sigue siendo Apple, ¿vale? Y a lo mejor esto, pues es una de las cosas que nos presentan en la siguiente WWDC como la nueva librería de testing que tenéis que usar, que a mí no me extrañaría, porque tiene muy buena pinta.

Está, fíjate, ahora mismo estaría soportada, ¿vale? Porque esto es un proyecto que ya tenéis en GitHub, ¿vale? Podéis instalarlo, podéis probarlo. Insisto, es una propuesta preliminar, ¿vale? Ni siquiera es una beta, es una propuesta preliminar que dará lugar a muchos cambios, ¿vale? Pero lo tenéis en github.com barra apple barra swift guión testing y soporta macOS, iOS, watchOS, tvOS, Ubuntu y está pendiente de Windows, porque ahora mismo en Windows todavía no se soportan las macros, ¿vale? Pero esto no es algo que, insisto, esto viene de Apple,

¿vale? Esto es github.com barra apple barra swift guión testing y esto lo hace Stuart Montgomery, Stuart Montgomery que es un ingeniero de software del equipo de XCTest en Scouse en Apple, ¿vale? Esto no es Paco que se ha puesto a hacerlo, ¿vale? Esto es algo oficial y que, bueno, pues es una propuesta que ponen ahí, que luego pues obviamente todo esto traerá mucho más juego y traerá mucho más cambios, ¿no? Al respecto, pero desde luego, bueno, pues es algo que se ha empezado a trabajar

y que yo ya te digo, o sea, aplaudo, aplaudo muchísimo el que estas iniciativas se lleven a la comunidad open source y que se trabajen y que ojalá hubieran hecho esto con SwiftData, ¿vale? Porque claro, la diferencia es que XCTest es una librería que pertenece al propio lenguaje Swift, ¿vale? Y entonces, bueno, pues el cambio, ¿vale? CoreData no y entonces por eso entiendo que a lo mejor no se puso dentro de los foros de Swift, ¿vale? Pero bueno, la verdad que...

Lo de CoreData no lo entiendo, o sea, bueno, lo de SwiftData entiendo que como viene de CoreData, ¿vale? Es interoperable y seguramente que por detrás tenga mucho código de CoreData. Yo creo por eso no lo han hecho, pero sí que es verdad que a lo mejor SwiftData podrían haberlo enfocado como algo que saliese de la propia Swift.

A ver, al final Swift tiene manejo de ficheros, que es lo que te hace falta para la base de datos. No sé, no sé por qué. Bueno, sí, sé por qué. Porque precisamente habrá mucho código todavía y mucha necesidad de CoreData para SwiftData, ¿vale? Y por eso no lo han hecho. A lo mejor en el futuro, cuando vaya evolucionando dentro de un par de años, sí que lo saquen de, digamos, de una librería, una herramienta de Apple, una librería de Apple, y lo pongan como una librería de Swift Open Source, esperemos.

Seguramente le vendrá bien. Sí, sí, absolutamente. Y luego teníamos otra noticia que, si quieres comentarla tú, que es el SDK Generator, ¿no? Sí, pues sigue Apple liberando herramientas que a mí me parece bien porque creo que es un cambio de idea de ir liberando librerías. Hablamos, creo que hablamos de aquí, de una para parsear HTML, para crear la respuesta y la, o sea, la ricos y la responde HTML.

Están liberando librerías que seguramente tendrían ellos allí pseudo oficiales, internas, ¿vale? Y las están liberando y la verdad es que está muy bien. Pues esta de la que voy a hablaros ahora es SDK Generator, le han llamado, y viene a resolver un problema que yo tuve en su día cuando hacía librerías, y es que había, de aquellas había solo una manera, que era crear una librería normal de toda la vida, que venían de C, yo creo, este tipo de librerías, y tú ya la distribuías compilada, había que hacer algunos

hechizos porque cuando salieron, si querías que la librería funcionase primero y supieras utilizar el simulador, que el simulador de ellos no es un emulador, sino que corre sobre la arquitectura del Mac, que era x86, y luego salieron procesadores de Apple de 32 bits y también los había de 62, con lo cual ya era también otras dos arquitecturas, pues tenías que hacer una, un hechizo para compilarlas por separado y distribuirlas en un solo binario, y tú a tu usuario de la librería,

vale, le dabas ese, esa librería, ese binario compilado que tenía todas las arquitecturas, y era bastante engorroso. Ahora tenemos aquí, o sea, tenemos otra cosa intermedia que eran en su día los.framework, que era como esto, pero más avanzado, se le podían poner ciertas cabeceras, recursos, por separado, tenía, y luego salieron los.xcframework, vale, que es otra manera también de distribuir, pero al final tú le tienes que dar un archivo, vale, que es un poquito por lo que,

lo que cuento, engorroso el crearlo para las arquitecturas y demás. Luego vino Swift Package Manager, porque antes teníamos la Cocoa, vale, Cocoa Pots, que no era oficial, vale, Apple sacó Swift Package Manager, entonces puedes distribuirlo, pero claro, un Swift Package Manager es código, si quieres distribuirlo en código, es abierto, todo el mundo lo puede ver, claro, hay gente que querrá que su librería no se pueda ver cómo funciona por dentro, cómo son sus tripas.

Entonces lo que hacía la gente era volver a estas librerías compiladas y metía como recurso, como archivo, como fichero, estos bundles, que por ejemplo yo creo que Firebase y todas esas hacen esto, tú no puedes ver el código dentro, sino que directamente Swift Package Manager te da acceso a los archivos que vas subiendo ya compilados, vale.

Pues Apple lo que nos ha traído, vale, es una nueva forma de generar estas librerías, digamos que ya es la librería compilada para que no se vea el código, vale. Entonces nos ha dado el Swift Generator, este que es, digamos, una herramienta que genera la compilación de todas esas arquitecturas, vale, para que sea mucho más sencillo el crear estos archivos y el compartir estas librerías, vale.

De momento han empezado soportando la parte que tenía cero soporte, que es la de Ubuntu, vale, pero la idea es que esto se vaya extendiendo al runtime de macOS y puedas generar tu librería y distribuirla con Swift Package Manager, pero no con este workaround que era al final distribuir un fichero en lugar de código, vale.

Y nada, tienen en este caso un uso bastante pequeñito, vale, o un porcentaje de uso bastante pequeñito, pero bueno, está bien que Apple vaya liberando estas librerías y vaya dando a desarrolladores. Seguro que alguno de vosotros estáis en ese punto y esto es una buena noticia sin duda porque yo de aquellas lo pasé mal y ahora sé que la gente que está distribuyendo SDKs, pues al final eso, pues cada vez que tiene una nueva versión es, oye, hemos generado una nueva versión, te mando el binario.

Como los animales, en julio en vez de un gestor de dependencia lo que tienes que hacer es copiar ese binario cada vez y es un poco rollo para el que lo genera y rollo para el que lo recibe, que cada vez que cambien tiene que generar el binario. Bueno, pues es una cosa que, bueno, no deja de ser interesante y bueno, pues la verdad que son pequeñas cositas, es como la librería que han metido para el tema de los certificados, de los ASN1, de los X509, la nueva librería, como tú dices, de HTTP y tal, que también había por ahí.

En fin, hay un montón de nuevas opciones que desde luego me parece bastante interesante que se dé esa circunstancia y que te permita seguir mejorando tu código, etc. Aquí hay una cosa bastante curiosa. ¿Por qué Apple hace esto? No hace demasiado, hubo una polémica porque se acusó a Apple, es que tiene narices la cosa, de tener demasiadas palabras reservadas en el lenguaje Swift.

Se considera que un buen lenguaje de programación, o que tenga una curva fácil de aprendizaje, es aquel que tiene pocas palabras reservadas. En fin, yo disiento completamente de eso. Es decir, cuando tú montas algo, por ejemplo, en JavaScript o por ejemplo en Python, sabes que todo lo que montes lo vas a montar en base a librerías de terceros, a librerías de todo tipo, librerías para hacer cualquier cosa, porque el lenguaje en sí no tiene capacidad para hacer una mierda.

Eso para mí no es un buen lenguaje de programación, insisto, es mi opinión. Para mí, un buen lenguaje de programación es el que tiene lo que tú necesitas integrado en el propio lenguaje, es el que tiene integrado Asynnawait, es el que tiene integrado XCTest, es el que tiene integrado librerías para usar distintos tipos de tipos de datos de una manera natural, es el que tiene integrado todo lo que puedas llegar a necesitar, el que tiene integrada toda la gestión de peticiones de red, etc.

La serialización de datos, es decir, yo si quiero serializar datos en cualquier otro lenguaje tengo que buscar una librería de serialización. En Apple tengo Codable, no tengo que ir a buscarlo fuera. Y eso lo que hace, repito, en mi opinión, después de haber manejado lenguajes de programación durante más de 40 años, yo creo que al final lo importante es que las herramientas que necesites estén, uno, disponibles y dos, con garantías.

Y el que no las tenga disponibles... Te pasa que utilizas una librería como CocoaPods y luego nadie te la actualiza. Por ejemplo, o que tú uses lo que le está pasando a un montón de gente con RxSwift, que de pronto quiere poner RxSwift en Xcode 15, pero como la librería Observable se llama igual que la de RxSwift, pues entonces a tomar por saco, ya no funciona.

Y no puedes compilar. O como le ha pasado a un cliente que de pronto, mágicamente, el año pasado estaban usando una librería que habían decidido tener el nombre de NavigationStack. Pues ya saben lo que pasa con SwiftUI. Entonces, claro, este tío, el que hizo esta librería, en vez de cambiar el nombre y llamarlo StackNavigation, por ejemplo, darle la vuelta al nombre y punto, y que simplemente tengas que cambiar, no.

Decide que no sólo va a cambiar el nombre, sino que además va a refactorizar la librería entera para que funcione de una forma distinta. Conclusión, la aplicación a la basura. Porque toda la aplicación de más de mil líneas tienes que refactorizarla entera porque toda esa librería está metida hasta la cocina de tu casa.

Pues no, mira, lo siento, pero no. Que eso te lo puede hacer también Apple, por supuesto, te lo puede hacer también Apple, pero no te lo va a hacer tan... Es decir, te va a ir avisando y te va a ir diciendo, oye, que hay aquí un cambio, que esto no sé qué, y no te va a hacer cambios de ese calado.

Un Unity sí, pero un Apple no. Pero bueno, independientemente, la gente considera que tiene demasiadas palabras reservadas. Conclusión, pues que Apple lo que está haciendo ahora es sacar todo lo que considera extra del lenguaje a librerías externas como dependencias, y si tú quieres usar los algoritmos asíncronos que igualan Async Await con Combine, si quieres usar los nuevos tipos de colecciones con las colas o con los diccionarios o conjuntos ordenados, pues todo eso lo tienes que instalar aparte.

O la librería, por ejemplo, de Swift Numerics, para tipos de datos avanzados. Entonces, bueno, pues ese sería un poco el tema. Entonces, bueno, pues es lo que hay. Siempre buenas noticias, más herramientas. Y si quieres, cambiamos un poco de tercio y hablamos de versiones, versiones de iOS en este caso, porque a lo mejor los menos abezados os habréis dado cuenta, los más abezados os habréis dado cuenta que salió iOS 17, pero inmediatamente salió iOS 17.0.1.

Y esto tiene una explicación muy sencilla que os voy a dar a continuación, y es que la versión 17 tiene que estar preparada, supongo, que, bueno, se puede ver por la compilación, pero finales de agosto, ¿vale? Mediaos finales de agosto. ¿Por qué? Porque todos los iPhone nuevos que van a salir en septiembre, que noticia, se están fabricando ya, pues no sé cuándo empezará, pues en mayo, yo creo, mayo, junio, empieza ya la producción del iPhone para que el día que estrenan en septiembre tengan suficiente

stock, ¿vale? Para que te llegue a casa. Pues tiene que estar ya preparado y en ese último momento es cuando ya le ponen su versión que tiene que ir. Entonces, claro, ¿qué pasa? Que de aquí a que sale la versión, que pasan dos, tres semanas, pues siempre salen errores, ¿vale? De hecho, sacan la Release Candidate, esa es la que está metida normalmente en los iPhone, pero está metida de una semana antes, ¿vale? Entonces, claro, ahí normalmente la versión.0.1 sale muy rápido.

Pero ¿qué ha pasado también? Que habréis visto, los que hayáis estrenado iPhone, es que lo primero que hacíais cuando instalabais vuestro iPhone es que os pedía que actualizaseis a la.0.2. ¿Y por qué? Pues porque esa primera versión que salió tendría alguna cosa aparte específica para esos iPhones que tampoco funcionaba bien y hay que actualizar, ¿vale? Además, la.0.2 está solo para los iPhone

nuevos. Sí, exactamente. Cuando empezabas a hacerlo, te pedía que actualizases y por eso es la explicación que tiene, que es bastante simple, pero que a la gente muchas veces es la típica de joder ya, porque estaba mala versión. Efectivamente, nos lo hemos contado muchas veces, vivimos en estado de beta permanente, pero en este caso las fechas obligan a tener que cerrar versión a finales de agosto y normalmente pues no está suficientemente pulida o siempre sale algo de última hora y por

eso tenemos estas versiones rápidas. Pero, Julio, ¿tienes noticias de que hay una 17.1 en ciernes? Sí, de hecho, por completar lo que has comentado, otra de las cosas que tienen esta 17.01 y 17.02 es el parcheo de tres agujeros de seguridad muy gordos y explotados activamente que no dio tiempo a incluir en la versión cuando salió la 17.0, pero que, pues sí, dos días después ya sí dio tiempo a meterlas aquí y son tres agujeros de seguridad pues bastante importantes, ¿vale? Si no recuerdo

mal haber leído, uno o dos de ellos tienen que ver con Pegasus, con el software espía, ¿vale? Y luego, aparte, habrá gente como tú con el Apple Watch Ultra 2 que habrá notado que él no funciona, que la pincita que tanto se publicitaba con los... Aquí es directo, no pasa nada. No pasa nada, la pincita que tanto se publicitaba como una nueva función en los Apple Watch Series 9, volvemos a recordar para el que no lo sepa, ¿vale? El hacer la pincita, que es justo el gesto que normalmente

haríamos con el Apple Vision Pro, ¿vale? Apple ya nos está empezando a hacer que ensayemos, ¿vale? Que nos acostumbremos al gestito, ¿vale? Una pincita... Soiber tiene el de Futuramatic que está muy contento. ¿La pinza la puedo hacer? Exacto.

Entonces, la pinza es juntar el dedo gordo con el índice, ¿vale? Haciendo entonces uno o dos toques. Eso es lo que funcionaría con Apple Vision Pro. Yo miro a un elemento, lo destaco, hago dos veces la pinza y se pone. Pues bien, la pinza, como ya vimos en la presentación de los iPhones, pues se va a incluir como una funcionalidad por defecto en los nuevos Apple Watch.

¿Que ya se puede hacer en los anteriores? Sí, en los anteriores se puede activar. Tú puedes activar el reloj, puedes hacer doble tap. Suena eso, que ha sonado, el toque loco. Y ahora ya puedo hacer los gestos y esto es un Apple Watch Series 4. Pero esto forma parte de la accesibilidad, forma parte del Assistive Touch de Watch OS X, ¿vale? Pero tengo que activar la opción de accesibilidad y luego, cuando yo quiero hacer el...

cuando quiero usar los gestos de acción directa, tengo primero que activar el modo de los gestos, ¿vale? Sin embargo, con los dispositivos nuevos esa detección de la pinza va a ser continua, ¿vale? Porque gracias al motor neural han conseguido una forma de que este proceso, que es muy invasivo a nivel de sistema, porque detectar esa pinza supone controlar ciertos grados de cambio en tu tensión, en lo que es el flujo sanguíneo, ¿vale? Luego a cambiar también a nivel de detección de movimiento.

Son una serie de factores que unen ciertos sensores y una serie de detecciones que con los Apple Watch antiguos, si lo tuvieras todo el rato activado, la batería se la comería a una velocidad brutal, ¿vale? Por lo que para que funcione tienes tú que activarlo a nivel de voluntario, ¿vale? Pero en los nuevos, como esa opción ya no es tan...

no consume tanto porque la han mejorado y le han hecho que funcione bien con el nuevo hardware, pues lo va a tener por defecto. Pero por ahora no está, sino que hay que esperar a la 17.1, que teóricamente debería de salir en los próximos días como beta para que llegara aproximadamente a mediados finales del mes de octubre, ¿vale? Entonces ahí tendríamos esa opción, ¿vale? Tampoco podemos olvidar que los los nuevos iPhones tienen también una función, ahora se me ha olvidado cuál era, una función

que no iba a estar hasta finales de año. Era relacionado con las cámaras, no me acuerdo, un modo de las cámaras, no estoy... Sí, no me acuerdo muy bien. Había alguna función, lo conté en el mega análisis, pero ahora mismo no me acuerdo, había una función también de las que habían anunciado para los para los iPhones, que bueno, que tiene esa funcionalidad, ¿vale? Entonces...

Y luego había otra que era lo de la aplicación, está el del Journal. Ah, eso es, la aplicación de Journal, que fue anunciada el WDC, la aplicación de diarios, todavía no está disponible, ¿vale? Por lo que teóricamente podría llegar en esta versión 17.1, ¿vale? Para los usuarios, ¿vale? Pero el tema es ese, ¿vale? Que la versión 17.01, que salió el pasado jueves, ¿vale? Es una versión que lo que hace es parchear, parchear tres fallos de seguridad más ciertos problemas que ha tenido iOS 17 y que son errores de primera instancia, que se resolucionan de una

forma muy rápida, entre ellos pues también, como ha comentado Arturo, el problema de la versión de inicio, que viene preinstalada en los nuevos iPhones, ¿vale? Eso es. Pues Julio, te voy a contar ahora una noticia que, bueno, no es noticia, es simplemente una entrada del blog del creador de la aplicación que justo hemos estado comentando de Mastodon, IceCubes, ¿vale? Que a mí este señor me cae muy bien.

Me cae muy bien porque ha cogido y ha dicho que han sacado el nuevo modelo de reactividad con las macros, observable y tal. Pues voy a coger, cambio mi aplicación, la hago solo disponible para los últimos sistemas y me quedo tan ancho. Y lo que ha hecho es compartir en su blog un poco la experiencia, ¿vale? Como tres puntos clave de esta experiencia de migrar la aplicación, dice que no ha sido muy complicado, que en un par de horas lo ha tenido...

Recordemos que es una aplicación de acceso a Mastodon, pero es súper completa. Tiene un montonazo de cosas. Luego nos dice que ha solucionado bugs en lugar de crearlos y que el incremento en el rendimiento se nota y que merece la pena. O sea, sólo habla de cosas de cosas buenas y positivas y aparte de eso que le ha llevado unas pocas horas, ¿vale? La migración.

Una de las cosas que pone, que destaca es que utilizaba un montón de observable objects, la aplicación, y los pasaba la mayoría de las veces como environment object, con lo cual cualquier cambio en una propiedad arroba published, ¿vale? Hacía que se redibujaran a todas las vistas, todos los bodies de las vistas que dependían de este objeto, con lo cual hacía muchas veces necesario el refresco.

Entonces, con este primer cambio, pues lo que ha conseguido es que no se refresque tanto. Luego, aparte, ha utilizado bastante, porque cuando haces arroba observable, digamos que todas las propiedades que metas dentro no le tienes que poner el arroba published, sino que ya son directamente observadas, por así decirlo. Entonces, le tienes que decir cuándo no son observadas, ¿vale? Y dice que de esta manera, pues se ahorra un montón de

refrescos, cosas que antes iban un poco lentas, él lo ha hecho con las herramientas que tiene de Instruments Code y ha visto que muchas menos veces que se redibuja, cosas que iban un poco lagueadas, ya no lo hace, ¿vale? Sobre todo habla de la página principal, donde está cargando los Tooths, se llaman, los Tooths, las publicaciones de Mastodon, que es una vista compleja, con muchas subvistas, pues claro, con esta manera sólo se refrescan las vistas que tienen que refrescarse, ¿vale? Cuando

hay un cambio de un dato, antes decía cualquier cambio, pues refrescaba de repente un montón de vistas. Luego dice algo del rendimiento de SubUI, dice que ya simplemente compilándolo con el SDK de IOS 17, en lugar de IOS 16, dice que ha cambiado la versión contra la que se compila de SubUI y que ya con eso nota bastante el rendimiento, digamos, simplemente por compilarlo, porque está compilando contra una nueva librería de SubUI, que en este caso, Apple por

dentro, aunque no nos cuente, ha hecho varias mejoras. Y luego dice que la migración a este framework de observación, ¿vale? hace que sea rápido y habla, pues eso, de que vistas con una jerarquía muy grande de vistas, ¿vale? A su vez, pues son bastante más rápidas, dice las columnas, o sea, las filas, perdón, que tienen muchas vistas dentro, dependen de estas de estas inyecciones de dependencias por environment, no directamente, ¿vale? Pues se nota que muchos menos refrescos y

que va bastante más rápido. Así que yo me alegro porque todavía he cacharreado, ¿vale? pero todavía no me he atrevido a empezar a migrar a algunos desarrollos en los que trabajo, pero bueno, son muy buenas noticias. Sobre todo me ha sorprendido la parte, porque lo de esto de que se refrescan menos y demás, ya lo sabía, pero la parte está de que ya sólo compilando contra el nuevo framework de, o sea, perdón, contra el SDK de iOS 17, ya se nota que SubUI han movido las tripas para hacerlo

más rápido. Y nada, Julio, no sé qué te parece a ti. Bueno, seguro que también te cae genial este tío, eso sí. Sí, además he tenido alguna que otra, algún que otro cruce de post, porque ya no se llaman tweets, algún que otro cruce de post con él, ¿vale? Claro, este fue uno de los que apostó por Mastodon, a las pruebas me remito, pero luego por razones obvias, como todo el mundo, ha ido volviendo a Twitter, porque Mastodon, pues, no tiene la...

Solamente Steven Troughton Smith es el único que sigue ahí, sin querer volver, ¿vale? Debe ser que le tiene demasiada tirria a Elon Musk, pero él, al final, ha empezado también a publicar en lo que es Twitter, lo que sería ahora X, pues, principalmente por eso, ¿vale? Porque obviamente no tiene la misma incidencia en lo que sería su nueva aplicación, ¿vale? Pero, desde luego, lo que cuenta es bastante interesante, ¿vale? Porque creo que, al final, claro, tener una experiencia como esta, de una aplicación bastante

importante, bastante grande, en ese sentido, pues, hombre, siempre es bastante curioso, ¿vale? Este señor, Thomas Ricouart, ¿vale? Pues eso, tiene en su... Podéis seguirlo como arroba Dimillion, ¿vale? D-I-M-I-L-L-I-A-N, ¿vale? Es un... Tiene ahí, pues, su artículo, ¿no? De The Making of Ice Cubes, ¿vale? Y contar un poco también, pues, cómo lo ha hecho, tal.

Siempre te cuenta un poco todo este fregado. Bueno, la aplicación es Open Source, ¿eh? Tienes el código... La aplicación es Open Source, efectivamente. Podéis descargaros el código, verlo. Además, es multiplataforma porque funciona también en Mac, funciona en iPad, en iOS, ¿vale? Es una auténtica maravilla. De hecho, es el cliente de Mastodon que yo tengo instalado, ¿vale? Es el que yo tengo puesto, ¿vale? Y, de hecho, es muy gracioso porque, cuando te llega un Tooth, o un Republish de ese Tooth,

o lo que sea, o un Like, o lo que sea, de Mastodon, se escucha el sonido de unos cubitos de hielo en un vaso, ¿no? Clic, clic, clic, ¿no? Porque se llama la aplicación Cubitos de Hielo, ¿no? Entonces, pues, la verdad que está, en ese sentido, bastante bien.

Y, bueno, pues demuestra que, efectivamente, esto es una apuesta importante de Apple, ¿no? Que yo, lo que he estado probando, lo realmente interesante de Observable es, precisamente, esto que comenta, ¿vale? Que ya no necesitas pasarlo todo a través de los Environment Objects, sino que, como un Observable conecta con el siguiente y hace que la vista se refresque, pues, claro, es que ahora es un cambio importante, es que ahora puedes tener lógica de los modelos, ¿vale? Es decir, el problema que

tenía SwiftUI hasta ahora es el uso de los Massive View Model, en este caso, ¿vale? Porque, al final, terminabas por tener todo el código de gestión de cada modelo, más todo el código de el tema de, pues, de la gestión, ¿no? No solo del almacén, sino de lo que es toda la lógica de negocio, la tenías que tener en el View Model, porque si no estaba en el Observable Object, cuando actualizabas la fuente de datos, la vista no se actualizaba, ¿vale? Si lo ponías aparte,

tenías que capturar, o sea, si tú cogías y ponías un Observable Object y dentro de él, o sea, ese Observable Object lo instanciabas en otro Observable Object y ese Observable Object estaba en la vista, no funcionaba. El primer Observable Object que forma parte del segundo, cuando sufre un cambio, la vista no se entera de ese cambio, porque la instancia es del segundo Observable Object, no del primero.

Tenías que enganchar a través de Combine el Object Will Change para que propagara del primer View Model al segundo y que el segundo lanzara el Object WillChange.Send para provocar, entonces es un parche, en fin, de aquella manera. Ahora ya no hace falta, ahora pones arroba observable y una instancia, arroba observable, puesto como, o sea, una clase, arroba observable, puesto como instancia en otra clase, arroba observable, cuando yo la pongo en la vista, a través de un State, pues hace que el primer observable,

al actualizar, propague el cambio y propague el cambio, por lo que puedo tener las lógicas de negocio de todos mis datos y los almacenes separados y enganchados a través de un mismo View Model. Entonces, claro, el cambio es brutal a nivel de organización, por lo que ahora ciertos tipos de datos que sean secundarios no tienes por qué meterlos desde el Environment Object, sino que los usas cuando te interese, como una dependencia del View Model de la pantalla que

estés usando. Y si para una pantalla no necesitas ese dato, no lo recoges y punto, pelota. Y por lo tanto, obviamente, tienes muchos menos refrescos inintencionados que no tienen nada que ver. Si tú tienes un dato secundario, pero quieres que sea afectado, eso refresca solo tres pantallas, tienes 10 y lo enganchas en el Environment Object, un cambio de esa fuente de datos va a refrescar las 10 pantallas.

Si lo tienes aislado en un observable aparte, pones la instancia, si la instancia lo coge, simplemente esas tres pantallas se actualizan y el resto, pues no. Es una cosa que, desde luego, es un cambio muy, muy, muy importante y que hace que todo sea mucho más sencillo a la hora de manejarlo. Entonces, la verdad que es un cambio, a mí me parece maravilloso.

La única pega que tiene el cambio es el de siempre. Es iOS 17, porque está utilizando la macro arroba observable, está usando una instrucción, porque las macros son retrocompatibles. Todas las macros son retrocompatibles hasta la primera versión de Swift. Es decir, funcionaría hasta iOS 11. Pero, claro, si tú dentro de la macro metes una instrucción que sólo está soportada en X versión, pues entonces ya estás limitando la macro.

No por la macro, sino por lo que usa la macro. La macro arroba observable está usando una función WithObservationTracking, que es una nueva forma de trazar el cambio de una operación o propiedad, y eso es iOS 17. Entonces, claro, la hemos fastidiado. Apple tendría que hacer que la librería Observation, que es la que la librería de la que forma parte arroba observable, fuera retrocompatible y se pudiera instalar en todas las versiones desde iOS 13.

En ese momento, todo el mundo usaría la nueva arquitectura, todos seríamos más felices y nos olvidaríamos de los ObservableObjects, de los ObservedObjects, de los StateObjects, de los EnvironmentObjects y de todo lo demás. Pues sí, pero Julio, soñar es gratis, pero que Apple haga lo que sueñes no lo es, básicamente.

Pues llevamos casi dos horas de programa y no nos hemos concentrado. Es que te enrollas que da gusto. A lo mejor no llegamos a lo que prometemos. Yo tengo una noticia más rápida. Vale, pues nada, la siguiente noticia es, lo ha publicado en Mastodon, no salimos de Mastodon, seguimos en Mastodon, Jen Simmons, que yo creo que es la sheriff en WebKit, que no es a Fanny, en WebKit.

Y nada, pues ha dicho que hay una nueva versión de Swift Developer Preview, que digamos que es la versión anterior que va saliendo el canal beta de Swift, en la que nos cuenta que esta nueva versión tiene un 94 de puntuación de compatibilidad, de interoperabilidad, mejor dicho. Y por poner un poco de contexto, pues tendríamos que Firefox tiene un 90 en esta puntuación y Chrome y Edge, que por debajo tienen Chromium, que es al final lo que importa aquí, tienen un 96.

Entonces todo esto de que Safari, que patin y patatán, pues naranjas de la China, porque Safari de tecnologías, digamos, está muy muy a la par de Chrome y de Edge. Pero por qué algunas web apps y algunos servicios no son compatibles? Pues yo creo que viene un poco más porque Safari tiene muchos métodos de protección, antirrastreo y demás, que por el hecho de que no sea compatible con X servicios.

No sé si Julio, si tú tienes otra otra opinión. No, no, no, es así. De hecho, se supone que Chromium en breve va a empezar también a hacer tareas de obfuscación de privacidad, igual que hace Safari. Y en ese momento veremos a ver lo que hacen los desarrolladores. Pero claro, aquí el principal problema es que todo el mundo hoy día prueba lo que hace a nivel de web.

O sea, los desarrolladores web ya han dicho paso de probar en navegadores. Yo pruebo en Chrome y punto. Y si lo quiere la gente en Chrome, pues en Chrome, como es el navegador más usado, pues punto pelota. Entonces claro, al final Safari lo sufre. Entonces el hecho de que haya este cambio, pues desde luego es importante. Pero sobre todo lo más importante es que el tema de la privacidad.

Recordemos que Safari lo que hace es obfuscar, impedir que haya seguimiento trazado entre distintas webs. Lo que hace Safari es engañar para que esa cookie de terceros que te deja Booking.com en tu navegador, para que cuando luego vayas a la web de tal, te sugiera el viaje que te has dejado. Porque si tú entras, por poner un ejemplo empírico, tú entras en Booking.com y dices quiero irme de vacaciones a, yo qué sé, al rompío en Huelva, por ejemplo.

Pues si me quiero ir ahí, busco apartamentos. Pues ahora prepárate porque vas a estar una semana viendo anuncios de apartamentos en el rompío en toda página puñetera web que entres. Claro, porque se han quedado ahí marcados. Entonces con Safari ese cruce de datos no es posible. Safari le da un identificador distinto a cada web, por lo que no tienen forma de machear los datos y por lo tanto en Amazon o en la web que sea no te va a salir nada.

Pero en muchas ocasiones, y a mí me ha pasado, tienes que desactivar esa protección de datos cruzados porque resulta que están usando esa forma de datos cruzados para que una web funcione. Y entonces, claro, pues tienes que quitarlo para que o usar Chrome, que es lo que yo normalmente hago.

En este caso Chrome, a ver, lo tengo instalado, pero normalmente que suelo usar ese Edge. Pero bueno, pues este cambio, desde luego, es interesante. Pues sí, pero bueno, quería dejar el mensaje este de que no engañen muchas veces, que dicen es que los de Apple vienen con Safari y aquí no hacen nada. A ver, no. Safari es un buen motor. ¿Qué es mejor o peor que Chrome? Pues ni lo sé, ni creo que probablemente nadie lo sepa, porque siempre hacen test de rendimientos, pero seguro que una versión es más rápida que otra

por X cosa. Luego el otro te adelanta, depende del test que hagas y todas las cosas. Que yo en mi día a día, por ejemplo, uso Safari por el tema de la sincronización de cuentas. Pero eso, que nos vengan con el cuento de que Safari es peor, es que no soporta porque están muy parejos, ¿vale? Pero muchas veces el problema es ese, que no pueden hacer este cruce de datos.

Entonces, pues hay muchas empresas que te lo desaconsejan. De hecho, no me acuerdo, que ya cada vez empiezan a funcionar más. Eso sí, hay algunos que te avisan. De hecho, en el programa que estamos grabando Julio y yo, yo como soy un outsider, estoy en Safari, pero ahí te avisan.

Safari suele dar problemas. Pues no lo sé. O sea, me lo creeré, pero a mí no me está pasando. Yo, de hecho, como servidor de la conexión en la que está conectado Arturo, ¿vale? Arturo, ahora para grabar este podcast, ¿vale? Que seguro que lo oís en Cuonda, ¿vale? Pero este podcast también se emite en directo en Twitch, ¿vale? En twitch.tv barrapelcoding. Emitimos en directo y estamos aquí, pues en vídeo, los dos charlando, comentando.

Luego el audio de este directo se posproduce, o sea, se coge el vídeo de este directo, se coge el audio que grabamos cada uno por nuestra parte, se posproduce, se deja bonito y con él se hace el podcast. Pero la grabación queda en Twitch, ¿vale? Y de hecho podéis estar atentos a lo que es el canal de Twitch, twitch.tv barrapelcoding y ahí pues podéis asistir en directo a estas grabaciones como están ahora, pues algo más, casi 35 personas ahora mismo en directo viendo cómo

grabamos, ¿vale? Entonces, para hacer esta unión yo no uso ningún tipo de software como, pues yo que sé, alguno que hay por ahí de... no me acuerdo, ¿vale? Los que usa todo el mundo, StringArt, ¿no? Y cosas así, ¿vale? No, yo estoy usando aquí una herramienta gratuita, abierta, que se llama vvdo.ninja, ¿vale? Que básicamente lo que hace es construir una...

un servidor web en el que yo le doy una url a Arturo, Arturo se conecta a ese servidor, recojo la url de él y como elemento de web lo pego en mi layout de OBS, ¿vale? Y entonces así, pues yo me puedo construir mis propios layouts y así es como yo funciono, ¿vale? Entonces el servidor ahora mismo está corriendo en Chrome, en mi máquina, pero Arturo, pues como es un poco outsider, a pesar de que yo le he dicho, no uses Safari, pues nada, él usa Safari para comprobar que Safari también es bueno.

Así que bueno, ese sería el tema. Pues como ya llevamos casi dos horas, yo creo que lo que vamos a hacer es cerrar con la respuesta a una de las dudas que nos ha mandado uno de nuestros oyentes, ¿vale? Y luego en otros sucesivos programas iremos contestando otras dudas que nos iráis mandando, ya tenemos un par por ahí almacenadas, pero si queréis enviarnos cualquier duda nueva, pues podéis hacerlo a caffe.swift, c-a-f-f-e, swift, arroba gmail.com o a través de nuestro x que es caffe.swift, arroba caffe.swift, también con dos f.

Y estamos también en Mastodon, ya que hemos hablado de Mastodon, ¿vale? También tenemos una cuenta en Mastodon que también podéis citarnos ahí, que es la en el servidor de Cuonda, ¿vale? Tenemos lo que es arroba caffe.swift con dos f, arroba cuonda.social, ¿vale? Entonces ahí pues también podéis enviarnos cualquier cuestión. Así que vamos a ir a esta última parte de las dudas de los oyentes y contestamos esta. Y cuéntanos Arturo, ¿de quién es la duda que tenemos? Porque es un viejo conocido, ¿no? De

ambos. Pues sí, pues es nuestro nuestro amigo Waika, que le mandamos un saludo y un abrazo muy fuerte, al que tengo que avisar siempre cuando veo la carrera. Hablo con él de Fórmula 1 y cuando veo la carrera de Fórmula 1 tengo que avisar. Cuando no puedo verle, la voy a ver en diferido, nos avisamos.

Oye, no me dijo antes nada de la carrera. Y nada, a ver si nos vemos. Nos vimos los tres la última vez en las J-POD. En las J-POD, sí, efectivamente. Sí, sí. Estuvimos ahí de cháchara y la verdad que fue interesante y estuvo estuvo guay, sí, sí. Pues sí, y pues Waika nos cuenta qué hacemos.

Nos hace así una pregunta, que son varias. ¿Qué hacemos cuando tenemos una aplicación de cinco o diez años? De estas que ya tienen polvo encima. Sí, directamente la pasamos hasta a SuiteUI. Si la aguantamos y cómo le planteamos al cliente cuál es la mejor manera de poner al día o actualizar esta aplicación. Y bueno, si quieres, cuenta tú, Julio, cómo lo ves y luego te cuento yo.

A ver, yo soy bastante radical. Es decir, yo soy de los que le dicen al cliente, mira, esto no... si quieres algo serio, esto lo tienes que refactorizar, ¿vale? Esto no... Y si te dicen, no, es que claro, la aplicación, tal, la funcionalidad, no sé cuánta, le dices, bueno, pues yo te la mantengo con la versión esta que tienes, incluso en Objective-C, pero que sepas que te va a costar mucho más cara, ¿vale? Porque cualquier cosa, mientras sea simplemente ir compilando, ¿vale? Y que vayamos probando que las distintas betas que vayan saliendo, ¿vale? Siga

compilando y siga funcionando y hacer pruebas unitarias de todo y comprobar que todo sigue funcionando. Sobre todo, aquí hay una cosa importante a tener en cuenta, que no es lo mismo una app de Swift que una app de Objective-C, ¿vale? La app de Objective-C es más fácil que se mantenga en el tiempo con menos cambios que Swift, ¿vale? Con Swift, si la aplicación es anterior a Swift 4, la cosa empieza a ser compleja y si la aplicación es anterior a Swift 3, entonces tienes

un lío muy gordo, ¿vale? Porque migrar una aplicación de Swift 1 o 2 a las versiones actuales requiere mucho trabajo, ¿vale? Porque depende de hasta dónde llegue la versión, tienes que cambiar muchas cosas y, sobre todo, lo más complejo es que los conversores de versiones de Swift están en versiones muy antiguas de Scode, ¿vale? Versiones muy antiguas que, además, no vas a poder ejecutar en versiones más modernas de los sistemas operativos, por lo que vas a tener que buscarte

las castañas de un equipo que sea antiguo. Yo, por ejemplo, la última vez que hice esto, tuve que hacer una conversión usando mi MacBook Pro que se quedó en... no recuerdo, creo que fue la versión anterior a Big Sur, me parece, el MacBook Pro de 2011, que todavía tiene una versión Scode 10 u 11, que me permitió hacer la conversión de Swift 1 y 2 a Swift 3, ¿vale? Una vez ya lo tienes en Swift 3,

ya sí es más simple llevárselo a las versiones superiores, entre comillas. Si te lo puedes llevar a Swift 4, mejor, ¿vale? Pero el tema es que, con Swift, insisto, es más complicado por la propia evolución que ha tenido Swift y porque, al final, ciertos cambios los tienes que hacer con el conversor, ¿vale? En mi caso, repito, si es Objective-C, es más simple porque Objective-C, si el código es Objective-C y es muy legacy, curiosamente sigue funcionando bien.

Eso sí, siempre y cuando no choque con algún bug posterior que tenga la librería, como por ejemplo el que hemos comentado al principio, de que de pronto te deje de pintar correctamente los elementos, ¿vale? Pero no podemos olvidar que, desde Scode 5, ya se podía usar los Storyboards, ¿vale? Y que, también te puedes encontrar proyectos que vengan de versiones mucho más atrás, que estén usando X y B, cosa que, a día de hoy, siguen funcionando, ¿vale? Entonces,

el tema es cuestión de coste y tiempo, ¿vale? Mantener una aplicación de esas características supone mucho más coste, supone mucho más tiempo y es cuestión de decirle al cliente, mira, esta aplicación no te la voy a poder evolucionar todo lo que tú quieras, no voy a poder modernizarla como tú quieras, sólo se puede mantener y que vaya funcionando versión a versión y que, si hay cualquier problema, pues se pueda anteceder el problema para ponerla al día,

¿vale? Entonces, si él decide que no la quiere refactorizar, entonces, pues, es simplemente ir manteniéndola y que siga viva. Repito, si es Objective-C, ¿vale? En código legacy. Si es Swift, repito, si es Swift 1 o Swift 2, hay que hacer un proceso de migración para que compilen las versiones más nuevas porque no podemos olvidar, y esto es algo que hay que tener muy presente, que cada nueva versión de macOS prohíbe usar la versión anterior de Scope, como hemos comentado,

pero en abril del año X Apple obliga a que todas las apps que se suben al App Store estén compiladas con la SDK lanzada en septiembre del año anterior, por lo que en marzo-abril de 2024 todas las apps van a tener que estar compiladas en la SDK de años 17.

En abril-marzo de 2023 todas las apps tuvieron que estar compiladas, todas las apps nuevas y antiguas, o sea, nuevas y actualizaciones, tenían que estar compiladas con la SDK de, pues eso, con la SDK de años 16, ¿vale? Entonces, claro, eso supone que tú quieras o no, si quieres que tu app esté viva a día de hoy en el App Store, porque si no Apple te la va a borrar, ¿vale?, porque es código legacy, por lo tanto, si no la actualizas Apple te la borra, a mí me lo ha hecho, Apple me ha borrado a mí tres aplicaciones que yo

ya no actualiceba desde hace varias versiones y me las ha borrado, ¿vale? Me advirtió, me dijo, tiene usted seis meses para actualizarla, como no la actualice se la borro, y si la quieres actualizar y que esté soportada en las últimas versiones del kit de desarrollo, tienes que coger todo ese código y pasarlo.

Insisto, si es Obyectives es más fácil, si es Swift hay que hacer obligatoriamente una adaptación, que cuanto más atrás sea la versión de Swift, más coste va a tener esa adaptación hasta la última versión, ¿vale? De forma que adaptar un código de Swift 1 o Swift 2 pueden ser fácilmente dos semanas mínimo de trabajo en una aplicación para dejarla aniquelada y que compile sin ningún problema, siempre y cuando no tenga librería de terceros, porque como tenga librería de terceros y esa librería de terceros estén obsoletas a nivel de cuando Franco era corneta,

o sea, olvídate, son meses de trabajo, por lo que llega un momento y dependencias que a lo mejor tienes que cambiar porque a lo mejor esa librería dejó de existir hace cinco años y tienes que buscar una nueva porque patata, ¿vale? Porque el que sea pues encontró trabajo y no le apetecía seguir, ¿vale? Entonces, o cambió a una nueva que hay que implementar desde cero, ¿vale? Por lo tanto, es una locura de volverte loco.

Así que, al final, ¿qué sucede? Pues que lo más fácil en muchos casos, cuando tienes una app que es muy antigua y no hay más forma de actualizarla correctamente, pues es decirle al cliente la verdad, es decir, decirle, mira, Apple obliga, y aquí te enseño las notas y los correos que manda Apple, a que tú todos los años tienes que cumplir la, el que la aplicación se compile con la última versión de Scope y tu aplicación es imposible que se compile tal como está estructurada, tal como está hecha en una versión muy antigua de Swift o

en una versión, pues en este caso, con ciertas librerías de terceros que son, pues, imposibles porque habría que usar librerías nuevas o a lo mejor la nueva versión de la librería está usando la versión 4 y la actual es la 10, ¿vale? A mí me ha pasado, ¿vale? De usar una dependencia de una aplicación que estaba en versión 3 o 4 y la última es la 10 y dices, hostia, entonces, claro, hay cambios ahí de código que rompen a nivel de compilación y tienes que refactorizar todo ese

código de cero. Cuando ya llega un punto en el que ya son meses de trabajo para adaptar esa aplicación, sale mucho más rentable borrón y cuenta nueva y hacerla entera en SwiftUI porque SwiftUI tardas la mitad de lo que tardarías con UIKit y, pues, le das un nuevo aire a tu aplicación y con SwiftUI, una vez ya estás en SwiftUI y en una versión posterior a Swift 5, ¿vale? En el caso de Swift hablaríamos a partir de Swift 5.1 y en el caso de SwiftUI a partir de SwiftUI 3 para

iOS 15, ¿vale? A partir de ahí ya tienes una versión lo suficientemente estable como para que el mantenimiento año tras año sea menor y, por lo tanto, sea un coste correctivo normal y que la evolución del producto, pues, pueda ser sin ningún problema. Pero, claro, también te vas a enfrentar al problema de que ahora vas a estar en iOS 15, por ejemplo, pero dentro de un año te va a decir el cliente, pues, o le vas a decir tú, oye, esto tiene que pasar a iOS 16.

Entonces, ¿qué vas a hacer? ¿Vas a meter los navigation stack en vez de los navigation views? O si te pide algo que tenga que ver con los navigation stack, entonces te peleas para que te deje subir a la 16. Ahí ya te peleas con SwiftUI y con la puñetera de que aún no sea totalmente retrocompatible, ¿vale? Entonces, bueno, pues eso sería un poco la respuesta corta.

No, a ver, la verdad es que yo haría prácticamente lo mismo que os he dicho, pero hay que separar un poco primero el código y luego el framework. Serían las dos partes a estudiar. Sí que es verdad que emigrar Swift de determinadas versiones es un poco rollo, pero bueno, también la propia UIKit.

Yo hace poco también me mandó a Apple en uno de esos correos de, oye, esta aplicación la tienes que actualizar. Y pues le eché un rato y vi que no me merecía la pena porque necesitaba bastante trabajo. Y luego hace un año también me pasó con otra aplicación que tengo y ahí lo que hice fue pues cargarme las dos vistas que me daban problemas y pasarlas a SwiftUI.

¿Qué es lo bueno? Que es interoperable. Entonces puedes ir paso a paso o mirar a ver dónde te trabas o dónde ha dejado de funcionar. Necesitas cambiarlo sí o sí y hacerlo. Pero bueno, la recomendación primera es cosas tan, tan antiguas y sobre todo sin mantenimiento. Lo de siempre es lo de, entonces me estás diciendo que una aplicación cada año tengo que cambiarla.

No, cada año sí que hay que hacerle un pequeño mantenimiento para que no pasen cinco años y en esos, o sea, y al quinto año el mantenimiento sea horrible. Hay que ir pasito a pasito. Por eso estaban los asistentes de migración que había en su día, que te facilitaban la tarea, pero el problema era cuando lo dejabas muchos años sin, sin tocar.

Y sí que es verdad. Las aplicaciones, y ya si es algo híbrido ya ni te cuento, pero bueno, quitando las híbridas, las aplicaciones nativas, sí que es verdad que hay que darles un vistazo. Y esto ya lo cuento a la gente que pide los servicios de desarrolladores para esto. Sí que es verdad que merece la pena. Si tú tienes una aplicación, no quieres cambiar, la funciona bien y tal, oye, sí que te merece la pena que cuando vaya a llegar la fecha de las nuevas versiones, oye, que hables con algún

desarrollador y le digas, oye, ¿me puedes echar un vistazo a la aplicación? Porque probablemente te salve de problemas si dentro de medio año vas a querer añadirle algo o dentro de más tiempo, probablemente te salve de problemas haber dado ese paso anterior y luego te ahorrará dinero. O sea, a la larga te ahorrará dinero.

Y como, porque también sí que es verdad que hay como un poco esa, y yo creo que el problema tiene las consultoras, que lo que quieren obviamente sacar máximo dinero a los clientes, algunas, perdón, porque siempre hablo así en general, algunas consultoras que lo quieren sacar dinero a toda costa de todos los proyectos y que siempre parece que está todo mal, que te voy a borrar todo.

No, es que la mayoría de las veces, si es código muy antiguo, sí merece la pena el borrar ciertas cosas porque te va a salir mejor y no merece la pena enrocarse en estar poniendo parche sobre parche, porque a mí me ha pasado en muchos proyectos de, oye, estamos con este, yo qué sé, un componente X, estamos poniendo parche sobre parche y nos ha llevado, me lo invento, 20 horas.

Joder, es que a lo mejor en 20 horas hubiésemos tirado lo que había, hecho algo nuevo, bien testado, con test unitarios, con test de integración, utilizando async await, utilizando herramientas avanzadas, y es que a lo mejor, incluso voy más allá, a lo mejor no me lleva 20 horas sino que me lleva 25, pero los cimientos que tengo para que eso vaya creciendo son mucho mejores que los que tenía en esas 20 horas con algo que no sé por dónde se va a romper.

Y si vas paso a paso, por lo que te comentaba el otro día, que había en Scope 15 hay algo que me crasea la aplicación y que no tengo manera de preverlo, que es un fallo, pero esos fallos se dan. Entonces, si vas saltando versión a versión, eso imaginaros que esto ha sido en esta versión, pero bueno, en la primera vez que salta ya lo ves, no lo ves con dos o tres versiones de decalaje que tienes cuatro errores de este tipo que de repente te explota la aplicación y no sabes dónde.

Así que yo siempre, y bueno, hace un tiempo que no trabajo en plan en un proyecto y cobrando un mantenimiento, pero sí que está bien eso de, pues bueno, ya según sea el profesional, pues los hay más honestos y menos, pero un mínimo de mantenimiento siempre recomendable para la aplicación. Yo es algo que siempre pongo en todos mis proyectos, ¿vale? Creo que lo que ha dicho Arturo es absolutamente, absolutamente clave, ¿vale? Que todas las apps tienen que tener un

mantenimiento anual de revisión con las nuevas versiones de Scope y dejar funcionando tu aplicación con la nueva SDK. Si no hacemos eso en septiembre, octubre, podemos tener serios problemas porque, por ejemplo, el error que se ha encontrado Arturo con la SDK de iOS 17 es un error de cuelgue de las apps absoluto.

Es decir, alguno diría, hombre, es un error de Scope 15, ¿no? Perfecto, pero ¿qué es lo que pasa? Que si tus usuarios actualizan a iOS 17, ya no van a usar la SDK de iOS 16, van a usar la SDK de iOS 17, por lo que ese error que a ti te sale en Scope y que se cuelga la aplicación, le va a pasar a todos los usuarios que se descarguen la aplicación teniendo iOS 17 con el binario de la versión anterior.

Por lo tanto, tu app va a crasear. Y ojo, vamos a poner una nota positiva que le hemos comentado en el programa. En la aplicación de Ice Cube decía que solo por el hecho de compilarlo con la última versión del SDK hacía que fuese más rápido porque compilaba contra versiones nuevas de las librerías en las que se han mejorado cosas.

Claro, porque optimiza ya no sólo eso, sino que optimiza el código intermedio que genera Swift, ¿vale? Y entonces, pues ese código intermedio, lógicamente, los enlaces son más óptimos, la integración con C++ también ha permitido, porque una de las cosas que hacen que las nuevas versiones de iOS, Mac, etcétera, funcionen mucho más fluidas es la reducción de la constante traducción de tipados entre Objective-C, C y Swift, ¿vale? Porque cuando tú tienes un tipo en Swift y tienes que pasar eso a Objective-C o a C,

y luego de Objective-C a C volverlo a Swift, y luego de Swift volverlo otra vez a C porque tienes una capa de abstracción que va y viene en distintos lenguajes, todo eso es muy costoso. El encontrar las equivalencias y las inferencias, etcétera, por lo que el trazado que tiene hace que todo vaya más lento.

Todo eso ahora se ha optimizado y hace que todo funcione mucho mejor. Entonces, lo peor que puedes hacer, porque va a ser un problema muy gordo para ti, es dejar una app abandonada durante años, ¿vale? Porque entonces ahí es donde tienes el problema, donde yo he explicado todo ese proceso, ¿vale? Que parte de una premisa en la que te cae una aplicación que no se ha actualizado desde no sé cuántos años, ¿vale? Y por lo tanto, pues a echarla a andar en las versiones nuevas es tal.

Si esa aplicación, sea Objective-C, sea Swift, sea la que sea, se ha ido mimando año tras año, y se ha ido manteniendo año tras año, y se ha ido probando año tras año, y se ha ido compilando con la versión SDK de las nuevas versiones, da igual que la aplicación tenga un código de hace 10 años. Ya lo tienes compilado en la última versión, por lo que el mantenimiento, como es progresivo, va a ser mucho menos costoso, y esa aplicación de un código de hace 10 años podrá seguir dando servicio durante otros años

más sin ningún problema, y no habrá que refactorizarla. Cuando se plantea el que hay que refactorizar, es cuando coges una aplicación que hace 5, 6, 7 años que no se ha tocado, y por lo tanto, sigue en versiones antiguas, y ahora se quiere poner al día. No. Entonces, ahora ya se complica.

¿Vale? Esa es la diferencia, creo yo. Sí, sí. Exactamente, la verdad. Y eso, Waika lo pone desde que está en nuestro punto, de cómo se lo cuentas al cliente, pero bueno, yo siempre digo que está bien que los clientes sepan un poco de esto, porque sí que es verdad que hay gente mala ahí fuera. Se ha abusado mucho. Yo hace años que no trabajo directamente con estos proyectos, pero cuando trabajé en su día, venía muchísima gente rebotada, muchísima gente que decía, no, es que miran el proyecto y ya me

van a cobrar no sé cuánto ya solo por abrirlo, aunque no haya que tocarlo. Bueno, eso se puede hablar. Está claro que no va a ser gratis, porque abrir un proyecto lleva tiempo, y ver el alcance de los cambios de un proyecto lleva tiempo. Hombre, ¿te cuento el último que hicimos tú y yo? Bueno, todavía la versión de Android tenía un pase, según comentaste. Julio, no cuentes que hago Android.

Pero solo en ocasiones. Me lavo las manos, además, antes de tocar. Y luego lavas el teclado al abrir Android Studio y tal. Pero si estamos hablando de la versión que había en Apple, yo le tuve que cobrar horas de trabajo a este cliente, que si no me equivoco creo que al final cobramos 20 horas entre los dos o por ahí, no recuerdo ahora mismo.

Pero vamos, fue una cantidad de dinero importante solo por abrir la app y ver lo que hay dentro. Porque claro, esto es algo que tú no has hecho. Entonces, esta aplicación tenía cerca de 20 dependencias de terceros, de volverte loco. Y eres como, pero bueno, pero de verdad, pero que si es una aplicación de cuatro pantallas, ¿dónde va? Con más de mil líneas de código, decenas de ficheros, no sé qué.

Había montado ahí un Jirigai, una infraestructura de traducción de los textos cuando la aplicación estaba solo en inglés. Era una cosa como, pero tú estás loco. Yo creo que es lo peor que yo me he topado en mi vida. El mayor desastre de proporciones épicas que lo que hacía era que aquello ni era SwiftUI ni era nada. Aquello era un destrozo hecho por alguien que lo que había cogido era SwiftUI y lo había convertido en otra

cosa que para él era más cómoda. Lo peor que he visto en mi vida. Y claro, pues simplemente el levantar y el ver cómo funcionaba aquello, obviamente tuvo un coste. Entonces, depende mucho. Cuando tú quieres dar soporte a una aplicación que no es tuya, lo primero que tienes que hacer es acceder a ese código fuente y poder validar qué te supone levantar esa aplicación.

Ver cómo esa aplicación está hecha, ver qué dependencias tiene, ver cuál es el gestor de dependencias que tiene, porque en este caso por lo menos estaba usando SwiftPack y Manager, no usaba CocoaPods. En otras ocasiones yo me he encontrado proyectos con CocoaPods que han sido como un infierno. De hecho, yo con uno de los últimos clientes que tuve, no hace demasiado, al final lo que le convencí fue para que quitara CocoaPods y lo pasara todo a SwiftPack y Manager. Y al final se hizo y eso pues es una ventaja que él cogió.

Por lo que aquí, como digo, el primer coste que tienes que asumir es el levantamiento de la aplicación. Y eso puede ser fácil, dependiendo de cómo esté hecha la aplicación o no, semanas de trabajo para levantar y entender cuál es la arquitectura, cómo está estructurada, cómo se conectan las clases, cómo está montada a nivel general, etcétera.

Y cuanto más se aleje de lo nativo, peor en todos los sentidos. Y ya una vez tienes la aplicación levantada y ya sabes qué es lo que tiene y de qué pie cojea y qué cosas tienes que hacer, pues ya tendrás que presupuestar lo que tú consideres que sea el tiempo necesario para ponerla al día, para que puedas compilar y ejecutar en el actual sistema operativo y en la última SDK con Scope.

Y luego ya a partir de ahí, si quieren meter cosas, pues tendrás que valorar el trabajo. Eso es que a veces te dicen, no, si sólo quiero meter este botón, ya claro, pero para arrancarte el proyecto con ese botón de esa aplicación que hace dos años que no tocas, pues es que es un maldito infierno y no... En esta última, porque nos decían eso, es que quiero meter un botón, pero es que para meter ese botón tengo que averiguar cómo esta arquitectura, que no es SwiftUI, mete un botón.

Porque aquí estaba usando patrones setter getter, constructores de no sé qué, botones de no sé cuántas... No era poner botón y luego una llamada, no, no, no, no, no. Estaba montado sobre una arquitectura que era una auténtica basura, que para tocar cualquier cosa había que pasar por 7, 8, 9, 10 clases de pendiente, ir de una en otra, saltar de un lugar a otro y luego todo controlado por una librería de terceros llamada navigation stack, que tenía que ser la responsable de

todo el flujo de navegación porque no usaba la navegación nativa, porque era una librería que estaba poniendo por detrás gestiones de push y pop a través de UIKit. Entonces, claro, era un puñetero infierno. Claro, no es cuestión de poner un botón, es cuestión de cómo se pone un botón con esta mierda que ha hecho aquí el que sea, que para él será muy cómodo.

Pero claro, yo no tengo un manual de instrucciones de cómo se puede poner un botón con la basura esta que me han dado. Entonces, pues claro, meter las manos en la basura no es fácil ni cómodo. Lávatelas como yo cuando acabo con Andrés. Básicamente, básicamente. Pues no sé, algo más que aportar al respecto.

No, yo creo que la verdad que hemos contado un poquitillo a raíz de la pregunta de Waika el tema y sobre todo, ya te digo, yo creo que hemos dejado claro tanto de la parte de cliente como del profesional al que están contratando, que al final hay que ser honesto, pero las cosas valen lo que valen. Yo creo que es el resumen. Sí, básicamente.

Y que desde luego aprendan la lección de que no se puede dejar ningún desarrollo, ya no hablamos de Apple, ¿de acuerdo? Ningún desarrollo hay que dejarlo ahí y esperar que siga funcionando, porque tal como funcionan hoy día los sistemas, no. Entonces, al menos una vez al año, cuando hay una nueva versión de lo que sea, hay que ir revisando, comprobando que todo está bien, que cada cosa está en su sitio, todo tiene que tener, todo proyecto tiene que tener como mínimo, mínimo, mínimo, mínimo, mínimo, un presupuesto destinado a un mantenimiento correctivo

anual basado en los ciclos de vida de las herramientas con las que está hecho. Y a ver, si hablamos de web, pues imagínate, ¿vale? No hay nada peor en este mundo que, yo que sé, por ponerte un ejemplo radical, ¿vale? Montarte un WordPress, pones una página web y la dejas ahí. Pues hostia, cuando empiezan a salir versiones de WordPress nuevas, empieza a subir la versión de PHP, empieza no sé qué, ahora tú dile a alguien que trabaja con WordPress que coja una web que se

hizo en WordPress hace siete años y que la ponga al día con todos los plugins que han metido ahí para eso. O sea, se te suicida. Pues te voy a decir una cosa, tengo, bueno, es que me he encontrado con un proyecto con WordPress, pero que encima está metido por FTP en el servidor, que bueno, bueno, una magia, una magia me he encontrado ahí, pero es que a lo mejor me tienen una semana intentando averiguar dónde estaba ese WordPress y porque tampoco sabía dónde estaba la web y me dio por

poner el barra wp barra guionadmin y dije, ah, vale, es un WordPress, porque no sabía ni cómo estaba hecha la web. De un proyecto abandonado. De un proyecto abandonado, que además no podemos olvidar que WordPress, por terminar el ejemplo, es el CMS más utilizado en web y lógicamente también es el más atacado, por lo que o vas parcheando cualquier tipo de problema de seguridad o te arriesgas a que

te secuestren la web y empiecen a ponerte ahí lo que les dé la gana, desde venta de criptomonedas falsas hasta ponno o lo que sea menester. Y nada, pues yo creo que ha quedado claro, lo sentimos. El próximo día haremos otro programa de respuesta a preguntas donde realmente respondamos a vuestras preguntas, pero podéis hacernos llegar más preguntas al correo, podéis hacernos... ¿Qué es? Ay, se me ha ido el correo.

Cafésuif arroba... ¿Cafésuif podcast? No, Cafésuif arroba gmail.com, a Twitter, a Mastodon, arroba Cafésuif en x, perdón, y arroba Cafésuif arroba uonda.social. Y nada, yo creo que no nos liamos más y vamos con la despedida. Pues poco más, básicamente. Muchísimas gracias por escucharnos, espero que hayáis aprendido algo nuevo.

Ya sabéis que podéis encontrarme a mí en x como arroba jcfmunoz, en Mastodon como jcfmunoz, Mastodon.social, en BlueSky jcfmunoz arroba como es bsky... no sé qué, ni idea. Yo es que tengo BlueSky desde hace poco y solo es... a veces cuando grabamos y veo que publicas y luego Alex Barredo tiene, y sí que está todo el día ahí, pero la verdad es que entro poquito. Igual, pues mira, efectivamente es jcfmunoz.bsky.social, ese sería en BlueSky, BlueSky es el Twitter del antiguo dueño de Twitter.

Y luego el resto igual, podéis encontrarme como jcfmunoz, de hecho las dos redes donde estoy más activo es en x y también en Linkedin, linkedin.com barra in barra igual jcfmunoz. No obstante, podéis encontrar toda mi información en mypublicinbox, si entráis en mypublicinbox barra jcfmunoz, pues tenéis ahí toda la información, todas las redes, todo donde estoy y así podéis seguirme en ellas.

Por la calle no, pero en cualquier red podéis seguirme sin problema. ¿Y dónde puede encontrarte la gente a ti, Arturo? Pues a mí donde más estoy también es en nx.arturoribasa, en Mastodon, arturoribasa.mastodon.cloud. En Linkedin también es arturoribasa. Y luego en mi otro podcast, que es Vidas Digitales, donde somos algo menos cafeteros.

Y bueno, podéis encontrar toda la información sobre mí en www.arturorribas.com. Así que lo dicho, muchísimas gracias a todos por estar ahí estas más de dos horas de programa, donde espero que hayáis aprendido un montón de cosas y nos oímos pronto si Dios quiere. Y hasta entonces, pues ya sabéis que lo que tenéis que hacer, la mejor manera de aprender a programar, a depurar, a ser mejores programadores, es jugar con el código.

Así que nos vemos en la próxima. Chao. Chao. Puedes escuchar más episodios en cuonda.com, la comunidad de podcasts independientes en español.

Episodios recientes

3⨯13 Migrando a Swift 6
3⨯12 Diario de la WWDC24
3⨯11 El póker de la #wwdc24

Programas relacionados

Apple Coding Apple Coding, todo sobre el desarrollo en sistemas Apple. Julio César Fernández, evangelist de desarrollo, te trae cada semana análisis, noticias, charlas... para conocer cómo funciona la tecnología por dentro. tecnologia
Nebuchadnezzar A bordo de la Nebuchadnezzar, Oliver Nabani y Julio César Fernández repasarán cada 15 días la actualidad tecnológica, analizando y descubriendo lo que hay detrás de la misma. tecnologia
Apple Coding Daily Comentario y análisis de las últimas novedades del mundo de la tecnología por, para o relacionado con los entornos Apple, desde el punto de vista del desarrollo y la programación. tecnologia