WEBVTT
Kind: captions
Language: es

00:00:00.000 --> 00:00:08.680
Cuonda, la comunidad de podcast independientes en español.

00:00:08.680 --> 00:00:33.440
Bienvenidos a CAFÉ SWIFT, el podcast donde hablamos del lenguaje de programación SWIFT

00:00:33.440 --> 00:00:39.840
de Apple, solo no.

00:00:39.840 --> 00:00:45.240
Hablamos de programación, de herramientas para desarrolladores y de distintas experiencias,

00:00:45.240 --> 00:00:51.000
pero siempre desde el punto de vista de desarrolladores en entornos Apple y del lenguaje SWIFT.

00:00:51.000 --> 00:00:55.880
Y esos desarrolladores somos Arturo Rivas y Julio César Fernández.

00:00:55.880 --> 00:01:13.600
¡Comenzamos!

00:01:13.600 --> 00:01:18.320
Hola hola hola, hola a todos, bienvenidos a otro CAFÉ CON SWIFT.

00:01:18.320 --> 00:01:24.440
Ya tercera temporada, ya un poco rodada y hemos dicho, vamos a aprovechar que Tim Cook

00:01:24.440 --> 00:01:30.640
anda por Madrid para que, por supuesto, no se venga a CAFÉ SWIFT.

00:01:30.640 --> 00:01:37.200
No, a ver, quería venir, pero le hemos tenido que decir, no mira Tim, nos pilla mal y tal,

00:01:37.200 --> 00:01:40.080
tenemos obligaciones, ya si eso quedamos otro día, etcétera.

00:01:40.080 --> 00:01:41.080
Entonces, bueno.

00:01:41.080 --> 00:01:44.680
Estamos mucho con lo de la programación y ya sabemos que a ti te van otras cosas.

00:01:44.680 --> 00:01:47.800
Exacto, sí, sí, comer cocido y tal.

00:01:47.800 --> 00:01:52.000
Le vas a aburrir al pobre señor aquí dándole la chapa con SWIFT, no venga.

00:01:52.000 --> 00:01:53.000
Totalmente, totalmente.

00:01:53.000 --> 00:01:54.920
Agradecemos que haya querido venir.

00:01:54.920 --> 00:01:59.960
Es un detalle, es un detalle por su parte, la verdad, se agradece, Tito Tim.

00:01:59.960 --> 00:02:04.520
Y nada, pues estamos aquí otro día más con un café como siempre cargado, o sea,

00:02:04.520 --> 00:02:10.960
no sé cuándo haremos un café ligero y no me lío más porque, como siempre, tenemos

00:02:10.960 --> 00:02:15.800
un montonazo de cosas de las que hablar, así que empezamos con nuestra primera sección

00:02:15.800 --> 00:02:18.720
en la que os contamos qué hemos estado haciendo.

00:02:18.720 --> 00:02:24.720
Bueno, de hecho, por darle tiempo a que termine la cabecera musical, hoy lo que vamos a hacer

00:02:24.720 --> 00:02:31.480
es dedicarnos a responder dudas que teníamos ahí acumuladas de gente que las envía a

00:02:31.480 --> 00:02:34.920
Cafeswift con dos Fs, arroba gmail.com.

00:02:34.920 --> 00:02:38.880
Así que si tenéis cualquier tipo de duda, pregunta, cuestión que queramos que tratemos

00:02:38.880 --> 00:02:43.360
en el programa, pues podéis enviarlo y podemos hacer como ahora.

00:02:43.360 --> 00:02:47.760
Entonces, yo creo que ahora ya sí habrá acabado la música de cabecera.

00:02:47.760 --> 00:02:50.000
Pero es que no soy yo profesional de los podcasts.

00:02:50.000 --> 00:02:55.320
Sí, bueno, es que es cuestión de medición, tiene que, para que dé tiempo a que se acabe,

00:02:55.320 --> 00:02:56.320
así que…

00:02:56.320 --> 00:02:59.440
Los enviados digitales también me han echado la broca a veces por cosas de estas.

00:02:59.440 --> 00:03:04.280
Nada, nada, esto no tiene… si no, yo me… ya has visto que no tengo capacidad de enrollarme

00:03:04.280 --> 00:03:05.920
sin ningún problema.

00:03:05.920 --> 00:03:20.480
Así que ahora sí, comenzamos.

00:03:20.480 --> 00:03:27.600
Pues cuéntanos Arturo, ¿qué has estado haciendo durante estos días desde la última vez que

00:03:27.600 --> 00:03:30.600
grabamos?

00:03:30.600 --> 00:03:34.200
Pues muchas cositas, porque yo creo que lo comenté, que ya volví otra vez al trabajo

00:03:34.200 --> 00:03:40.520
después de las vacaciones y la gente con muchísimas cosas que hacer, con nuevas versiones

00:03:40.520 --> 00:03:46.600
de EOS y hoy os voy a contar mis penas, también tiene que ver con las versiones de EOS, pero

00:03:46.600 --> 00:03:48.760
más con la nueva versión de Xcode.

00:03:48.760 --> 00:03:52.600
Xcode 15, qué bonita.

00:03:52.600 --> 00:03:54.560
Efectivamente, qué bonita.

00:03:54.560 --> 00:03:59.160
Pues yo soy muy de, en cuanto se puede, obviamente depende del proyecto y hay que tener en cuenta

00:03:59.160 --> 00:04:03.840
más cosas, pero yo soy muy de actualizar y sobre todo porque yo me gusta también actualizar

00:04:03.840 --> 00:04:13.280
mi ordenador al siguiente sistema y en Sonoma, que sale oficialmente en un par de días,

00:04:13.280 --> 00:04:19.480
pues no funciona la versión anterior de Xcode, la 14.3.1, solo funciona Xcode 15.

00:04:19.480 --> 00:04:24.240
Entonces, claro, digo, pues lo primero que tengo que hacer es que mis proyectos compilen

00:04:24.240 --> 00:04:28.040
todos en Xcode 15 sin problemas.

00:04:28.040 --> 00:04:35.400
Y este aquí que me encuentro, me he encontrado tres problemas, empiezo por el primero.

00:04:35.400 --> 00:04:38.680
No, I can't believe it.

00:04:38.680 --> 00:04:46.040
El primero y que más o que más esperable era es que el gran gestor de, bueno, gran

00:04:46.040 --> 00:04:53.800
no, el gestor de dependencias Coco Pods no se había actualizado, ¿vale?

00:04:53.800 --> 00:04:58.600
Me pinchas y no sangro.

00:04:58.600 --> 00:05:01.880
Pues la última actualización creo que era de abril, ¿vale?

00:05:01.880 --> 00:05:04.680
Y pues tenía varios problemas.

00:05:04.680 --> 00:05:12.520
Había workarounds, cambiando cosas en el pod file, pues eras capaz de hacerlo, ¿vale?

00:05:12.520 --> 00:05:15.760
Pero no me convencía mucho esta solución.

00:05:15.760 --> 00:05:21.720
Y ayer por la noche creo que fue, o antes de ayer, ya han compilado, vale, una versión,

00:05:21.720 --> 00:05:31.040
ya hay una, lo digo de memoria, una 13.1 creo que es, que ya tiene este parche, ¿vale?

00:05:31.040 --> 00:05:35.440
De hecho, había una, el github es abierto, ¿vale?

00:05:35.440 --> 00:05:40.360
Es un proyecto open source y tal, que estoy viendo que cada vez tiene menos apoyo.

00:05:40.360 --> 00:05:49.240
Una de las cosas por las que no estaba actualizado y yo fui uno de los que escribí un comentario

00:05:49.240 --> 00:05:55.520
de todavía, porque había varias personas pidiendo que lo actualizasen y ya de repente

00:05:55.520 --> 00:06:01.720
me llegó la notificación de que habían contestado, habían cerrado esa issue de github diciendo

00:06:01.720 --> 00:06:07.040
ya he puesto a compilar en cuatro horas o así y estará disponible la versión K.

00:06:07.040 --> 00:06:09.640
O sea, corrégeme si me equivoco, ¿vale?

00:06:09.640 --> 00:06:20.640
El martes día 12, el martes día 18, no, perdón, el lunes día 18 fue cuando salió Scope 15,

00:06:20.640 --> 00:06:23.760
versión final en el App Store, ¿vale?

00:06:23.760 --> 00:06:28.440
Que al que le dio a descargar probablemente hoy domingo ya tiene que estar terminando

00:06:28.440 --> 00:06:37.800
y, pero no funcionaba, es decir, que con la versión final en la calle han tardado X días

00:06:37.800 --> 00:06:44.280
en corregir que se pueda usar CocoPods en Scope 15.

00:06:44.280 --> 00:06:47.840
Como lo has dicho, Julio, es...

00:06:47.840 --> 00:06:53.520
Ya sabéis, niños, no uséis librerías de terceros y, sobre todo, no uséis la librería

00:06:53.520 --> 00:06:56.000
que permite instalar librerías de terceros.

00:06:56.000 --> 00:07:00.680
Pues bueno, tenemos un primer culpable, CocoPods.

00:07:00.680 --> 00:07:02.320
Vamos a por el segundo culpable.

00:07:02.320 --> 00:07:05.640
El primero, sospechoso habitual, me lo esperaba.

00:07:05.640 --> 00:07:06.640
Segundo paso.

00:07:06.640 --> 00:07:15.480
Pues de repente consigo compilar con el walkaround este que os comenté del podfile y explota

00:07:15.480 --> 00:07:16.480
la...

00:07:16.480 --> 00:07:18.840
Me pongo a navegar un poco por la aplicación y explota.

00:07:18.840 --> 00:07:20.680
Jope, ¿qué será?

00:07:20.680 --> 00:07:30.600
De repente veo que al acceder al perfil, digamos, del usuario en la aplicación, explota, ¿vale?

00:07:30.600 --> 00:07:38.040
Y veo que explota con algo de... con una imagen que utilizo el renderer porque se puede renderizar

00:07:38.040 --> 00:07:39.040
o bien la imagen, ¿vale?

00:07:39.040 --> 00:07:42.800
Si hay imagen, es una vista un poco extraña, pero bueno, renderiza si hay imagen.

00:07:42.800 --> 00:07:47.600
Y si no, lo que hace es renderizar la vista como imagen, ¿vale?, para trabajar siempre

00:07:47.600 --> 00:07:53.800
con formato de imagen y es las iniciales del nombre del usuario, por si el usuario todavía

00:07:53.800 --> 00:07:55.480
no ha subido la foto.

00:07:55.480 --> 00:08:01.280
Y resulta que la librería que estaba utilizando o una función de la librería que estaba utilizando

00:08:01.280 --> 00:08:02.640
estaba deprecada.

00:08:02.640 --> 00:08:10.400
Pero lo que me mosquea es que el proyecto compila sin problemas, pero casca en la versión...

00:08:10.400 --> 00:08:13.080
Cuando lo compilas contra el SDK de iOS 17.

00:08:13.080 --> 00:08:19.380
Pues eso no es un deprecado, eso es un obsolete, o sea, eso es que lo han quitado directamente

00:08:19.380 --> 00:08:23.920
y se les ha olvidado marcarlo como obsolete para no dejarte compilar.

00:08:23.920 --> 00:08:25.920
La idea es esa, que no te deje compilar, ¿por qué?

00:08:25.920 --> 00:08:32.040
Porque imaginaros que yo no pruebo eso y la saco así porque digo, a ver, esto me compila.

00:08:32.040 --> 00:08:39.040
La idea es que se puede haber un gliss de alguna vista que no se dibuje, cosas que empañen

00:08:39.040 --> 00:08:44.480
un poco el uso, pero que explote directamente debería ser algo contemplado antes de...

00:08:44.480 --> 00:08:47.160
O sea, en tiempo de compilación, ¿vale?

00:08:47.160 --> 00:08:51.480
Entonces el segundo culpable es Apple, que no diría...

00:08:51.480 --> 00:08:56.360
Que a veces hace estas cosas, no es el punto habitual, pero...

00:08:56.360 --> 00:08:57.360
Es el problema.

00:08:57.360 --> 00:09:04.360
Ya sabemos que, por ejemplo, en SwiftUI este año ha habido bastantes cambios de deprecación.

00:09:04.360 --> 00:09:09.360
Por ejemplo, en SwiftUI, por sin ir más lejos, ¿vale?

00:09:09.360 --> 00:09:17.520
De pronto han decidido que las Toolbars ya no se llaman Navigation Leading Bar o algo

00:09:17.520 --> 00:09:22.480
así, Navigation Trailing Bar, sino que ahora se llaman Top Bar Leading y Top Bar Trailing,

00:09:22.480 --> 00:09:23.480
¿vale?

00:09:23.480 --> 00:09:24.960
Y por qué patata.

00:09:24.960 --> 00:09:30.440
Han decidido, que es mi favorita, que el Corner Radius ahora ya no se puede usar y haya que

00:09:30.440 --> 00:09:35.800
usar el Clip Shape, entonces donde antes ponías una instrucción muy corta, ahora tienes que

00:09:35.800 --> 00:09:38.440
poner una instrucción bastante más larga.

00:09:38.440 --> 00:09:46.920
En fin, tonterías, pero al final una deprecación es algo que sigue funcionando, pero que Apple

00:09:46.920 --> 00:09:51.400
recomienda que te cambies porque en algún momento, en futuras versiones, pues ya no

00:09:51.400 --> 00:09:52.400
será usable.

00:09:52.400 --> 00:09:57.040
Te pone un warning en Scode, que a mí me da TOC.

00:09:57.040 --> 00:09:59.240
Sí, sí, no totalmente.

00:09:59.240 --> 00:10:04.000
Me da un obsesivo compulsivo brutal, yo no puedo tener ni un solo warning en mi código.

00:10:04.000 --> 00:10:05.000
Por eso...

00:10:05.000 --> 00:10:10.240
Claro, pero te pasan cosas como que cuando migraron al Split View o el Navigation Stack,

00:10:10.240 --> 00:10:14.840
yo tenía un montón de Navigation View que tienes que dejar, porque en Nios 15 no existe

00:10:14.840 --> 00:10:16.600
el Navigation Stack.

00:10:16.600 --> 00:10:27.560
De hecho, el Navigation View Content, si está, o sea, el Navigation View Content no está

00:10:27.560 --> 00:10:28.560
deprecado.

00:10:28.560 --> 00:10:40.320
Están deprecados la clase y está deprecado todos los inicializadores del Strut, salvo

00:10:40.320 --> 00:10:44.720
el Navigation View Content, porque efectivamente, si tienes Nios 15, tienes que hacerlo con

00:10:44.720 --> 00:10:45.720
Navigation View.

00:10:45.720 --> 00:10:49.360
No con este Navigation Stack.

00:10:49.360 --> 00:10:53.200
Pues eso, tendremos que convivir con esos warnings.

00:10:53.200 --> 00:10:57.680
Sí, pero bueno, a mí lo que me preocupa es eso, que estés usando una función que

00:10:57.680 --> 00:11:02.920
teóricamente, bueno, que vale, que está deprecada, genial, pero si compila es porque

00:11:02.920 --> 00:11:03.920
sigue estando.

00:11:03.920 --> 00:11:10.240
Por lo que, en fin, eso es un problema bastante, porque colgar una aplicación de Swift es

00:11:10.240 --> 00:11:12.160
bastante complicado, ¿vale?

00:11:12.160 --> 00:11:19.760
O sea, colgar una app de Swift ya tiene que ser algo muy gordo, pero, hombre, en fin.

00:11:19.760 --> 00:11:28.360
Y ya, esta te la pasé indignado, porque de repente digo, jope, como que veo que las fuentes

00:11:28.360 --> 00:11:33.800
que son negritas, luego nos dejan en el Storyboard, porque esta aplicación utiliza Storyboard,

00:11:33.800 --> 00:11:40.280
luego no son negritas, me las cambia, luego entro a una de esas vistas, vuelvo a asignar

00:11:40.280 --> 00:11:44.680
la fuente, vuelvo otra vez a la aplicación y pone la correcta, pero en otra vista hago

00:11:44.680 --> 00:11:51.840
lo mismo y no pone la correcta, y me da por buscar por internet a ver qué dice la gente

00:11:51.840 --> 00:11:58.960
y me llevan a una captura de los, de la Release Note, que siempre salen en las versiones de,

00:11:58.960 --> 00:12:05.680
tanto en las betas como en las versiones finales, y en el apartado de conocido por todos y temido

00:12:05.680 --> 00:12:12.320
por todos llamado Known Issues, para los que no sepáis inglés, eso, Problemas Conocidos,

00:12:12.320 --> 00:12:20.640
aparece que quizás no se resuelvan, como es, que quizás no aparezcan correctamente

00:12:20.640 --> 00:12:28.560
las fuentes definidas en el Storyboard. Y yo, no, me estás vacilando. Y sin ningún

00:12:28.560 --> 00:12:32.520
workaround ni ninguna manera, porque me dices, no, entras y vuelves a setearlas, o yo qué

00:12:32.520 --> 00:12:37.400
sé, cualquier cosa. No, no, que es así, entonces, cualquiera que tenga una aplicación

00:12:37.400 --> 00:12:47.760
con Storyboard no puede lanzarla compilada con Scouse 15. Lo que me lleva a pensar, Julio,

00:12:47.760 --> 00:12:57.920
es que yo creo que veremos un Scouse 10, o sea, 15.01, o incluso 15.1, lunes o martes

00:12:57.920 --> 00:13:05.680
antes de que salga Sonoma. Y Sonoma no salió justo a la vez que EOS, quizás por algo de

00:13:05.680 --> 00:13:10.920
esto, porque te obliga a utilizar Scouse 15 y Scouse 15 no estaba ya para utilizar. Porque

00:13:10.920 --> 00:13:15.440
otros años han esperado octubre porque había nuevos Mac, este año lo han adelantado porque

00:13:15.440 --> 00:13:24.440
no hay nuevos Mac, pero ese decalaje de una semana respecto a EOS, no lo sé, es mis cábalas,

00:13:24.440 --> 00:13:28.000
mi bola de cristal más pequeña que la tuya. De hecho, ya estoy viendo aquí la captura

00:13:28.000 --> 00:13:33.040
que me enviaste, y efectivamente pone Interface Builder Documents, a los documentos de Interface

00:13:33.040 --> 00:13:40.560
Builder que usen fuentes de app personalizadas, podrían cargar incorrectamente la fuente

00:13:40.560 --> 00:13:48.280
en ejecución. Workaround, pon la fuente manualmente en código. O sea, de verdad, voy a llenar,

00:13:48.280 --> 00:13:52.480
mira, he mentido, que he dicho que no había Workaround, pero es que qué Workaround es,

00:13:52.480 --> 00:13:59.680
me he metido en todas las vistas de la aplicación para hacerlo por código, en serio.

00:13:59.680 --> 00:14:05.280
Cuando lo tienes ya seteado perfectamente, eso te obliga a hacer outlets de cada componente,

00:14:05.280 --> 00:14:13.080
poner tal, o sea, es un show importante. Pero eso me da a entender, yo en los últimos años

00:14:13.080 --> 00:14:22.360
he visto que Apple ha dejado de prestar atención a UIKit, y por ejemplo, tú sabes perfectamente

00:14:22.360 --> 00:14:28.800
que es muy normal que en las últimas versiones el renderizado de los Storyboards haga cosas raras,

00:14:28.800 --> 00:14:34.720
te cambie cosas, de pronto pones una constraint correcta y te hace una cosa súper extraña. Es

00:14:34.720 --> 00:14:40.640
decir, cuando yo he tenido que formar a la gente en UIKit, porque todavía en el Bootcamp formamos

00:14:40.640 --> 00:14:47.680
en UIKit, porque el Bootcamp al final es todo el espectro de formación, y por lo tanto no

00:14:47.680 --> 00:14:54.120
podemos obviar la parte de UIKit. Pero cuando yo doy UIKit, me doy cuenta efectivamente que

00:14:54.120 --> 00:14:59.640
Apple es como que lo está abandonando poco a poco. Es mi impresión, no sé cómo lo ves tú.

00:14:59.640 --> 00:15:06.800
El error de este que se te queda el Storyboard con un error y no se reflejan bien, se queda así

00:15:06.800 --> 00:15:11.640
como raro. Puedes seguir usándolo, pero se queda como raro. O que de repente le das a la vista de

00:15:11.640 --> 00:15:17.600
asistente y te aparece una vista no JTC, digamos de la clase en sí, no de tu clase especializada,

00:15:17.600 --> 00:15:26.320
si de la interface que tiene definido y tal, cada dos por tres. Hace dos versiones así,

00:15:26.320 --> 00:15:31.920
hicieron la de, mira ahora cargan más grande, perdón, cargan más rápido en proyectos en

00:15:31.920 --> 00:15:38.360
Storyboard grandes. Pero yo creo que llevan ya por lo menos dos años haciéndole caso justo,

00:15:38.360 --> 00:15:43.160
pero a ver lo que digo yo, hazle caso justo. Pero tío, no me metas un error de estos en

00:15:43.160 --> 00:15:51.760
la versión final. Yo espero que mañana o pasado veamos cuando ya pongan, mira ya tenéis Sonoma,

00:15:51.760 --> 00:15:58.760
que tenéis lo que digo, obligatorio Scout 15, que es otra cosa que me extraña. Creo que otros años

00:15:58.760 --> 00:16:03.720
sí que cuando eran betas no funcionaban las versiones anteriores de Scout, pero en la versión

00:16:03.720 --> 00:16:09.560
final del sistema, en la Release Candidate, sí funcionan. Porque si por lo que sea tú necesitas

00:16:09.560 --> 00:16:17.920
una versión antigua de Scout, deberías poder. Pero creo que se puede porque puedes parchearlo,

00:16:17.920 --> 00:16:23.920
es decir, puedes entrar dentro de Scout, cambiarle no sé qué cosa en el InfoPolis o alguna puñeta de

00:16:23.920 --> 00:16:32.840
estas y conseguir que funcione. Creo que se puede hacer, pero efectivamente yo recuerdo que el año

00:16:32.840 --> 00:16:38.480
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

00:16:38.480 --> 00:16:45.400
puse hasta el final porque dejaba de funcionar Scout 13. Entonces yo no sé quién ha tomado esa

00:16:45.400 --> 00:16:54.000
decisión o el motivo de esa decisión, pero desde luego me parece una muy mala decisión. A ver,

00:16:55.160 --> 00:17:04.120
el motivo entiendo que es porque ahora las SDKs están por separado y entonces no puedes cargar

00:17:04.120 --> 00:17:11.600
la SDK de MacOS de la versión anterior de MacOS porque la SDK de MacOS la coge directamente del

00:17:11.600 --> 00:17:17.840
propio sistema operativo. Pero si no, pues ponme la SDK de la versión anterior, me da igual o por

00:17:17.840 --> 00:17:23.280
lo menos en iOS. Había un workaround en otros años, porque claro tenía que poner a investigar,

00:17:23.280 --> 00:17:30.040
y era que cogías porque cada versión de Scout, si entras dentro de los archivos,

00:17:30.040 --> 00:17:37.840
tiene los runtimes de cada versión de iOS que tengas. Y podías coger la versión,

00:17:37.840 --> 00:17:43.040
porque uno de mis problemas era también que tenía un dispositivo de pruebas que se me actualizó.

00:17:43.040 --> 00:17:47.000
Supongo que no me di cuenta porque eso de que se me actualizó solo es mentira,

00:17:47.000 --> 00:17:51.080
por lo que sea mejor me aparecieron ahí y le di. Lo actualicé a iOS 17. Entonces claro,

00:17:51.080 --> 00:17:57.320
un dispositivo en iOS 17 yo no puedo debuggear una aplicación con el Scout anterior,

00:17:57.320 --> 00:18:03.960
porque el Scout anterior no tiene el runtime de en este caso de iOS 17. Entonces yo miré y había

00:18:03.960 --> 00:18:08.160
como un truquillo otros años en que entrabas en las carpetas donde estaban todos los runtimes y

00:18:08.160 --> 00:18:13.760
cogías el del Scout nuevo y lo metías el 17. En este caso lo copiabas y lo metías en el antiguo.

00:18:13.760 --> 00:18:22.640
Pero este año estaban todos en la versión de Scout 15 todos los runtimes hasta la 16.4,

00:18:22.640 --> 00:18:30.160
que creo que fue la última vez que cambió, pero no estaba el de iOS 17. No sé por qué ahora han

00:18:30.160 --> 00:18:34.080
metido lo de los runs. Supongo que por esto que comentábamos, que vienen los SDKs por separado,

00:18:34.080 --> 00:18:40.360
o sea, digamos los runs. Bueno, sí, las dos cosas, los runtimes y los SDKs por separado.

00:18:40.360 --> 00:18:45.400
Y a lo mejor ya los meten en otro directorio, no tengo ni idea, pero ya no estaba ahí. Entonces

00:18:45.400 --> 00:18:52.800
uno de los Workaround que había, pues no lo pudo hacer. Pero bueno, Periplo. Todos los años creemos

00:18:52.800 --> 00:18:59.280
que estamos preparados junio, pero siempre con las nuevas versiones siempre hay algún drama para

00:18:59.280 --> 00:19:05.880
los desarrolladores. Siempre, siempre, siempre. Sí, pero bueno, aún así tocamos madera, ¿vale?

00:19:05.880 --> 00:19:15.640
Es decir, yo he usado otros IDEs, como por ejemplo, sin ir más lejos, Unity, que tú también lo has dado

00:19:15.640 --> 00:19:21.120
ahí una formación. No sé si luego has tenido tiempo de dedicarle a Unity, pero Unity, el cambio

00:19:21.120 --> 00:19:27.360
de un proyecto a una nueva versión, puede ser un drama muy triste. Me pasó que un día cuando estaba

00:19:27.360 --> 00:19:33.800
haciendo el curso, cogió y instalé el nuevo, no sé cuántos, y cogí y me volví a ver cómo instalar

00:19:33.800 --> 00:19:38.960
el antiguo, porque digo, para el curso este voy a perder más tiempo en pasarlo de una versión a

00:19:38.960 --> 00:19:44.800
otra que haciendo el curso. Efectivamente, entonces bueno, y luego aparte no podemos

00:19:44.800 --> 00:19:56.760
olvidar algo que pasa con Scope 15 versión final, y es que yo sigo teniendo Scope 15 beta aparte de

00:19:56.760 --> 00:20:04.840
la versión final. Y diréis, ¿por qué? Porque la versión final desaparecen Vision OS SDK y Reality

00:20:04.840 --> 00:20:11.640
Composer, porque no están en la versión final. Reality Composer Pro es una herramienta que

00:20:11.640 --> 00:20:19.080
pertenece a la SDK de Vision OS y todavía no está en versión final, por lo que tienes que tener

00:20:19.080 --> 00:20:27.240
o Scope 14. Es decir, si tú usas Reality Composer como herramienta, sólo tienes dos opciones y si

00:20:27.240 --> 00:20:35.120
estás en Sonoma, sólo tienes una. Si estás en Ventura, es tener Scope 14 y Scope 15. Para tener

00:20:35.120 --> 00:20:42.400
las dos versiones, lo único que tienes que hacer es renombrar el punto app, o tener la aplicación

00:20:42.400 --> 00:20:49.520
esta que se llama Scopes, que te permite gestionar, y una app que se llama Xcodes, que te permite

00:20:49.520 --> 00:20:56.960
gestionar y tener varias instalaciones de Scopes a la vez. Entonces esa aplicación te permite tener

00:20:56.960 --> 00:21:02.640
varias y poder elegir cuál quieres usar, cuál tal, no sé qué. Si no, pues simplemente renombráis el

00:21:02.640 --> 00:21:10.680
Scope 14 como Scope 14 punto app, instaláis la 15, que se llamará Scope punto app, y podéis tener

00:21:10.680 --> 00:21:18.040
las dos a la vez. Esa es la única manera de, en Ventura, tener Reality Composer. Pero como Scope

00:21:18.040 --> 00:21:25.080
15 cambió Reality Composer por Reality Composer Pro, que es la versión que viene con Vision OS,

00:21:25.080 --> 00:21:32.120
y Vision OS todavía está en beta, pues Reality Composer Pro y Vision OS SDK no están en la

00:21:32.120 --> 00:21:37.320
versión final de Scope 15. Por lo que si quieres seguir trabajando en Vision OS, como es mi caso,

00:21:37.320 --> 00:21:46.000
tienes que dejarte la beta 8, que es la última de Scope 15 instalada, junto a la Scope 15 final,

00:21:46.000 --> 00:21:53.160
que es la que tienes a todos los efectos. Yo entiendo que, porque esto lo estamos grabando

00:21:53.160 --> 00:22:05.200
el domingo 24, y Sonoma sale el martes 26, si no recuerdo mal. Entonces cuando salga Sonoma,

00:22:05.200 --> 00:22:09.960
como ha dicho Arturo, yo comprendo, entiendo, supongo, de hecho probablemente estéis oyendo

00:22:09.960 --> 00:22:16.000
este episodio y ya habrá salido, que habrá una versión de Scope que parchee cositas,

00:22:16.000 --> 00:22:26.400
¿vale? Pero lo más importante, que salga la beta de la 17.1, porque la beta de la 17.1 debería de

00:22:26.400 --> 00:22:34.240
traer la beta 4 de Vision OS SDK, y por supuesto la beta de Reality Composer Pro, que yo entiendo

00:22:34.240 --> 00:22:40.040
que es una aplicación que aún no está para ser lanzada, y por eso no se ha incluido en Scope 15,

00:22:40.040 --> 00:22:45.480
¿vale? Por lo que si necesitáis esa herramienta, si necesitáis Reality Composer, pues eso es lo

00:22:45.480 --> 00:22:52.520
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?

00:22:52.520 --> 00:23:01.160
Estas son las cositas que tiene Apple, ¿vale? Yo entiendo, supongo, que una vez salga Sonoma,

00:23:01.160 --> 00:23:07.440
pues no lo sé, habrá un, al menos un parche para estas cositas, ¿no?, de tal, y luego no

00:23:07.440 --> 00:23:13.280
podemos olvidar que está todavía ahí, y que está en el aire, saber si se arreglará o no,

00:23:13.280 --> 00:23:20.760
el tema de la concurrencia de procesos en Swift Data, ¿vale? Que esto es una cosa que yo puse

00:23:20.760 --> 00:23:25.840
como fallo en Apple, que nadie me ha contestado, que nadie me ha hecho caso. Yo cruzo los dedos a

00:23:25.840 --> 00:23:29.600
que alguien lo haya leído, aunque no me hayan contestado, me da igual que no me contesten,

00:23:29.600 --> 00:23:35.240
me da igual que no me den crédito de nada, me importa poco, pero es un lío que incluso,

00:23:35.240 --> 00:23:43.520
acuérdate, que hasta Sean Allen, el divulgador de desarrollo de Swift y tal, pues llegamos a

00:23:43.520 --> 00:23:48.560
cruzar tweets, ¿no?, preguntando cómo funcionaba y tal, porque él se dio cuenta de que pasaba lo

00:23:48.560 --> 00:23:53.520
mismo, de que Swift Data no funcionaba en concurrencia, que tú le decías que fuera

00:23:53.520 --> 00:23:58.680
concurrente, pero luego, a la hora de la verdad, siempre funcionaba sobre el hilo principal,

00:23:58.680 --> 00:24:04.040
y por lo tanto estaba bloqueando el hilo principal, porque aunque tú pusieras un task,

00:24:04.040 --> 00:24:08.760
luego al final todo el proceso iba contra el main actor, y por lo tanto te paraba el hilo

00:24:08.760 --> 00:24:14.320
principal. Hacía un main actor ahí en el medio, un main actor punto RAM. Sí, sí, sí. Para correr

00:24:14.320 --> 00:24:20.080
eso. Porque tú lanzabas, o sea, tú ahora mismo lanzas, cuando te montas, claro, el principal

00:24:20.080 --> 00:24:27.200
problema es que el container de Swift Data solo te ofrece un context, que es un main context que

00:24:27.200 --> 00:24:33.920
está unido al main actor y que solo se puede usar dentro de un closure o dentro de una función que

00:24:33.920 --> 00:24:40.040
es arroba main actor, ¿vale? Por lo tanto, lo que estás haciendo es elevar el permiso de eso. Como

00:24:40.040 --> 00:24:47.880
ya hablamos aquí, cuando tú, hasta la beta 6 creo que fue, cuando se actualizaba un contexto en

00:24:47.880 --> 00:24:52.840
segundo plano de Swift Data, la interfaz no se daba cuenta, no se actualizaba. Tenías que cerrar

00:24:52.840 --> 00:24:59.920
la app y volver a abrirla. En la beta 7 lo arreglaron, pero con la coña marinera de que lo

00:24:59.920 --> 00:25:04.480
que hicieron fue elevarlo todo al main actor, ¿vale? Entonces ahora lo hace todo en el hilo

00:25:04.480 --> 00:25:10.000
principal para que así Swift UI sea consciente de ese cambio. Pero claro, lo que han hecho así

00:25:10.000 --> 00:25:17.600
es tropear la concurrencia de Swift Data. Entonces ahora todo Swift Data, si tienes procesos normalitos

00:25:17.600 --> 00:25:22.240
que no consuman mucho, bueno, pues la interfaz no se va a dar mucha cuenta. Pero si tienes procesos

00:25:22.240 --> 00:25:27.240
concurrentes en batch, como tengo yo, de mil, mil y pico registros que se cargan al inicio de la app,

00:25:27.240 --> 00:25:35.600
pues es que te has metido en un lío importante. Entonces, en fin, es un poco de aquella manera,

00:25:35.600 --> 00:25:44.000
¿vale? Entonces, en fin, hay que tener... Bueno, pues esperemos que arreglen esto de alguna manera,

00:25:44.000 --> 00:25:52.760
porque si no, en fin, yo no sé cómo puede ser, ¿vale? Y luego, aparte, hay otra cosa con Swift

00:25:52.760 --> 00:26:03.080
Data que es, de nuevo, la vuelta del mismo problema. Y es que todo el mundo no quiere

00:26:03.080 --> 00:26:10.240
poner las queries en las views, ¿vale? Ya era un problema con CoreData, porque los FedRequest

00:26:10.240 --> 00:26:14.960
había que ponerlos en la view, porque si no, no capturaba el contexto que estaba inyectado como

00:26:14.960 --> 00:26:21.760
dependencia en toda la app. Y, por estructura, se sigue funcionando igual con el nuevo ArrobaQuery,

00:26:21.760 --> 00:26:29.560
por lo que el ArrobaQuery tenéis que seguir poniéndolo en la view. No os gusta, lo siento,

00:26:29.560 --> 00:26:34.760
pero no hay otra forma, ¿vale? Porque tiene que conectar con el contexto que está inyectado a

00:26:34.760 --> 00:26:42.360
nivel de dependencia. Y como lo hagáis vosotros dentro de un Observable, da igual. Cuando ese

00:26:42.360 --> 00:26:47.960
dato se actualice, la vista no se va a enterar y no tenéis los datos refrescados en tiempo real.

00:26:47.960 --> 00:26:55.760
Así que... Y esto es algo que, pues, no creo que lo arreglen en ningún momento, porque... Bueno,

00:26:55.760 --> 00:27:01.240
pues, ¿por qué no? A pesar de tener el ArrobaObservable, que está bastante bien, ¿vale?

00:27:01.240 --> 00:27:09.800
Pues sí, menudo galimatías de scodes, de versiones, y por si fuera poco, Julio,

00:27:09.800 --> 00:27:14.000
pedimos en su día un suite data, pero se nos olvidó decir que lo hicieran bien.

00:27:14.000 --> 00:27:17.800
No pusimos ese pequeño matiz.

00:27:17.800 --> 00:27:18.880
Se daba por supuesto, macho.

00:27:18.880 --> 00:27:20.440
Claro, no, no.

00:27:20.440 --> 00:27:22.800
Ese es el problema, que lo dábamos por supuesto.

00:27:22.800 --> 00:27:28.920
No hay que dar por supuesto. Así que, nada, esos son mis dramas. Si no hubiese sido drama

00:27:28.920 --> 00:27:35.600
esta mañana, Julio, encontrar un puñetero cable por casa que funcionase con CarPlay en el iPhone 15...

00:27:35.600 --> 00:27:41.280
Porque eso es. Cuéntanos, porque tienes nuevos dispositivos, ¿vale? Entonces,

00:27:41.280 --> 00:27:45.960
vamos a un poco de salseo, ¿vale? Porque al final es parte de lo que has hecho, ¿no? O sea,

00:27:45.960 --> 00:27:50.200
tienes... Has renovado flota, ¿no? Enséñanos qué has renovado.

00:27:50.200 --> 00:27:57.440
Sí, pues, nada, me he lanzado a los nuevos iPhone, ¿vale? Como tenía un 14 Pro, pues,

00:27:57.440 --> 00:28:02.560
he cogido directamente un 15 Pro, porque el 15 Pro Max me parece demasiado grande y yo

00:28:02.560 --> 00:28:08.480
tampoco soy muy amante de las fotos. Pero precisamente en el tema de las fotos es donde

00:28:08.480 --> 00:28:14.280
me está gustando mucho, porque a mí lo que me gusta, y iPhone creo que tiene mucho de eso,

00:28:14.280 --> 00:28:19.760
es lo saco del bolsillo, he hecho una foto y ya está. Y quiero que esa foto salga las

00:28:19.760 --> 00:28:23.880
mayores veces posibles bien, ¿vale? Que luego no la esté mirando y diga,

00:28:23.880 --> 00:28:27.760
joder, vaya mierda de foto que he hecho y me he perdido de hacer una foto buena en ese momento.

00:28:27.760 --> 00:28:35.440
Y me está gustando muchísimo. Por la noche estoy alucinando porque noto muchísimo menos grano,

00:28:35.440 --> 00:28:41.600
porque siempre notaba en la cámara del 14 Pro, sobre todo por la noche, pero también de día

00:28:41.600 --> 00:28:47.160
depende de lo que estuvieras haciendo fotos o depende de los colores que tuviera, veía...

00:28:47.160 --> 00:28:54.280
o sobre todo yo creo que al telefoto, el telefoto tenía bastante grano y ahora lo estoy notando

00:28:54.280 --> 00:29:00.480
bastante mejor. Y sobre todo otra cosa que me ha flipado es el modo retrato a posteriori,

00:29:00.480 --> 00:29:05.760
¿vale? Ahora tiene modo retrato, pero también puedes hacer una foto normal y te aparece,

00:29:05.760 --> 00:29:11.200
si él detecta que hay una persona o un animal o tal, te aparece como la F para activar el modo

00:29:11.200 --> 00:29:16.720
retrato. Pero si en el momento no lo activas, luego al editar la foto puedes escoger el

00:29:16.720 --> 00:29:21.120
retrato. Y un par de fotos en las que no había hecho retrato, le he dado el toque ese del

00:29:21.120 --> 00:29:27.760
difuminado y ha quedado muy bien. ¿Por qué? Porque yo creo que con el nuevo... las nuevas

00:29:27.760 --> 00:29:36.680
capacidades que tiene el chip A17 Pro han mejorado los algoritmos para hacer ese degradado... para

00:29:36.680 --> 00:29:40.480
hacer el degradado no, sino digamos para separar lo que degrada es de lo que no.

00:29:40.480 --> 00:29:47.840
La profundidad de lo que es lo que es la segmentación de la fotografía creando el

00:29:47.840 --> 00:29:56.000
mapa de profundidad. Y lo pilla muchísimo mejor. La verdad es que no me lo esperaba que en esa

00:29:56.000 --> 00:30:00.760
parte, porque luego sí que me esperaba pues eso más más ligero, el bisel este de los bordes bien,

00:30:00.760 --> 00:30:06.840
menos menos... o sea se nota que es un poco más pequeñito, que eso está está guay,

00:30:06.840 --> 00:30:12.200
pero sobre todo el bisel este que sea más ligero lo hace más manejable,

00:30:12.200 --> 00:30:15.880
que eso ya lo esperaba, pero la foto me ha sorprendido gratamente.

00:30:15.880 --> 00:30:23.400
Claro es que, a ver, hay que tener en cuenta que los iPhones nuevos con el A17 Pro tienen

00:30:23.400 --> 00:30:30.080
un nuevo motor neural que duplica, duplica la potencia de la anterior, ¿vale? La potencia

00:30:30.080 --> 00:30:38.000
de la A14 Pro era en el motor neural de 17 billones con B de operaciones por segundo,

00:30:38.000 --> 00:30:46.440
y el nuevo que tiene la A17 Pro sube a 35 billones con B de operaciones por segundo.

00:30:46.440 --> 00:30:53.280
Eso le ha permitido pues lógicamente tener un algoritmo de mayor precisión en lo que es la

00:30:53.280 --> 00:30:59.960
división, lo que es el cálculo del mapa de profundidad, la segmentación de la fotografía,

00:30:59.960 --> 00:31:05.120
a través de Machine Learning, pero fíjate que me resulta muy curioso lo que me cuentas,

00:31:05.120 --> 00:31:17.320
porque las cámaras gran angular y ultra gran angular de los 15 Pro y de los 15 Pro Max son

00:31:17.320 --> 00:31:26.040
exactamente la misma cámara que el 14 Pro. O sea, no ha habido cambio a nivel de hardware.

00:31:26.040 --> 00:31:33.440
Sin embargo, fíjate que el telefoto sí es nuevo. Pues el telefoto, yo creo que esas fotos son las

00:31:33.440 --> 00:31:40.000
que antes me salían con mucho grano y ha mejorado bastante. El telefoto sí es nuevo, el telefoto

00:31:40.000 --> 00:31:45.080
del tanto del Pro como del Pro Max, el del Pro Max es obvio que es nuevo porque tiene el tetraprisma,

00:31:45.080 --> 00:31:52.240
que es el que hace el tema del poder tener una profundidad de campo tan grande, pero el del

00:31:52.240 --> 00:32:01.560
15 Pro, perdón, ese telefoto 3X sí es nuevo. Por lo tanto, ahí aunque tiene la misma apertura que

00:32:01.560 --> 00:32:08.200
el anterior de f 2.8, pero es cierto que al ser mejor tener un sensor de más calidad, pues

00:32:08.200 --> 00:32:16.200
obviamente también repercutirá. Pero fíjate lo curioso que al final el ISP, el procesador de

00:32:16.200 --> 00:32:21.200
señales de imagen, que es el que se encarga de coger lo que saca la cámara y procesarlo para

00:32:21.200 --> 00:32:29.600
darte una foto que esté lo más bien posible, lo más bonita posible, ese cambio de ese chip hace

00:32:29.600 --> 00:32:37.400
que el mismo exacto hardware saque mejores fotos. Esto es una cosa que es bastante...

00:32:37.400 --> 00:32:41.960
Como en su día las mejores fotos hacían estas comparaciones, no sé si fue... Bueno,

00:32:41.960 --> 00:32:47.560
hay algunas que son muy chorras, pero creo que fue Marques Brownlee el que hizo una comparación y

00:32:47.560 --> 00:32:52.000
creo que salía el Pixel que de aquí hace, te estoy hablando de hace cuatro o cinco años,

00:32:52.000 --> 00:32:56.760
el Pixel que era el único que tenía sólo una cámara y era el que mejores fotos hacía. ¿Por qué?

00:32:56.760 --> 00:33:03.520
Porque hacía procesamiento posprocesado en la nube con un algoritmo muy potente que conseguía

00:33:03.520 --> 00:33:09.840
que esa foto, con el peor hardware o un hardware peor que otros que tenían dos cámaras, saliese

00:33:09.840 --> 00:33:15.520
mejor el resultado. Esto es igual, con el mismo hardware consigues mejores resultados.

00:33:15.520 --> 00:33:26.160
Pues es curioso. Yo tuve la ocasión de probarlo, de probar el 15 Pro, básicamente verlo. Y también

00:33:26.160 --> 00:33:31.520
el tema del agarre, el hecho de que las esquinas no sean totalmente rectas y tal, pues la verdad

00:33:31.520 --> 00:33:41.920
que le da un punto interesante. Y luego aparte también has hecho el otro cambio más. A ver,

00:33:41.920 --> 00:33:51.400
a ver, levanta, levanta. Tenemos ahí un Apple Watch Ultra 2. Cuéntanos cuáles son tus impresiones,

00:33:51.400 --> 00:34:01.640
porque vienes de un Series 8. Series 8, o sea que has hecho un cambio del modelo normal.

00:34:01.640 --> 00:34:07.480
Del modelo anterior, bueno sí, del Ultra. Pero del Series 8 de Wi-Fi, o sea que vienes

00:34:07.480 --> 00:34:13.920
del de aluminio al titanio. Efectivamente, y la verdad que tenía un poco de miedo. O sea,

00:34:13.920 --> 00:34:18.800
yo cuando salió el Ultra dije, el Ultra a lo mejor no es para mí. Pero luego de hecho me picó,

00:34:18.800 --> 00:34:24.480
cuando hicimos el directo de la presentación, me picó María porque hablaba como muy segura y muy

00:34:24.480 --> 00:34:29.720
convencida de qué buena decisión. Y dije mira, pues voy aprovechando que esto que tiene Apple,

00:34:29.720 --> 00:34:34.000
que lo puedes probar, no sé si son 15 días o un mes, digo mira pues voy a actualizar al Ultra y si

00:34:34.000 --> 00:34:41.120
no me gusta, oye, pues me vuelvo a un Series normal. Y la verdad es que estoy encantado,

00:34:41.120 --> 00:34:48.160
porque la pantalla se nota, se nota que es más grande. El brillo, no había echado de menos mucho

00:34:48.160 --> 00:34:55.800
brillo. Sí que se ve muy bien, pero ahí te diría que normal. No es incómodo porque yo duermo con

00:34:55.800 --> 00:35:00.680
él, entonces tenía miedo de que me molestase. Para nada, la verdad es que es cómodo. Yo tengo

00:35:00.680 --> 00:35:06.640
una muñeca pequeñita, he cogido el modelo de correa, hay creo que tres tamaños, pues el más

00:35:06.640 --> 00:35:12.280
pequeño y lo que sí que he notado... Yo me flipa el más grande, o sea que...

00:35:14.040 --> 00:35:20.760
Pues me flipa lo de la batería. O sea, yo lo utilizo mucho, pero muchas veces, por ejemplo,

00:35:20.760 --> 00:35:27.000
cuando salía fuera de casa, si salgo solo voy escuchando podcast siempre, entonces claro,

00:35:27.000 --> 00:35:32.600
si voy tirando del reloj, normalmente lo suelo intentar tener descargados, pero como utilizo

00:35:32.600 --> 00:35:38.280
la aplicación de podcast de Apple y no hay manera de decirle quiero tener descargados esto, sino le

00:35:38.280 --> 00:35:42.360
pones los últimos y él te va descargando, entonces hay veces que quiero escuchar un podcast que no

00:35:42.360 --> 00:35:50.800
tengo descargado. Entonces claro, tira mucho de batería eso y muchas veces llevaba el móvil

00:35:50.800 --> 00:35:58.080
simplemente por el tema de escuchar podcast y ahora el dejármelo en casa, estar escuchando podcast,

00:35:58.080 --> 00:36:04.600
dándole una tiza, durmiendo con él y demás. Y es que creo que lo he cargado una vez en todo esto

00:36:04.600 --> 00:36:11.320
y porque estaba el 50%. O sea, lo de la batería es brutal. Lo que me hace todavía más Julio,

00:36:11.320 --> 00:36:16.760
que ya lo dijimos en su día, desear que haga un puñetero iPhone así. O sea, un iPhone que le

00:36:16.760 --> 00:36:22.880
pueda meter toda la tiza que quiera y que llegue tranquilamente. O sea, el día lo pasan bien,

00:36:22.880 --> 00:36:28.920
salvo casos excepcionales, como por ejemplo unas llamadas de FaceTime, que ahora yo hago mucho

00:36:28.920 --> 00:36:37.400
FaceTime con las abuelas de mi hija y eso el FaceTime funde la batería de los puñeteros iPhone.

00:36:37.400 --> 00:36:42.400
Entonces me hace desear más un iPhone. Las llamadas de FaceTime ahora usan mucho

00:36:42.400 --> 00:36:47.720
Machine Learning y todo ese tipo de cosas para el tema de la voz, efectos de profundidad,

00:36:47.720 --> 00:36:51.440
no sé qué, la transcripción que la puedes activar también, cosas así.

00:36:51.440 --> 00:37:01.920
Pues sí, entonces es lo mejor que le he encontrado. El salto de batería. Sobre todo,

00:37:01.920 --> 00:37:05.560
a ver, claro, en un iPhone a lo mejor no es tan importante porque cuando estás durmiendo el iPhone

00:37:05.560 --> 00:37:09.680
lo tienes conectado, cargando. Pero claro, el Apple Watch, si lo utilizas para dormir,

00:37:09.680 --> 00:37:13.880
no te lo quitas en todo el día. Entonces, bueno, de hecho lo que he hecho es poner el cargador

00:37:13.880 --> 00:37:20.560
rápido en el baño para cuando me ducho. Porque sí que hay diferencia. Ya en el Series 8 lo notaba.

00:37:20.560 --> 00:37:26.600
Tengo un cargador rápido y de cargarlo con el rápido a cargarlo con uno normal se notaba un

00:37:26.600 --> 00:37:31.000
montón. De hecho, eso, yo que no me lo quiero quitar, me lo quiero quitar el menor tiempo

00:37:31.000 --> 00:37:36.040
posible, pues muchas veces tenía que quitarme lo demás por eso, porque si no, no llegaba,

00:37:36.040 --> 00:37:40.560
no llegaba al final. Bueno, al final del día no, pero sí que hay días que como no estuvieras

00:37:40.560 --> 00:37:52.560
atento te podía no durar el día. Pero no has sentido la sensación, la premura en tu físico

00:37:52.560 --> 00:38:02.800
de ir a bucear o de hacer alpinismo o de cruzar sin mirar si está en rojo o no el semáforo. Es

00:38:02.800 --> 00:38:11.040
decir, no has tenido esos impulsos. No, de momento no. He ido ayer a Faunia. No sé si cuenta como

00:38:11.040 --> 00:38:23.880
actividad de riesgo. Ostras, había un emú que venía con... Tenía mala pinta. Madre mía, mi vida.

00:38:23.880 --> 00:38:32.840
En fin, pues nada. Yo, como ya sabes, estoy esperando mi Ultra 2. Yo salto desde el Series 4,

00:38:32.840 --> 00:38:40.960
por lo tanto ya es un salto importante. Y bueno, pues a ver si llega en algún momento y puedo

00:38:40.960 --> 00:38:45.800
empezar a disfrutarlo. Por cierto, antes de que nos cuentes lo que has estado haciendo,

00:38:45.800 --> 00:38:52.520
una de las cosas que has estado haciendo el viernes es salir a la calle a probar la demo

00:38:52.520 --> 00:39:00.040
que traen el iPhone 14 Pro para las llamadas por satélite que se han activado en España.

00:39:02.040 --> 00:39:08.640
Pues no. Pues yo el único salí, salía a mirarlo en la calle en cuanto vi la noticia de que se

00:39:08.640 --> 00:39:14.080
había activado y dije, seguro que no soy el único tonto que está aquí mirando así para los lados.

00:39:14.080 --> 00:39:18.400
El que te dice, oriéntalo para acá, oriéntalo para allá a los satélites. Seguro que no soy

00:39:18.400 --> 00:39:24.840
el único tonto que está haciendo esto. No, no, de hecho ni le he prestado atención. Pero bueno,

00:39:24.840 --> 00:39:31.840
por si no lo sabéis, pues efectivamente se ha activado en España la cobertura de llamadas

00:39:31.840 --> 00:39:37.040
de emergencia a través de satélite. De forma que si por lo que sea, esperemos que no,

00:39:37.040 --> 00:39:43.600
tenéis algún tipo de accidente, aunque sea en una zona sin cobertura, el teléfono va a ser capaz de

00:39:43.600 --> 00:39:48.960
hacer la llamada de emergencia a través de conexión satelital. Si no recuerdo mal,

00:39:48.960 --> 00:39:58.280
es un año gratis y luego hay que pagar, me parece. Me pillas. Creo que sí, creo que sí,

00:39:58.280 --> 00:40:05.560
que es un año gratis y luego si lo quieres seguir manteniendo tienes que pagar por ese servicio. No

00:40:05.560 --> 00:40:12.880
sé, por el hecho de que al final es un servicio que a Apple no le sale gratis. Entonces pues eso

00:40:12.880 --> 00:40:21.040
te lo ofrecen el primer año y luego ya te lo cobran. Pero vamos, no sé, no lo he probado la verdad.

00:40:22.480 --> 00:40:28.520
Pues nada, muy interesante. Cuéntanos, Julio, qué has estado haciendo, que ya sabemos que no

00:40:28.520 --> 00:40:32.400
ha sido probar las llamadas satelitales. No, pues lo que he estado haciendo ha sido,

00:40:32.400 --> 00:40:39.120
pues aparte de estar a pocos metros de Tim Cook sin saberlo, pues también he estado,

00:40:39.120 --> 00:40:48.760
pues obviamente como ya sabes, dando clase. Estas semanas han sido de nuevo de dar clase y lo que

00:40:48.760 --> 00:40:53.760
estamos viendo ahora es un poco lo que hablamos en el episodio anterior, el tema de las arquitecturas,

00:40:53.760 --> 00:41:03.160
en este caso de SwiftUI. Este año he incorporado una nueva versión de la arquitectura que uso

00:41:03.160 --> 00:41:10.640
nativa, basada en Clean Architecture, en el que creo un interactor que es el que se encarga de

00:41:10.640 --> 00:41:20.080
inyectar lo que es el almacenamiento, digamos la persistencia de datos, ya sea en local o en red.

00:41:20.080 --> 00:41:27.960
Pues esa persistencia de datos se inyecta a las aplicaciones directamente a través de un protocolo.

00:41:27.960 --> 00:41:32.880
Es algo que ya probé en su momento, pero que ahora este verano lo he perfeccionado y

00:41:32.880 --> 00:41:38.640
lo he dejado de una manera, pues que al final está utilizando programación orientada protocolos,

00:41:38.640 --> 00:41:48.320
para poder elegir para que el mismo exacto procedimiento que carga y envía, si es tanto

00:41:48.320 --> 00:41:55.240
local como red, pues sea el mismo a nivel de código, pero las fuentes o el lugar de donde

00:41:55.240 --> 00:42:03.760
procede esa información, pues pueda variar en cada instancia, pasando de tener la persistencia

00:42:03.760 --> 00:42:09.200
en una clase a tenerla en un strut, para que sea totalmente orientado a protocolos. Entonces lo

00:42:09.200 --> 00:42:14.800
que hacemos es inyectar por dependencia ese strut, bien de producción, bien de desarrollo,

00:42:14.800 --> 00:42:21.480
de preview, de SwiftUI, directamente al ViewModel y directamente pues aquello funciona estupendamente

00:42:21.480 --> 00:42:28.160
bien. De hecho hice una masterclass la semana pasada en directo aquí en Twitch, explicándolo,

00:42:28.160 --> 00:42:33.360
que todavía estará colgada en Twitch, por si queréis verla. De hecho, si Jobs quiere y me

00:42:33.360 --> 00:42:39.480
da tiempo, podré colgarla también en YouTube. Y bueno, pues ahí está ese cambio. Y luego el

00:42:42.280 --> 00:42:49.360
miércoles, que ha sido una semana muy Apple, el miércoles estuve de nuevo en las oficinas de

00:42:49.360 --> 00:42:56.160
Apple. Estuve en las oficinas de Apple en la Puerta del Sol, no en la tienda, sino en la

00:42:56.160 --> 00:43:05.120
parte de arriba, pues de nuevo dando una charla. Apple, junto a la gente de iDutech, pues bueno,

00:43:05.120 --> 00:43:12.360
en realidad lo organiza iDutech y Apple pues colabora con ellos para ceder el lugar para

00:43:12.360 --> 00:43:20.160
dar estas charlas. Entonces fui como ponente de unas charlas que ya di en junio sobre inteligencia

00:43:20.160 --> 00:43:26.120
artificial generativa y básicamente pues bueno, pues una masterclass de una hora más o menos,

00:43:26.120 --> 00:43:31.040
donde explico la situación actual de la IA generativa, las herramientas que hay,

00:43:31.040 --> 00:43:38.880
de dónde venimos, hacia dónde vamos y luego pues una serie de conceptos fundamentales,

00:43:38.880 --> 00:43:43.920
que es inteligencia artificial, que es Machine Learning, que es Deep Learning, distintos tipos

00:43:43.920 --> 00:43:49.520
de inteligencias, distintos tipos de modalidades de dichas inteligencias y luego pues explicar

00:43:49.520 --> 00:43:56.400
las redes neuronales y los tipos más básicos o en general una definición rápida de los distintos

00:43:56.400 --> 00:44:03.640
tipos de redes neuronales que tenemos. Desde las redes neuronales más básicas, pasando por los

00:44:03.640 --> 00:44:12.360
transformers, los modelos de difusión, las redes, en fin, todo tipo de las redes NERF y tal. Bueno,

00:44:12.360 --> 00:44:17.480
pues explicando un poco cómo funciona todo eso pues para que la gente pueda entender a nivel

00:44:17.480 --> 00:44:24.040
de funcionamiento pues cómo va toda esta cosa. Entonces bueno, pues es algo que es interesante

00:44:24.040 --> 00:44:33.080
y que bueno, pues de hecho... Ojo Julio, que no es fácil meter esto en una hora. Bueno, pues una

00:44:33.080 --> 00:44:38.680
hora hay algo, además meto medio vídeos, pues voy sacando, yo que sé, cuando hablo de NERF,

00:44:38.680 --> 00:44:46.200
que es el tema de los campos neurales de radiación, que es para poder sacar a partir de 2D,

00:44:46.200 --> 00:44:54.120
generar 3D, detectando lo que serían precisamente lo de las fotos que hemos hablado, lo del algoritmo

00:44:54.120 --> 00:45:01.120
de poder hacer la foto de modo retrato y poder cambiar y tal, eso es NERF. NERF es a través de

00:45:01.120 --> 00:45:09.880
redes neuronales comprender una fotografía 2D y crearle un mapa de profundidad que te

00:45:09.880 --> 00:45:17.200
permita discernir los distintos campos que hay dentro de esa bidimensionalidad. Y entonces,

00:45:17.200 --> 00:45:23.480
bueno, pues les enseño, por ejemplo, cómo funciona el Object Capture de Apple, que ahora ya funciona

00:45:23.480 --> 00:45:31.160
en iOS, y de hecho hay varias demos de cómo hay apps de iOS 17 que son capaces de... Tú te paseas

00:45:31.160 --> 00:45:37.000
con un vídeo alrededor de algún tipo de elemento 3D, lo capturas y te lo genera en tiempo real con

00:45:37.000 --> 00:45:42.880
texturas y con todo, y de hecho a veces es incluso indistinguible de él real, dentro de lo que es

00:45:42.880 --> 00:45:48.080
esa realidad aumentada, y bueno, pues todo lo que es el funcionamiento de transformes, etcétera,

00:45:48.080 --> 00:45:58.040
y varias demos de IA generativa, de cómo funciona el nuevo Microsoft 365 Copilot, etcétera, etcétera,

00:45:58.040 --> 00:46:05.000
que de hecho ahora también ya les comenté que saldría la versión de Inteligencia Artificial

00:46:05.000 --> 00:46:11.520
de Windows, que ya ha sido anunciada, que fue anunciada el otro día, Windows Copilot, y bueno,

00:46:11.520 --> 00:46:17.960
pues Windows Copilot la verdad que es un adelanto de lo que vamos a ver en breve en todos los

00:46:17.960 --> 00:46:24.400
sistemas operativos, ¿vale? Es decir, Apple ya está trabajando en su propio sistema llamado Ajax,

00:46:24.400 --> 00:46:32.360
a nivel de nombre preliminar de producto, y será la IA que se integre en todos los sistemas.

00:46:32.360 --> 00:46:38.600
Me recuerda, Julio, el nombre, no sé quién lo habrá elegido, pero a mí me recuerda a un

00:46:38.600 --> 00:46:41.400
framework que utilicé yo bastante en mis inicios de Javascript.

00:46:41.400 --> 00:46:47.760
Claro, sí, sí, ¿no? Es el típico framework de Javascript, es la forma de programación reactiva

00:46:47.760 --> 00:46:53.160
de Javascript, ¿vale? Tu poder, a través de Ajax, tú podías enviar y recibir peticiones,

00:46:53.160 --> 00:46:58.560
o sea, podías enviar peticiones post que devolvían una respuesta y no tenías que

00:46:58.560 --> 00:47:04.240
refrescar la página, ¿vale? Entonces, pues sí, lo han llamado así. Entonces, pero bueno,

00:47:04.240 --> 00:47:10.880
el caso es que, pues la verdad que es interesante y esto es un cambio de paradigma que va a cambiar

00:47:10.880 --> 00:47:17.280
por completo la forma en la que usamos cualquier tipo de sistema, ¿vale? O sea, el año que viene

00:47:17.280 --> 00:47:23.200
vamos a poder invocar no solo apps, ¿vale? Porque hoy día yo le puedo decir, no sé quién,

00:47:23.200 --> 00:47:29.240
ábreme tal aplicación, ¿vale? Y te lo hace, ¿vale? No tienes por qué, pero al final no lo haces, ¿no?

00:47:29.240 --> 00:47:38.280
Pero a partir de la integración de estas herramientas con los nuevos sistemas como

00:47:38.280 --> 00:47:43.360
Windows Copilot o el futuro Ajax de Apple, pues lo que tendremos es un control total,

00:47:43.360 --> 00:47:49.600
es decir, yo podré decirle al sistema abre OBS, ponme, confígurame la escena, ponme tal,

00:47:49.600 --> 00:47:55.240
arráncame la cámara virtual, ponme no sé cuántas e incluso, y aquí es donde está la gran diferencia,

00:47:56.280 --> 00:48:03.120
el trabajo con nuestros ficheros en local, nuestros ficheros en disco duro, ¿vale? El que tú le

00:48:03.120 --> 00:48:11.120
puedas decir, yo de hecho ya tengo una IA que estoy probando, que se engancha con GPT-4,

00:48:11.120 --> 00:48:17.280
pero tiene la capacidad de ejecutar procesos en tu máquina, ¿vale? Entonces yo a ese sistema le dije,

00:48:17.280 --> 00:48:26.240
conviérteme este fichero que está en tal carpeta, ¿vale? A MP3. Y entonces fue a por el fichero,

00:48:26.240 --> 00:48:32.600
bajó las librerías que necesitaba para ello, lanzó el script para hacer la conversión y lo

00:48:32.600 --> 00:48:37.960
convirtió y yo no tuve que hacer absolutamente nada. ¿Sabes, Julio, que es que además Apple

00:48:37.960 --> 00:48:47.320
lo tiene ya en su sistema? Y justo te conté una cosa que hice esta mañana. Tiene atajos. La

00:48:47.320 --> 00:48:53.160
aplicación de atajos tiene un montón de acciones del sistema que tiene una API para que los

00:48:53.160 --> 00:48:58.040
desarrolladores den de alta esas acciones, que es una de las cosas que decía que por eso ha tardado

00:48:58.040 --> 00:49:04.920
Microsoft tanto en integrar la parte de Copilot, porque tenía que, digamos, mapear todas las

00:49:04.920 --> 00:49:12.480
acciones que se pueden hacer en una, o sea, para que esta inteligencia artificial pudiera,

00:49:12.480 --> 00:49:17.880
o sea, este algoritmo de machine learning pudiera escogerlas, digamos. Pues es que eso Apple ya lo

00:49:17.880 --> 00:49:21.920
tiene con los shortcuts y esta mañana estaba creando uno precisamente para el botón de acción

00:49:21.920 --> 00:49:29.320
del iPhone 15 Pro directamente porque lo que yo quería era que me cambiase los modos de concentración,

00:49:29.320 --> 00:49:37.760
pero quería algo un poco más profesional, que era que si se hacía entre las siete de la, no,

00:49:37.760 --> 00:49:42.280
entre las diez de la noche y las siete de la mañana, me pusiera el modo descanso, pero si lo

00:49:42.280 --> 00:49:50.200
hacía en otro, fuera de ese rango, que fuera el modo no molestar, ¿vale? Y, joder, es un poco arduo

00:49:50.200 --> 00:49:54.680
el tienes que sacar una variable con la, o sea, obtenerla ahora, sacar una variable con la hora,

00:49:54.680 --> 00:50:01.120
es un poco engorroso la parte de hacer de atajos. Si consigues que esos atajos, ya solo esto,

00:50:01.120 --> 00:50:08.520
que esos atajos te los haga con lenguaje natural el propio sistema, es que para mí, vamos, es un

00:50:08.520 --> 00:50:13.760
avance enorme porque es que luego encima, ¿qué me pasó? Ah, vale, me pasó que quería, muy bien,

00:50:13.760 --> 00:50:18.840
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

00:50:18.840 --> 00:50:25.200
quite el modo si está puesto, ¿vale? Pues también otro if ahí y es un poco engorroso y entiendo,

00:50:25.200 --> 00:50:30.240
a ver, y yo tengo un poco de lógica de programación, de trabajo con datos, lo que es un if,

00:50:30.240 --> 00:50:37.040
pero alguien que no tenga ni puñetera idea de esa lógica, entiendo que hacer un atajo en la

00:50:37.040 --> 00:50:45.240
aplicación de atajos es una tarea complicada y si tenemos algo que se lo decimos y lo hace, además,

00:50:45.240 --> 00:50:50.520
también sería un campo de pruebas muy bueno porque, mira, yo te lo meto en la aplicación,

00:50:50.520 --> 00:50:57.120
te pongo esta guía generativa para hacer atajos, punto, ya está, no sale de aquí y te funciona

00:50:57.120 --> 00:51:02.280
mejor o peor, pero no sale de aquí, entonces no se arriesga tanto Apple. Yo creo que lo debería

00:51:02.280 --> 00:51:08.840
empezar a meter por ese punto, no sé cómo lo ves. Sí, es que ese va a ser, yo creo que está

00:51:08.840 --> 00:51:15.440
clarísimo que ese va a ser el punto, el de cómo ya tiene automatizado, ya tenía gran parte del

00:51:15.440 --> 00:51:21.840
sistema automatizado a través de Apple Script y a través de la famosa antigua aplicación de

00:51:21.840 --> 00:51:29.800
Automator, ¿vale? Y ahora con lo que serían los atajos lo tiene igual, ¿vale? Entonces las

00:51:29.800 --> 00:51:36.160
automatizaciones están ahí, ¿vale? Es decir, la inteligencia artificial generativa que va a usar

00:51:36.160 --> 00:51:41.840
Apple es la misma inteligencia artificial generativa que va a usar Microsoft en el sentido

00:51:41.840 --> 00:51:48.840
de inteligencias de texto e inteligencias de generación de imágenes, ¿vale? Y luego puede

00:51:48.840 --> 00:51:54.760
ser que haya alguna más metida. La diferencia es que gran parte de lo que va a hacer Microsoft

00:51:54.760 --> 00:52:01.840
Copilot, Windows Copilot, perdón, lo va a hacer en la nube, por lo que tus datos van a ir a la

00:52:01.840 --> 00:52:08.000
nube o tus datos ya van a estar en la nube porque los archivos con los que va a trabajar van a estar

00:52:08.000 --> 00:52:14.720
en OneDrive, ¿ok? Pero Apple lo que está haciendo es trabajar para poder cargar esos modelos en

00:52:14.720 --> 00:52:22.280
local. Sabemos que Apple la nube no la curra mucho, no la maneja mucho. No trabaja ese artículo. No

00:52:22.280 --> 00:52:30.320
trabaja ese artículo y entonces pues eso lo que hace es que al final Apple lo que quiere es poder

00:52:30.320 --> 00:52:36.560
cargar el local que de hecho ya está trabajando con Stable Diffusion, que se puede cargar el

00:52:36.560 --> 00:52:44.320
local como un modelo de CoreML, se puede cargar Yama 2, el modelo de Facebook también en CoreML

00:52:44.320 --> 00:52:51.400
y utilizarlo como modelo generativo de texto. Entonces basado en eso va a hacer un poco como

00:52:51.400 --> 00:52:58.440
lo que hace GPT-4, ¿vale? GPT-4 al final lo que tiene son pues la guía generativa de texto. De hecho

00:52:58.440 --> 00:53:03.800
ahora se acaba de anunciar Dalí 3 que va a estar integrado en GPT-4. Una de las cosas más

00:53:03.800 --> 00:53:09.240
problemáticas a la hora de manejar una guía generativa de imágenes es saber darle el prompt

00:53:09.240 --> 00:53:15.880
exacto para que te genere lo que tú quieres y hay que ser todo un artista, todo un prompt engineer

00:53:15.880 --> 00:53:25.560
para llegar a eso. Pues bien, lo que ha hecho OpenAI es integrar Dalí 3 dentro de GPT-4 de

00:53:25.560 --> 00:53:31.680
forma que cuando tú a GPT-4 le pides de manera textualizada, de manera conversacional, la

00:53:31.680 --> 00:53:38.160
imagen que quieres, él traduce por detrás lo que tú le has dicho a un prompt que sea capaz de

00:53:38.160 --> 00:53:44.280
sacar lo que le has pedido, ¿vale? Es decir, te hace una traducción. Lo típico que hay mucha gente,

00:53:44.280 --> 00:53:52.920
que de hecho existe, ¿vale? Hay un montón de páginas donde tú puedes copiar todas unas

00:53:52.920 --> 00:53:59.200
instrucciones como contexto dentro de tu conversación de GPT y a partir de ahí le puedes pedir prompts

00:53:59.200 --> 00:54:04.760
de mid-journey, por ejemplo, a GPT y te los da estupendos, ¿vale? Entonces, pues eso ya lo va

00:54:04.760 --> 00:54:11.080
a hacer de manera automática GPT-4. Entonces, insisto, esto es lo que hará Apple. Lo que tienes

00:54:11.080 --> 00:54:18.040
que hacer es que GPT-4, como ya hace GPT-4, esté conectado a un sistema de análisis avanzado que

00:54:18.040 --> 00:54:25.760
sea capaz de ejecutar scripts de Python para trabajar y procesar tus datos, ¿vale?, a nivel

00:54:25.760 --> 00:54:30.920
de análisis y también la inclusión de plugins, plugins que permitan, pues por ejemplo, como yo

00:54:30.920 --> 00:54:36.760
hago con GPT, de darle una URL y que vaya a leer esa URL y luego me hable de ella y me diga, pues

00:54:36.760 --> 00:54:42.240
oye, este es el resumen, esto no sé qué, esto no sé cuál, ¿vale? Entonces, eso lo hará Apple también

00:54:42.240 --> 00:54:50.800
de poder utilizar cualquier tipo de contexto y, sobre todo y principalmente, los plugins que

00:54:50.800 --> 00:54:57.800
permiten ejecutar, que ese es el key de la cuestión, que permiten entender y ejecutar ciertas acciones,

00:54:57.800 --> 00:55:03.200
por lo que simplemente a la hora de pedirlo, pues lo cogería. Y esto, antes de que alguien diga,

00:55:03.200 --> 00:55:09.320
pues como lo hago con Siri, porque no sé qué decir y... No, no, o sea, a ver, ¿por qué Microsoft...

00:55:09.320 --> 00:55:16.120
Claro, ¿por qué Microsoft mató Cortana antes de crear Windows Copilot? Para que la gente no pensara

00:55:16.120 --> 00:55:23.560
que eso era Cortana. Windows Copilot es otra cosa distinta a Cortana, ¿vale? Pues bien, si yo fuera

00:55:23.560 --> 00:55:32.840
Apple, os lo digo en serio, si yo fuera Apple, dado el desgaste que tiene la marca Siri, unida a algo

00:55:32.840 --> 00:55:38.360
que funciona menos, que falla más que una escopetilla feria, yo me plantearía seriamente,

00:55:38.360 --> 00:55:45.480
y os lo digo de corazón, matar a Siri. Pero no matarla como tal, sino matarla como marca,

00:55:45.480 --> 00:55:54.360
matarla como elemento. Es decir, no llamar Siri a lo que sustituya a Siri. Porque eso es lo que

00:55:54.360 --> 00:55:58.360
Apple viene haciendo en los últimos años. Siri ha tenido cuatro reescrituras.

00:55:58.360 --> 00:56:03.840
Hay un SiriKit... Es complicado.

00:56:03.840 --> 00:56:09.520
Pues que lo cambien de nombre. Me da igual, pero que no lo llamen Siri, aunque luego por dentro

00:56:09.520 --> 00:56:14.760
siga siendo Siri, aunque siga siendo la librería SiriKit, aunque sigan siendo los atajos de Siri,

00:56:14.760 --> 00:56:23.240
pero que no se llame Siri, se llame Paca, ¿vale? Y ya está. Entonces, oye, Paca. Bueno,

00:56:23.240 --> 00:56:27.720
ahora ya no hay que decir oye. Bueno, no hay que decir oye, no. Yo no he sido capaz de invocarla

00:56:27.720 --> 00:56:34.000
sin el oye, ¿vale? Creo que lo del hey lo han quitado solo en inglés, pero en español sigue

00:56:34.000 --> 00:56:39.640
siendo oye. No lo he probado. No, no, porque el otro día se me pasó por la cabeza probarlo y no,

00:56:39.640 --> 00:56:44.600
sigue siendo igual, sigue siendo oye. No escucha otra cosa, ¿vale?

00:56:46.280 --> 00:56:54.520
Pues sí, a ver, la verdad es que esto es el futuro. En este Microsoft lleva, digamos,

00:56:54.520 --> 00:56:59.200
un poco la delantera. Lo único que me surge, no sé si va a ser de pago o va a ser con la licencia

00:56:59.200 --> 00:57:03.280
de Windows, porque, ojo, cuidado. Windows Copilot. Esto que se ejecute en la nube.

00:57:03.280 --> 00:57:13.840
Windows Copilot, Windows, ¿vale? Va a ser gratis. Pero va a ser gratis lo que es ponme el modo

00:57:13.840 --> 00:57:21.600
oscuro, arráncame no sé qué aplicación, hazme no sé qué cosa. Ahora, cuando ya trabajes con la

00:57:21.600 --> 00:57:27.080
parte de documentos, ahí ya, ojito, porque la parte de documentos...

00:57:27.080 --> 00:57:32.840
Es que tiene que ir a la nube, entrenarlo con tus documentos en la nube y eso, eso cuesta,

00:57:32.840 --> 00:57:37.080
cuesta dinero. Claro, es que Microsoft 365

00:57:37.080 --> 00:57:45.840
Copilot es algo distinto a Windows Copilot, ¿vale? Entonces Microsoft 365 Copilot es muy

00:57:45.840 --> 00:57:51.200
caro. Es el doble o el triple, no, no recuerdo exactamente, pero es más del doble de lo que

00:57:51.200 --> 00:57:58.120
vale Office a día de hoy. Y lo tienes que, bueno, ya sabéis que ya no se llama Office,

00:57:58.120 --> 00:58:04.720
pero bueno, pero tienes que pagarlo aparte. Entonces, yo tengo la duda, porque eso es algo

00:58:04.720 --> 00:58:11.120
que a mí, por lo menos, no me ha quedado claro, de si el, por ejemplo, tú puedes coger un documento

00:58:11.120 --> 00:58:17.360
de tu disco y decirle, sumaráis, ¿no? Y que te haga un resumen. ¿Pero ese resumen es gratis o

00:58:17.360 --> 00:58:23.640
ese resumen tiene un coste? Porque lo que va a ser gratis es la integración de BIN con inteligencia

00:58:23.640 --> 00:58:30.240
artificial en el sistema operativo y que a través de ese, de ese BIN en el sistema operativo le

00:58:30.240 --> 00:58:36.720
puedas pedir cosas del sistema operativo, ¿vale? Pero, y eso será Windows Copilot,

00:58:36.720 --> 00:58:46.240
pero ¿Windows Copilot va a meter el que tú hagas un resumen de tus documentos de Word y esté gratis?

00:58:46.240 --> 00:58:54.600
Porque yo creo que va a haber modelos distintos. Para eso que cuentas de lo del sistema,

00:58:54.600 --> 00:58:58.960
de pedirle que pongan modo oscuro y cosas de esas, yo creo que van a hacer un modelo pequeñito que

00:58:58.960 --> 00:59:06.280
se ejecute en la nube, pero digamos en máquinas más modestas y que cueste menos dinero. Y luego

00:59:06.280 --> 00:59:12.120
la parte que ya será máquinas más pesadas, un modelo más grande y que encima se entrene con tus

00:59:12.120 --> 00:59:17.120
datos, irá en la licencia aparte. Es que es imposible, es imposible que de esto gratis,

00:59:17.120 --> 00:59:23.200
no puede. Sobre todo a los millones y millones y millones y millones de usuarios de Windows.

00:59:23.200 --> 00:59:27.760
Y la parte, a ver, ChatGPT... Y sobre todo con Windows pirata.

00:59:27.760 --> 00:59:37.760
ChatGPT tiene Windows gratis, digo, tiene parte gratis, pero claro, primero que a veces está

00:59:37.760 --> 00:59:43.600
petado y no te deja entrar y demás, pero encima no entrena con tus datos. Es que entrenarlo con

00:59:43.600 --> 00:59:50.080
tus datos es mucho proceso, mucho tiempo que tienes ocupados esas máquinas virtuales, pero bueno...

00:59:50.080 --> 00:59:55.760
Pero es contexto, es decir, no es que esté entrenado con tus datos, sino que tú le mandas

00:59:55.760 --> 01:00:02.680
tu fichero y él se lo lee. Pero claro, si tu fichero ocupa la misma vida, estamos hablando

01:00:02.680 --> 01:00:09.800
de contextos muy grandes y cuanto más grande es el contexto, más coste tiene. Y si encima,

01:00:09.800 --> 01:00:17.280
como dice Microsoft, todo funciona con GPT-4, que GPT-4 no es gratuito, ¿vale? Pues y de hecho,

01:00:17.280 --> 01:00:25.040
si lo usas GPT-4 en Bing, tienes una limitación de contexto de hasta 30 peticiones, pues en fin,

01:00:25.040 --> 01:00:30.200
a lo mejor lo hacen medio gratis al principio para que la gente se acostumbre, pero esto...

01:00:30.200 --> 01:00:35.760
Pero es que es medio gratis en algo como Windows. Claro, entonces, si le pides cosas del sistema

01:00:35.760 --> 01:00:41.720
operativo, eso yo entiendo que será gratis, pero en el momento en el que tú tienes, yo que sé,

01:00:41.720 --> 01:00:49.640
que le digas cópiame tal fichero a tal carpeta o conviérteme este fichero a no sé qué, vale,

01:00:49.640 --> 01:00:54.600
entonces a lo mejor es gratuito porque al final son procesos que simplemente van a la nube,

01:00:54.600 --> 01:00:59.400
ven lo que tienen que hacer, vuelven y te lo hacen en tu máquina local, perfecto. Pero...

01:00:59.400 --> 01:01:03.920
El resto no lo sé. Sin embargo, Apple, repito, Apple lo va a poner en local,

01:01:03.920 --> 01:01:11.640
va a ponerte un modelo de generación de texto en local en tu máquina, por lo que no va a haber

01:01:11.640 --> 01:01:16.160
limitación. A ver, la limitación va a ser la capacidad que tenga dicho modelo. Si ese modelo

01:01:16.160 --> 01:01:22.440
tiene una capacidad de 8000 tokens, pues si le quieres dar un documento que sea demasiado largo,

01:01:22.440 --> 01:01:27.440
pues te dirá, no, mira, te lo voy a tener que trocear porque no puedo leerlo entero, ¿vale?

01:01:27.440 --> 01:01:32.800
Si le pone... porque claro, aquí también los contextos importan, ¿vale? No es lo mismo

01:01:32.800 --> 01:01:37.960
ahora mismo GPT-4, si no me equivoco, funciona con los 8000 tokens de contexto. Eso es,

01:01:37.960 --> 01:01:43.280
aproximadamente, unas 7000 palabras, ¿vale? En el momento en el que tú superas las 7000

01:01:43.280 --> 01:01:50.760
palabras, GPT se olvida, ¿vale? A mí me ha pasado. Yo he llegado a tener conversaciones muy largas

01:01:50.760 --> 01:01:57.760
con él y cuando le he preguntado por cosas que le hablé al principio, se había olvidado de ellas,

01:01:57.760 --> 01:02:02.760
porque había superado el contexto de las 7000 palabras. Entonces, claro, esas 7000 palabras

01:02:02.760 --> 01:02:07.880
son las que llegan al total, ¿vale? Que sí, que 7000 palabras es una burrada, ya lo sé,

01:02:07.880 --> 01:02:11.440
pero al final, entre lo que tú le dices y lo que él te contesta, tal.

01:02:11.440 --> 01:02:18.080
Claro, entonces, teóricamente, GPT-4 va a llegar a tener contextos de 32.000 tokens,

01:02:18.080 --> 01:02:25.640
que serían unas 28.000 o 29.000 palabras, ¿vale? Pero, claro, en fin, hasta que lleguemos a eso,

01:02:25.640 --> 01:02:30.600
y cuanto mayor es el contexto, más coste tiene. Entonces, Apple lo que está intentando es hacer

01:02:30.600 --> 01:02:36.080
que esto funcione en local, ¿vale? Por eso no se ha metido todavía en todo este fregado. La gente

01:02:36.080 --> 01:02:41.760
dice, ¡ay, es que Apple llega tarde! ¡Ay, mi, mi, mi, mi, mi, mi! Pues lo normal, ¿vale? Pero no

01:02:41.760 --> 01:02:48.040
es que llegue tarde, es que lo que Apple no va a hacer es montar un servicio en la nube para quedarse

01:02:48.040 --> 01:02:53.440
con tus datos y procesar tus datos, ¿vale? Porque Microsoft te está diciendo que no van a usar tus

01:02:53.440 --> 01:02:59.400
datos para nada malo y que para brindar el niño Jobs, pero tú tienes que creerlos, ¿vale? Entonces,

01:02:59.400 --> 01:03:04.920
ahora mismo, toda la IA está funcionando en la nube y toda la IA le está dando tus datos. Y si

01:03:04.920 --> 01:03:12.480
tú vas a usar Microsoft 365 Copilot para que el Office haga virguerías, tú tienes que saber que

01:03:12.480 --> 01:03:19.880
toda tu información confidencial de tu empresa va a ir a la nube. Y la van a tener ahí, pues bueno,

01:03:19.880 --> 01:03:24.720
bueno, pues tú mismo, tú verás lo que hace, ¿vale? Si no te importa, pues genial.

01:03:24.720 --> 01:03:30.120
Dar un paquete para empresas, pero que es bastante más caro, en donde una de las cláusulas es que no

01:03:30.120 --> 01:03:35.160
sale. O sea, que tendrán unos servidores dedicados, pero es muchísimo más caro, obviamente.

01:03:35.160 --> 01:03:41.080
Claro, entonces, al final, pues ¿qué pasa? Pues que Apple se enfrentó a este problema el año pasado,

01:03:41.080 --> 01:03:47.560
el hecho de que empezaban, se encontró, ¿vale? Que había varios desarrolladores que estaban

01:03:47.560 --> 01:03:56.840
usando GitHub Copilot y claro, Apple dijo, a ver señores, guay, pero los proyectos que aún no han

01:03:56.840 --> 01:04:04.640
salido no podéis usar GitHub Copilot, porque eso es secreto industrial, ¿vale? De hecho, sabemos que

01:04:04.640 --> 01:04:11.160
Apple trabaja con Git, con GitHub, ¿vale? Pero trabaja con GitHub cuando ya ha publicado un

01:04:11.160 --> 01:04:15.680
elemento, pero cuando está en privado, trabaja con sus propios servidores.

01:04:15.680 --> 01:04:23.040
De que en GitHub, claro, tú le pones en Copilot, le pones Key o Sender Key y claro,

01:04:23.040 --> 01:04:29.080
y te puede dar una clave de API de algún usuario, del código de algún usuario.

01:04:29.080 --> 01:04:35.480
Y así se filtraban claves de API. Por eso, entonces, es que no tiene...

01:04:35.480 --> 01:04:40.240
Entonces, claro, ahí no puede Apple permitirse. Entonces, Apple se puso a hacer su propia IA,

01:04:40.240 --> 01:04:47.680
ya tiene su propia IA generativa, que según dicen es igual de buena que GPT-4 y permite

01:04:47.680 --> 01:04:52.120
hacer auténticas virguerías, como ya estamos viendo, pero Apple tiene sus tiempos y Apple

01:04:52.120 --> 01:04:57.440
lo que quiere es cargar eso en local, en tu ordenador o en tu móvil o donde sea,

01:04:57.440 --> 01:05:02.240
para que todo sea privado y no tenga que salir fuera. Y para eso, pues hace falta tiempo y hace

01:05:02.240 --> 01:05:07.880
falta que esté todo bien integrado. Entonces, bueno, pues todo esto llegará y va a ser un

01:05:07.880 --> 01:05:13.240
cambio brutal en los sistemas operativos, que llegará poco a poco y que las primeras versiones

01:05:13.240 --> 01:05:19.120
pues se harán un poco más arcaicas y lo iremos mejorando poco a poco, lo normal, pero llegará

01:05:19.120 --> 01:05:25.760
a un punto en el que casi la mayoría de cosas podremos hablarlas. Yo podré llegar a mi ordenador

01:05:25.760 --> 01:05:35.920
y decirle, oye Paca, ábreme Logic, créame un proyecto de cuatro pistas de audio, pon la fuente

01:05:35.920 --> 01:05:42.640
tal en la pista primera y prepárate para empezar a grabar. Y que él me haga todo y me lo ponga

01:05:42.640 --> 01:05:50.360
a funcionar. Y luego de unos años ya que grabe el programa. Bueno, ya sabes que hay avatares

01:05:50.360 --> 01:05:55.960
virtuales que permiten hacerlo. De hecho, yo me tengo a mí mismo hablando en varios idiomas.

01:05:58.120 --> 01:06:06.080
Y pues eso está a la vuelta de la esquina. Lo probó dotcsv. Cuando tú tienes un set como el

01:06:06.080 --> 01:06:14.120
que tenemos tú y yo, que es una imagen fija, yo me puedo ahora mismo ir a Heiyen, darle que

01:06:14.120 --> 01:06:20.680
quiere un instan avatar, coger y grabarme hablando durante dos minutos con este fondo e intentando

01:06:20.680 --> 01:06:26.920
no gesticular por encima de los hombros. Entonces voy comentando, no sé qué, tal, tal, pipi, pipi,

01:06:26.920 --> 01:06:33.480
papapá. Grabo dos minutos de audio, subo el vídeo, se procesa y a los 10 minutos ya tengo un avatar

01:06:33.480 --> 01:06:40.880
mío. Entonces ahora cualquier audio que yo le dé a ese avatar va a ser yo con este fondo moviendo

01:06:40.880 --> 01:06:47.240
las manos, gesticulando y haciendo cambios, haciendo que mi avatar diga el audio que le

01:06:47.240 --> 01:06:52.120
he subido. Entonces, si yo le subo un audio diciendo cualquier otra cosa, yo, por ejemplo,

01:06:52.120 --> 01:07:01.560
podría grabar el podcast como podcast y luego dárselo a este avatar para que lo genere. De

01:07:01.560 --> 01:07:12.280
hecho, hay canales 24 horas de venta en China donde las chicas que están vendiendo productos

01:07:12.280 --> 01:07:22.480
son avatares de IA, que las empresas están pagando mil dólares al mes y tienen un avatar que es

01:07:22.480 --> 01:07:31.320
capaz hasta de interactuar con los productos que tiene ahí. Entonces es simplemente una mujer que

01:07:31.320 --> 01:07:37.280
se graba con unos minutos de referencia, se entrena y a partir de ahí, si ella se va porque está

01:07:37.280 --> 01:07:44.840
cansada o se va a dormir, se queda el avatar y sigue vendiendo y pueden llegar a hacer seis,

01:07:44.840 --> 01:07:51.040
siete, ocho, nueve mil dólares mientras está solo el avatar y nadie sabe que es un avatar,

01:07:51.040 --> 01:07:57.880
que no es real, ¿vale? Ese es el nivel en el que estamos ahora mismo, ¿vale? Entonces imagínate.

01:07:57.880 --> 01:08:08.120
Cada día es algo nuevo, la verdad. Pues sí, entonces imagínate la posibilidad en Apple

01:08:08.120 --> 01:08:16.360
Vision Pro. Imagínate una aplicación, te lo digo así, el primero que se le ocurra la idea para

01:08:16.360 --> 01:08:25.000
vosotros, jugadores, de una novia virtual. Una novia virtual que tú la invoques cuando quieras,

01:08:25.000 --> 01:08:29.520
que le hables, que te cuente, que te diga, que te explique qué tal, qué para arriba,

01:08:29.520 --> 01:08:35.760
qué para abajo, que incluso si tienen los derechos. Hoy día hay modelos a través de Telegram,

01:08:35.760 --> 01:08:44.160
por ejemplo, con la voz de Amuranz, ¿vale? En el que tú le puedes decir lo que quieras,

01:08:44.160 --> 01:08:48.360
lo que quieras a ese avatar. Bueno, la chica hasta que estuvo con...

01:08:48.360 --> 01:08:53.200
Y no te contesta Amuranz, te contesta una voz sintetizada que Amuranz ha grabado,

01:08:53.200 --> 01:08:59.560
pero que es absolutamente real. Tú le escribes a través de Telegram y ella te manda una nota de

01:08:59.560 --> 01:09:06.480
voz contestándote. Y entonces tienes una conversación real con una IA que tiene la

01:09:06.480 --> 01:09:13.240
voz de Amuranz que es indistinguible de la voz real. La mujer de... Bueno, la mujer no,

01:09:13.240 --> 01:09:17.760
que estuvo con él o no me acuerdo. Estuvo con una cantante que tuvo... Creo que ha salido que

01:09:17.760 --> 01:09:26.920
ha tenido dos hijos con ella. Grimes. Grimes. Pues ha creado con una IA su voz para que tú puedas

01:09:26.920 --> 01:09:32.120
hacer una canción con su voz y a cambio le tienes que dar, no sé, un porcentaje de lo que saques.

01:09:32.120 --> 01:09:42.280
Pues fíjate. Pues sí. Pues en la IA no dejan de salir noticias, Julio, pero en Swift y en Apple

01:09:42.280 --> 01:09:46.160
también hay algunas noticias. Así que si quieres pasamos a la siguiente sección.

01:09:46.160 --> 01:10:07.160
Tiramos. Pues hay noticias curiosas, ¿vale? Noticias curiosas. Yo, la que más, la que más,

01:10:07.160 --> 01:10:16.600
la que más que he de reconocer que me dejó flipándolo es el tema del nuevo proyecto de Unit

01:10:16.600 --> 01:10:29.800
Testing basado en macros para Swift. Me parece una locura. O sea, me parece un cambio brutal,

01:10:29.800 --> 01:10:39.360
¿vale? Un cambio brutal para definir cómo serían, cómo sería el Unit Test, ¿vale? Y esto no es

01:10:39.360 --> 01:10:46.760
quitar XCTest, ¿de acuerdo? O sea, estamos hablando de pues SwiftData. ¿SwiftData qué es?

01:10:46.760 --> 01:10:53.160
SwiftData es una capa de macros de Swift que cambia la forma en la que se construye CoreData

01:10:53.160 --> 01:11:01.640
para que en vez de ser Objective-C sea mucho más Swift. Pues bien, es lo que han propuesto en los

01:11:01.640 --> 01:11:08.320
foros de Apple, ¿vale? A través de una nueva aproximación en los testing, ¿vale? Estaríamos

01:11:08.320 --> 01:11:19.520
hablando de usar la macro adjunta arroba test para poder tener la capacidad de realizar test

01:11:19.520 --> 01:11:25.040
de una forma totalmente distinta. Ya no habría que crear una función que empezara con el nombre

01:11:25.040 --> 01:11:36.080
test y que luego usara los famosos XCTest de pues el XCTAssertTrue, XCTAssertNotNil,

01:11:36.080 --> 01:11:44.000
XCTAssert lo que sea, ¿vale? Estaríamos hablando que yo, para definir una función que fuera de

01:11:44.000 --> 01:11:49.920
tipo test, ¿vale? Ahora lo que tengo que hacer, como ya sabéis, es dentro de un target de testing

01:11:49.920 --> 01:11:57.560
poner función test en minúscula y luego ya el nombre que lo añado lo que sea. Y simplemente

01:11:57.560 --> 01:12:02.560
con que empiece con la palabra test en minúscula ya se incluye como un test unitario, ¿vale? Pues

01:12:02.560 --> 01:12:10.160
ahora lo que habría que poner arriba es arroba test. Entonces al poner arroba test le pondríamos

01:12:10.160 --> 01:12:18.600
la definición, ¿vale? De lo que es ese test, ¿de acuerdo? La definición a nivel de texto, ¿vale?

01:12:18.600 --> 01:12:25.080
De forma que luego le diríamos, por ejemplo, le podríamos dar, por ejemplo, opciones como que

01:12:25.080 --> 01:12:33.000
ese test sólo esté disponible cuando cierto valor de una variable esté correcta o no, ¿vale? Si yo

01:12:33.000 --> 01:12:40.120
pongo simplemente arroba test, ¿vale? Y ya está, pues sería pues eso, arroba test. Y entonces pues yo le doy

01:12:40.120 --> 01:12:47.960
ahí la descripción y punto. Pero le puedo decir, activa este test sólo si el valor isAvailable está

01:12:47.960 --> 01:12:54.440
en tal instancia, ¿vale? Y entonces en ese caso entraría en el test. O por ejemplo, a los test les

01:12:54.440 --> 01:13:02.120
puedo enviar argumentos, ¿vale? Argumentos que permitan recoger información que luego capturará

01:13:02.120 --> 01:13:08.480
ese test para poder usarlo como datos internos. Entonces cuando yo ya tengo el arroba test con

01:13:08.480 --> 01:13:15.360
esas entradas, debajo pongo la función, ¿vale? Entonces dentro de la función lo que cambia es

01:13:15.360 --> 01:13:23.080
que en vez de poner el xct, a, ser, xct, lo que sea, xct, xct, xct, lo único que vamos a poner es

01:13:23.080 --> 01:13:32.760
hashExpect, ¿vale? Se espera esto, ¿vale? Entonces yo pongo hashExpect que, por ejemplo, la cantidad de tal

01:13:32.760 --> 01:13:40.240
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

01:13:40.240 --> 01:13:45.400
yo le quiera poner, ¿de acuerdo? Simplemente hashExpect... Pero con el operador directamente,

01:13:45.400 --> 01:13:50.880
¿no? Como argumentos, como se hace... Exacto, y ponemos el operador directamente y listo. Vale,

01:13:50.880 --> 01:14:00.560
esto es un cambio brutal, pero brutal. A mí me ha parecido de una belleza la forma de describirlo,

01:14:00.560 --> 01:14:07.360
que me ha dejado muy loco. O sea, si esto lo tenemos el año que viene, que tiene pinta porque,

01:14:07.360 --> 01:14:13.440
en fin, sabemos que Swift funciona de esta manera y además sería una API multiplataforma, por lo

01:14:13.440 --> 01:14:19.320
que los tests en Linux o en cualquier otro sistema serían exactamente iguales. Bueno,

01:14:19.320 --> 01:14:26.520
esto es un cambio de paradigma, pero madre mía, porque facilitaría muchísimo la comprensión de

01:14:26.520 --> 01:14:32.200
los tests y, sobre todo, la velocidad a la que hacemos los tests, ¿vale? Yo no sé cómo lo ves

01:14:32.200 --> 01:14:40.360
tú, ¿qué te parece? Pues yo también me ha volado la cabeza porque, a ver, la sintaxis es mucho más

01:14:40.360 --> 01:14:46.600
sencilla. Todo eso, todo el engorro este que teníamos en los tests, todo eso de creo una

01:14:46.600 --> 01:14:51.240
función por cada caso, no sé qué, pues esto al final te lo hace. Como dices, pues le pones los

01:14:51.240 --> 01:14:56.680
argumentos y te hace un test para cada, o sea, te genera el test para cada argumento. Luego te,

01:14:56.680 --> 01:15:03.000
no sé, te quitas como toda la sobrecarga de, no, tiene que empezar por test y esas chorradas,

01:15:03.000 --> 01:15:10.280
entre comillas. Luego la parte de assets era muy complicada, ¿vale? Cuando miras a ver si cumple

01:15:10.280 --> 01:15:16.840
ese test, algo, pues eran funciones con parámetros, con tal. Pues aquí se supone que con la sintaxis

01:15:16.840 --> 01:15:21.680
puedes utilizar el propio Swift, ¿vale? Pues todas las funciones de filter, map, no sé qué,

01:15:21.680 --> 01:15:27.800
puedes utilizarlas, ¿vale? Y comparadores de los de toda la vida, pues igual, distinto, mayor,

01:15:27.800 --> 01:15:34.080
menor, sin tener que utilizar una sobrecarga de una función que era más engorroso. Y no sé,

01:15:34.080 --> 01:15:42.000
me alegra porque esto en principio es algo que es de la gente de Apple, pues que tiene sus proyectos

01:15:42.000 --> 01:15:47.280
internos, ¿vale? Pues como Swift es de código abierto, pues de hecho el que lo explica, que

01:15:47.280 --> 01:15:52.720
está en el post que ha puesto en los foros de Swift, pues eso, que han hecho Open Source,

01:15:52.720 --> 01:16:00.560
una librería en la que estaban él y sus colegas, sus compañeros, trabajando. Y nada, pues que la

01:16:00.560 --> 01:16:05.800
ponen Open Source porque todavía queda, ¿vale? No está, no está acabada ni mucho menos, pero bueno,

01:16:05.800 --> 01:16:11.480
ahora con la comunidad, pues si coge tracción, pues no creo que tarde mucho. A lo mejor en, no sé,

01:16:11.480 --> 01:16:17.120
en unos meses tienen algo, una versión preliminar y en medio año estamos ya disfrutando de esta,

01:16:17.120 --> 01:16:25.960
de esta librería. O a lo mejor esperan a, porque a ver, Swift es Open Source, pero está el amo del

01:16:25.960 --> 01:16:30.600
Proud, sigue siendo Apple, ¿vale? Y a lo mejor esto, pues es una de las cosas que nos presentan en la

01:16:30.600 --> 01:16:36.880
siguiente WWDC como la nueva librería de testing que tenéis que usar, que a mí no me extrañaría,

01:16:36.880 --> 01:16:44.600
porque tiene muy buena pinta. Está, fíjate, ahora mismo estaría soportada, ¿vale? Porque esto es un

01:16:44.600 --> 01:16:52.120
proyecto que ya tenéis en GitHub, ¿vale? Podéis instalarlo, podéis probarlo. Insisto, es una

01:16:52.120 --> 01:16:57.560
propuesta preliminar, ¿vale? Ni siquiera es una beta, es una propuesta preliminar que dará lugar

01:16:57.560 --> 01:17:04.840
a muchos cambios, ¿vale? Pero lo tenéis en github.com barra apple barra swift guión testing

01:17:04.840 --> 01:17:13.560
y soporta macOS, iOS, watchOS, tvOS, Ubuntu y está pendiente de Windows, porque ahora mismo en Windows

01:17:13.560 --> 01:17:19.600
todavía no se soportan las macros, ¿vale? Pero esto no es algo que, insisto, esto viene de Apple,

01:17:19.600 --> 01:17:26.320
¿vale? Esto es github.com barra apple barra swift guión testing y esto lo hace Stuart Montgomery,

01:17:26.320 --> 01:17:32.840
Stuart Montgomery que es un ingeniero de software del equipo de XCTest en Scouse en Apple, ¿vale?

01:17:32.840 --> 01:17:38.120
Esto no es Paco que se ha puesto a hacerlo, ¿vale? Esto es algo oficial y que, bueno, pues es una

01:17:38.120 --> 01:17:47.000
propuesta que ponen ahí, que luego pues obviamente todo esto traerá mucho más juego y traerá mucho

01:17:47.000 --> 01:17:53.560
más cambios, ¿no? Al respecto, pero desde luego, bueno, pues es algo que se ha empezado a trabajar

01:17:53.560 --> 01:18:00.600
y que yo ya te digo, o sea, aplaudo, aplaudo muchísimo el que estas iniciativas se lleven

01:18:00.600 --> 01:18:07.200
a la comunidad open source y que se trabajen y que ojalá hubieran hecho esto con SwiftData, ¿vale?

01:18:07.200 --> 01:18:15.640
Porque claro, la diferencia es que XCTest es una librería que pertenece al propio lenguaje Swift,

01:18:15.640 --> 01:18:21.160
¿vale? Y entonces, bueno, pues el cambio, ¿vale? CoreData no y entonces por eso entiendo que a

01:18:21.160 --> 01:18:24.920
lo mejor no se puso dentro de los foros de Swift, ¿vale? Pero bueno, la verdad que...

01:18:24.920 --> 01:18:30.560
Lo de CoreData no lo entiendo, o sea, bueno, lo de SwiftData entiendo que como viene de CoreData,

01:18:30.560 --> 01:18:36.640
¿vale? Es interoperable y seguramente que por detrás tenga mucho código de CoreData. Yo creo

01:18:36.640 --> 01:18:40.200
por eso no lo han hecho, pero sí que es verdad que a lo mejor SwiftData podrían haberlo enfocado

01:18:40.200 --> 01:18:46.000
como algo que saliese de la propia Swift. A ver, al final Swift tiene manejo de ficheros, que es lo

01:18:46.000 --> 01:18:51.680
que te hace falta para la base de datos. No sé, no sé por qué. Bueno, sí, sé por qué. Porque

01:18:51.680 --> 01:18:58.440
precisamente habrá mucho código todavía y mucha necesidad de CoreData para SwiftData, ¿vale? Y por

01:18:58.440 --> 01:19:02.080
eso no lo han hecho. A lo mejor en el futuro, cuando vaya evolucionando dentro de un par de

01:19:02.080 --> 01:19:10.240
años, sí que lo saquen de, digamos, de una librería, una herramienta de Apple, una librería de Apple, y

01:19:10.240 --> 01:19:16.720
lo pongan como una librería de Swift Open Source, esperemos. Seguramente le vendrá bien. Sí, sí,

01:19:16.720 --> 01:19:24.520
absolutamente. Y luego teníamos otra noticia que, si quieres comentarla tú, que es el SDK Generator,

01:19:24.520 --> 01:19:29.600
¿no? Sí, pues sigue Apple liberando herramientas que a mí me parece bien porque creo que es un

01:19:29.600 --> 01:19:39.320
cambio de idea de ir liberando librerías. Hablamos, creo que hablamos de aquí, de una para parsear HTML,

01:19:39.320 --> 01:19:46.840
para crear la respuesta y la, o sea, la ricos y la responde HTML. Están liberando librerías que

01:19:46.840 --> 01:19:53.560
seguramente tendrían ellos allí pseudo oficiales, internas, ¿vale? Y las están liberando y la verdad

01:19:53.560 --> 01:20:00.400
es que está muy bien. Pues esta de la que voy a hablaros ahora es SDK Generator, le han llamado,

01:20:00.400 --> 01:20:08.320
y viene a resolver un problema que yo tuve en su día cuando hacía librerías, y es que había,

01:20:08.320 --> 01:20:15.480
de aquellas había solo una manera, que era crear una librería normal de toda la vida, que venían

01:20:15.480 --> 01:20:20.120
de C, yo creo, este tipo de librerías, y tú ya la distribuías compilada, había que hacer algunos

01:20:20.120 --> 01:20:25.840
hechizos porque cuando salieron, si querías que la librería funcionase primero y supieras utilizar

01:20:25.840 --> 01:20:31.880
el simulador, que el simulador de ellos no es un emulador, sino que corre sobre la arquitectura

01:20:31.880 --> 01:20:37.600
del Mac, que era x86, y luego salieron procesadores de Apple de 32 bits y también los había de 62,

01:20:37.600 --> 01:20:43.360
con lo cual ya era también otras dos arquitecturas, pues tenías que hacer una, un hechizo para

01:20:43.360 --> 01:20:49.160
compilarlas por separado y distribuirlas en un solo binario, y tú a tu usuario de la librería,

01:20:49.160 --> 01:20:54.640
vale, le dabas ese, esa librería, ese binario compilado que tenía todas las arquitecturas,

01:20:54.640 --> 01:21:00.880
y era bastante engorroso. Ahora tenemos aquí, o sea, tenemos otra cosa intermedia que eran en su

01:21:00.880 --> 01:21:06.240
día los.framework, que era como esto, pero más avanzado, se le podían poner ciertas cabeceras,

01:21:06.240 --> 01:21:13.040
recursos, por separado, tenía, y luego salieron los.xcframework, vale, que es otra manera también

01:21:13.040 --> 01:21:17.800
de distribuir, pero al final tú le tienes que dar un archivo, vale, que es un poquito por lo que,

01:21:17.800 --> 01:21:23.080
lo que cuento, engorroso el crearlo para las arquitecturas y demás. Luego vino Swift Package

01:21:23.080 --> 01:21:30.680
Manager, porque antes teníamos la Cocoa, vale, Cocoa Pots, que no era oficial, vale, Apple sacó

01:21:30.680 --> 01:21:36.920
Swift Package Manager, entonces puedes distribuirlo, pero claro, un Swift Package Manager es código,

01:21:36.920 --> 01:21:41.760
si quieres distribuirlo en código, es abierto, todo el mundo lo puede ver, claro, hay gente que

01:21:41.760 --> 01:21:46.640
querrá que su librería no se pueda ver cómo funciona por dentro, cómo son sus tripas. Entonces

01:21:46.640 --> 01:21:54.040
lo que hacía la gente era volver a estas librerías compiladas y metía como recurso, como archivo,

01:21:54.040 --> 01:22:02.360
como fichero, estos bundles, que por ejemplo yo creo que Firebase y todas esas hacen esto,

01:22:02.360 --> 01:22:07.640
tú no puedes ver el código dentro, sino que directamente Swift Package Manager te da acceso

01:22:07.640 --> 01:22:13.600
a los archivos que vas subiendo ya compilados, vale. Pues Apple lo que nos ha traído, vale,

01:22:13.600 --> 01:22:22.320
es una nueva forma de generar estas librerías, digamos que ya es la librería compilada para que

01:22:22.320 --> 01:22:28.040
no se vea el código, vale. Entonces nos ha dado el Swift Generator, este que es, digamos, una

01:22:28.040 --> 01:22:38.200
herramienta que genera la compilación de todas esas arquitecturas, vale, para que sea mucho más

01:22:38.200 --> 01:22:45.320
sencillo el crear estos archivos y el compartir estas librerías, vale. De momento han empezado

01:22:45.320 --> 01:22:52.120
soportando la parte que tenía cero soporte, que es la de Ubuntu, vale, pero la idea es que esto

01:22:52.120 --> 01:22:59.520
se vaya extendiendo al runtime de macOS y puedas generar tu librería y distribuirla con Swift

01:22:59.520 --> 01:23:04.480
Package Manager, pero no con este workaround que era al final distribuir un fichero en lugar de

01:23:04.480 --> 01:23:12.560
código, vale. Y nada, tienen en este caso un uso bastante pequeñito, vale, o un porcentaje de uso

01:23:12.560 --> 01:23:17.880
bastante pequeñito, pero bueno, está bien que Apple vaya liberando estas librerías y vaya dando

01:23:17.880 --> 01:23:22.840
a desarrolladores. Seguro que alguno de vosotros estáis en ese punto y esto es una buena noticia

01:23:22.840 --> 01:23:28.280
sin duda porque yo de aquellas lo pasé mal y ahora sé que la gente que está distribuyendo SDKs,

01:23:28.280 --> 01:23:35.480
pues al final eso, pues cada vez que tiene una nueva versión es, oye, hemos generado una nueva

01:23:35.480 --> 01:23:42.040
versión, te mando el binario. Como los animales, en julio en vez de un gestor de dependencia lo que

01:23:42.040 --> 01:23:47.360
tienes que hacer es copiar ese binario cada vez y es un poco rollo para el que lo genera y rollo

01:23:47.360 --> 01:23:54.640
para el que lo recibe, que cada vez que cambien tiene que generar el binario. Bueno, pues es una

01:23:54.640 --> 01:24:03.280
cosa que, bueno, no deja de ser interesante y bueno, pues la verdad que son pequeñas cositas,

01:24:03.280 --> 01:24:10.720
es como la librería que han metido para el tema de los certificados, de los ASN1, de los X509,

01:24:12.000 --> 01:24:19.840
la nueva librería, como tú dices, de HTTP y tal, que también había por ahí. En fin,

01:24:19.840 --> 01:24:26.280
hay un montón de nuevas opciones que desde luego me parece bastante interesante que se

01:24:26.280 --> 01:24:33.120
dé esa circunstancia y que te permita seguir mejorando tu código, etc. Aquí hay una cosa

01:24:33.120 --> 01:24:44.080
bastante curiosa. ¿Por qué Apple hace esto? No hace demasiado, hubo una polémica porque se acusó

01:24:44.080 --> 01:24:52.000
a Apple, es que tiene narices la cosa, de tener demasiadas palabras reservadas en el lenguaje

01:24:52.000 --> 01:24:58.520
Swift. Se considera que un buen lenguaje de programación, o que tenga una curva fácil de

01:24:58.520 --> 01:25:05.400
aprendizaje, es aquel que tiene pocas palabras reservadas. En fin, yo disiento completamente de

01:25:05.400 --> 01:25:16.800
eso. Es decir, cuando tú montas algo, por ejemplo, en JavaScript o por ejemplo en Python, sabes que

01:25:16.800 --> 01:25:23.160
todo lo que montes lo vas a montar en base a librerías de terceros, a librerías de todo

01:25:23.160 --> 01:25:28.920
tipo, librerías para hacer cualquier cosa, porque el lenguaje en sí no tiene capacidad para hacer

01:25:28.920 --> 01:25:37.280
una mierda. Eso para mí no es un buen lenguaje de programación, insisto, es mi opinión. Para mí,

01:25:37.280 --> 01:25:42.560
un buen lenguaje de programación es el que tiene lo que tú necesitas integrado en el propio lenguaje,

01:25:42.560 --> 01:25:49.040
es el que tiene integrado Asynnawait, es el que tiene integrado XCTest, es el que tiene

01:25:49.040 --> 01:25:56.520
integrado librerías para usar distintos tipos de tipos de datos de una manera natural, es el

01:25:56.520 --> 01:26:03.200
que tiene integrado todo lo que puedas llegar a necesitar, el que tiene integrada toda la

01:26:03.200 --> 01:26:10.960
gestión de peticiones de red, etc. La serialización de datos, es decir, yo si quiero serializar datos

01:26:10.960 --> 01:26:16.400
en cualquier otro lenguaje tengo que buscar una librería de serialización. En Apple tengo Codable,

01:26:16.400 --> 01:26:23.640
no tengo que ir a buscarlo fuera. Y eso lo que hace, repito, en mi opinión, después de haber

01:26:23.640 --> 01:26:32.760
manejado lenguajes de programación durante más de 40 años, yo creo que al final lo importante

01:26:32.760 --> 01:26:40.360
es que las herramientas que necesites estén, uno, disponibles y dos, con garantías. Y el que no las

01:26:40.360 --> 01:26:45.760
tenga disponibles... Te pasa que utilizas una librería como CocoaPods y luego nadie te la

01:26:45.760 --> 01:26:52.760
actualiza. Por ejemplo, o que tú uses lo que le está pasando a un montón de gente con RxSwift,

01:26:52.760 --> 01:26:58.080
que de pronto quiere poner RxSwift en Xcode 15, pero como la librería Observable se llama igual

01:26:58.080 --> 01:27:05.880
que la de RxSwift, pues entonces a tomar por saco, ya no funciona. Y no puedes compilar. O como le

01:27:05.880 --> 01:27:10.840
ha pasado a un cliente que de pronto, mágicamente, el año pasado estaban usando una librería que

01:27:10.840 --> 01:27:19.040
habían decidido tener el nombre de NavigationStack. Pues ya saben lo que pasa con SwiftUI. Entonces,

01:27:19.040 --> 01:27:26.480
claro, este tío, el que hizo esta librería, en vez de cambiar el nombre y llamarlo StackNavigation,

01:27:26.480 --> 01:27:31.720
por ejemplo, darle la vuelta al nombre y punto, y que simplemente tengas que cambiar, no. Decide

01:27:31.720 --> 01:27:36.200
que no sólo va a cambiar el nombre, sino que además va a refactorizar la librería entera

01:27:36.200 --> 01:27:42.680
para que funcione de una forma distinta. Conclusión, la aplicación a la basura. Porque toda la

01:27:42.680 --> 01:27:48.200
aplicación de más de mil líneas tienes que refactorizarla entera porque toda esa librería

01:27:48.200 --> 01:27:55.760
está metida hasta la cocina de tu casa. Pues no, mira, lo siento, pero no. Que eso te lo puede

01:27:55.760 --> 01:28:00.920
hacer también Apple, por supuesto, te lo puede hacer también Apple, pero no te lo va a hacer tan...

01:28:00.920 --> 01:28:07.560
Es decir, te va a ir avisando y te va a ir diciendo, oye, que hay aquí un cambio, que esto no sé qué,

01:28:07.560 --> 01:28:15.720
y no te va a hacer cambios de ese calado. Un Unity sí, pero un Apple no. Pero bueno,

01:28:15.720 --> 01:28:22.480
independientemente, la gente considera que tiene demasiadas palabras reservadas. Conclusión,

01:28:22.480 --> 01:28:27.480
pues que Apple lo que está haciendo ahora es sacar todo lo que considera extra del lenguaje

01:28:27.480 --> 01:28:33.600
a librerías externas como dependencias, y si tú quieres usar los algoritmos asíncronos que igualan

01:28:33.600 --> 01:28:39.720
Async Await con Combine, si quieres usar los nuevos tipos de colecciones con las colas o con

01:28:39.720 --> 01:28:46.080
los diccionarios o conjuntos ordenados, pues todo eso lo tienes que instalar aparte. O la librería,

01:28:46.080 --> 01:28:51.320
por ejemplo, de Swift Numerics, para tipos de datos avanzados. Entonces, bueno, pues ese sería

01:28:51.320 --> 01:29:00.680
un poco el tema. Entonces, bueno, pues es lo que hay. Siempre buenas noticias, más herramientas.

01:29:00.680 --> 01:29:06.440
Y si quieres, cambiamos un poco de tercio y hablamos de versiones, versiones de iOS en este

01:29:06.440 --> 01:29:13.640
caso, porque a lo mejor los menos abezados os habréis dado cuenta, los más abezados os habréis

01:29:13.640 --> 01:29:23.600
dado cuenta que salió iOS 17, pero inmediatamente salió iOS 17.0.1. Y esto tiene una explicación muy

01:29:23.600 --> 01:29:32.720
sencilla que os voy a dar a continuación, y es que la versión 17 tiene que estar preparada, supongo,

01:29:32.720 --> 01:29:38.800
que, bueno, se puede ver por la compilación, pero finales de agosto, ¿vale? Mediaos finales de

01:29:38.800 --> 01:29:44.360
agosto. ¿Por qué? Porque todos los iPhone nuevos que van a salir en septiembre, que noticia,

01:29:44.360 --> 01:29:49.640
se están fabricando ya, pues no sé cuándo empezará, pues en mayo, yo creo, mayo, junio,

01:29:49.640 --> 01:29:54.840
empieza ya la producción del iPhone para que el día que estrenan en septiembre tengan suficiente

01:29:54.840 --> 01:30:02.520
stock, ¿vale? Para que te llegue a casa. Pues tiene que estar ya preparado y en ese último

01:30:02.520 --> 01:30:09.120
momento es cuando ya le ponen su versión que tiene que ir. Entonces, claro, ¿qué pasa? Que de aquí a

01:30:09.120 --> 01:30:15.160
que sale la versión, que pasan dos, tres semanas, pues siempre salen errores, ¿vale? De hecho,

01:30:15.160 --> 01:30:21.360
sacan la Release Candidate, esa es la que está metida normalmente en los iPhone, pero está metida

01:30:21.360 --> 01:30:30.400
de una semana antes, ¿vale? Entonces, claro, ahí normalmente la versión.0.1 sale muy rápido. Pero

01:30:30.400 --> 01:30:35.720
¿qué ha pasado también? Que habréis visto, los que hayáis estrenado iPhone, es que lo primero que

01:30:35.720 --> 01:30:42.120
hacíais cuando instalabais vuestro iPhone es que os pedía que actualizaseis a la.0.2. ¿Y por qué?

01:30:42.120 --> 01:30:48.760
Pues porque esa primera versión que salió tendría alguna cosa aparte específica para esos iPhones

01:30:48.760 --> 01:30:54.760
que tampoco funcionaba bien y hay que actualizar, ¿vale? Además, la.0.2 está solo para los iPhone

01:30:54.760 --> 01:31:01.280
nuevos. Sí, exactamente. Cuando empezabas a hacerlo, te pedía que actualizases y por eso es

01:31:01.280 --> 01:31:07.040
la explicación que tiene, que es bastante simple, pero que a la gente muchas veces es la típica de

01:31:07.040 --> 01:31:11.800
joder ya, porque estaba mala versión. Efectivamente, nos lo hemos contado muchas veces, vivimos en

01:31:11.800 --> 01:31:18.880
estado de beta permanente, pero en este caso las fechas obligan a tener que cerrar versión a finales

01:31:18.880 --> 01:31:25.640
de agosto y normalmente pues no está suficientemente pulida o siempre sale algo de última hora y por

01:31:25.640 --> 01:31:34.080
eso tenemos estas versiones rápidas. Pero, Julio, ¿tienes noticias de que hay una 17.1 en ciernes?

01:31:34.080 --> 01:31:42.160
Sí, de hecho, por completar lo que has comentado, otra de las cosas que tienen esta 17.01 y 17.02

01:31:42.160 --> 01:31:51.080
es el parcheo de tres agujeros de seguridad muy gordos y explotados activamente que no dio tiempo

01:31:51.080 --> 01:31:58.560
a incluir en la versión cuando salió la 17.0, pero que, pues sí, dos días después ya sí dio tiempo

01:31:58.560 --> 01:32:04.680
a meterlas aquí y son tres agujeros de seguridad pues bastante importantes, ¿vale? Si no recuerdo

01:32:04.680 --> 01:32:12.880
mal haber leído, uno o dos de ellos tienen que ver con Pegasus, con el software espía, ¿vale? Y

01:32:12.880 --> 01:32:24.080
luego, aparte, habrá gente como tú con el Apple Watch Ultra 2 que habrá notado que él no funciona,

01:32:24.080 --> 01:32:32.000
que la pincita que tanto se publicitaba con los... Aquí es directo, no pasa nada. No pasa nada, la

01:32:32.000 --> 01:32:37.480
pincita que tanto se publicitaba como una nueva función en los Apple Watch Series 9, volvemos a

01:32:37.480 --> 01:32:44.040
recordar para el que no lo sepa, ¿vale? El hacer la pincita, que es justo el gesto que normalmente

01:32:44.040 --> 01:32:50.000
haríamos con el Apple Vision Pro, ¿vale? Apple ya nos está empezando a hacer que ensayemos, ¿vale?

01:32:50.000 --> 01:32:53.200
Que nos acostumbremos al gestito, ¿vale? Una pincita...

01:32:53.200 --> 01:32:57.240
Soiber tiene el de Futuramatic que está muy contento. ¿La pinza la puedo hacer?

01:32:57.240 --> 01:33:02.800
Exacto. Entonces, la pinza es juntar el dedo gordo con el índice, ¿vale? Haciendo entonces

01:33:02.800 --> 01:33:08.280
uno o dos toques. Eso es lo que funcionaría con Apple Vision Pro. Yo miro a un elemento,

01:33:08.280 --> 01:33:13.640
lo destaco, hago dos veces la pinza y se pone. Pues bien, la pinza, como ya vimos en la

01:33:13.640 --> 01:33:21.920
presentación de los iPhones, pues se va a incluir como una funcionalidad por defecto en los nuevos

01:33:21.920 --> 01:33:27.280
Apple Watch. ¿Que ya se puede hacer en los anteriores? Sí, en los anteriores se puede

01:33:27.280 --> 01:33:35.440
activar. Tú puedes activar el reloj, puedes hacer doble tap. Suena eso, que ha sonado, el toque

01:33:35.440 --> 01:33:43.240
loco. Y ahora ya puedo hacer los gestos y esto es un Apple Watch Series 4. Pero esto forma parte

01:33:43.240 --> 01:33:50.320
de la accesibilidad, forma parte del Assistive Touch de Watch OS X, ¿vale? Pero tengo que activar

01:33:50.320 --> 01:33:55.440
la opción de accesibilidad y luego, cuando yo quiero hacer el... cuando quiero usar los gestos

01:33:55.440 --> 01:34:01.480
de acción directa, tengo primero que activar el modo de los gestos, ¿vale? Sin embargo,

01:34:01.480 --> 01:34:09.160
con los dispositivos nuevos esa detección de la pinza va a ser continua, ¿vale? Porque gracias

01:34:09.160 --> 01:34:14.920
al motor neural han conseguido una forma de que este proceso, que es muy invasivo a nivel de

01:34:14.920 --> 01:34:22.640
sistema, porque detectar esa pinza supone controlar ciertos grados de cambio en tu tensión, en lo que

01:34:22.640 --> 01:34:29.560
es el flujo sanguíneo, ¿vale? Luego a cambiar también a nivel de detección de movimiento.

01:34:29.560 --> 01:34:37.400
Son una serie de factores que unen ciertos sensores y una serie de detecciones que con

01:34:37.400 --> 01:34:43.240
los Apple Watch antiguos, si lo tuvieras todo el rato activado, la batería se la comería a una

01:34:43.240 --> 01:34:48.640
velocidad brutal, ¿vale? Por lo que para que funcione tienes tú que activarlo a nivel de

01:34:48.640 --> 01:34:56.360
voluntario, ¿vale? Pero en los nuevos, como esa opción ya no es tan... no consume tanto porque

01:34:56.360 --> 01:35:02.040
la han mejorado y le han hecho que funcione bien con el nuevo hardware, pues lo va a tener por

01:35:02.040 --> 01:35:09.640
defecto. Pero por ahora no está, sino que hay que esperar a la 17.1, que teóricamente debería

01:35:09.640 --> 01:35:18.560
de salir en los próximos días como beta para que llegara aproximadamente a mediados finales del mes

01:35:18.560 --> 01:35:26.440
de octubre, ¿vale? Entonces ahí tendríamos esa opción, ¿vale? Tampoco podemos olvidar que los

01:35:28.600 --> 01:35:36.280
los nuevos iPhones tienen también una función, ahora se me ha olvidado cuál era, una función

01:35:36.280 --> 01:35:44.000
que no iba a estar hasta finales de año. Era relacionado con las cámaras, no me acuerdo,

01:35:44.000 --> 01:35:50.400
un modo de las cámaras, no estoy... Sí, no me acuerdo muy bien. Había alguna función,

01:35:50.400 --> 01:35:55.040
lo conté en el mega análisis, pero ahora mismo no me acuerdo, había una función también de las

01:35:55.040 --> 01:36:01.720
que habían anunciado para los para los iPhones, que bueno, que tiene esa funcionalidad, ¿vale?

01:36:01.720 --> 01:36:06.560
Entonces... Y luego había otra que era lo de la aplicación, está el del Journal. Ah, eso es,

01:36:06.560 --> 01:36:11.960
la aplicación de Journal, que fue anunciada el WDC, la aplicación de diarios, todavía no está

01:36:11.960 --> 01:36:17.480
disponible, ¿vale? Por lo que teóricamente podría llegar en esta versión 17.1, ¿vale? Para los

01:36:17.480 --> 01:36:26.320
usuarios, ¿vale? Pero el tema es ese, ¿vale? Que la versión 17.01, que salió el pasado jueves,

01:36:26.320 --> 01:36:36.040
¿vale? Es una versión que lo que hace es parchear, parchear tres fallos de seguridad más ciertos

01:36:36.040 --> 01:36:42.600
problemas que ha tenido iOS 17 y que son errores de primera instancia, que se resolucionan de una

01:36:42.600 --> 01:36:48.400
forma muy rápida, entre ellos pues también, como ha comentado Arturo, el problema de la versión de

01:36:48.400 --> 01:36:56.280
inicio, que viene preinstalada en los nuevos iPhones, ¿vale? Eso es. Pues Julio, te voy a

01:36:56.280 --> 01:37:03.360
contar ahora una noticia que, bueno, no es noticia, es simplemente una entrada del blog del creador de

01:37:03.360 --> 01:37:10.960
la aplicación que justo hemos estado comentando de Mastodon, IceCubes, ¿vale? Que a mí este señor

01:37:10.960 --> 01:37:18.960
me cae muy bien. Me cae muy bien porque ha cogido y ha dicho que han sacado el nuevo modelo de

01:37:18.960 --> 01:37:26.440
reactividad con las macros, observable y tal. Pues voy a coger, cambio mi aplicación, la hago solo

01:37:26.440 --> 01:37:33.040
disponible para los últimos sistemas y me quedo tan ancho. Y lo que ha hecho es compartir en su

01:37:33.040 --> 01:37:41.400
blog un poco la experiencia, ¿vale? Como tres puntos clave de esta experiencia de migrar la

01:37:41.400 --> 01:37:47.400
aplicación, dice que no ha sido muy complicado, que en un par de horas lo ha tenido... Recordemos que

01:37:47.400 --> 01:37:53.640
es una aplicación de acceso a Mastodon, pero es súper completa. Tiene un montonazo de cosas. Luego

01:37:53.640 --> 01:38:03.880
nos dice que ha solucionado bugs en lugar de crearlos y que el incremento en el rendimiento

01:38:03.880 --> 01:38:12.480
se nota y que merece la pena. O sea, sólo habla de cosas de cosas buenas y positivas y aparte de

01:38:12.480 --> 01:38:19.400
eso que le ha llevado unas pocas horas, ¿vale? La migración. Una de las cosas que pone, que destaca

01:38:19.400 --> 01:38:25.760
es que utilizaba un montón de observable objects, la aplicación, y los pasaba la mayoría de las

01:38:25.760 --> 01:38:36.400
veces como environment object, con lo cual cualquier cambio en una propiedad arroba published, ¿vale?

01:38:36.400 --> 01:38:46.720
Hacía que se redibujaran a todas las vistas, todos los bodies de las vistas que dependían de este

01:38:46.720 --> 01:38:54.360
objeto, con lo cual hacía muchas veces necesario el refresco. Entonces, con este primer cambio,

01:38:54.360 --> 01:38:59.760
pues lo que ha conseguido es que no se refresque tanto. Luego, aparte, ha utilizado bastante,

01:38:59.760 --> 01:39:05.400
porque cuando haces arroba observable, digamos que todas las propiedades que metas dentro no

01:39:05.400 --> 01:39:10.800
le tienes que poner el arroba published, sino que ya son directamente observadas, por así decirlo.

01:39:10.800 --> 01:39:17.200
Entonces, le tienes que decir cuándo no son observadas, ¿vale? Y dice que de esta manera, pues se ahorra un montón de

01:39:17.200 --> 01:39:22.360
refrescos, cosas que antes iban un poco lentas, él lo ha hecho con las herramientas que tiene

01:39:22.360 --> 01:39:28.080
de Instruments Code y ha visto que muchas menos veces que se redibuja, cosas que iban un poco

01:39:28.080 --> 01:39:34.280
lagueadas, ya no lo hace, ¿vale? Sobre todo habla de la página principal, donde está cargando los

01:39:34.280 --> 01:39:40.880
Tooths, se llaman, los Tooths, las publicaciones de Mastodon, que es una vista compleja, con muchas subvistas,

01:39:40.880 --> 01:39:46.200
pues claro, con esta manera sólo se refrescan las vistas que tienen que refrescarse, ¿vale? Cuando

01:39:46.200 --> 01:39:51.920
hay un cambio de un dato, antes decía cualquier cambio, pues refrescaba de repente un montón de

01:39:51.920 --> 01:40:02.360
vistas. Luego dice algo del rendimiento de SubUI, dice que ya simplemente compilándolo

01:40:02.360 --> 01:40:12.000
con el SDK de IOS 17, en lugar de IOS 16, dice que ha cambiado la versión contra la que se compila

01:40:12.000 --> 01:40:22.240
de SubUI y que ya con eso nota bastante el rendimiento, digamos, simplemente por

01:40:22.240 --> 01:40:27.160
compilarlo, porque está compilando contra una nueva librería de SubUI, que en este caso, Apple por

01:40:27.160 --> 01:40:34.480
dentro, aunque no nos cuente, ha hecho varias mejoras. Y luego dice que la migración a este

01:40:34.480 --> 01:40:43.240
framework de observación, ¿vale? hace que sea rápido y habla, pues eso, de que vistas con

01:40:43.240 --> 01:40:54.760
una jerarquía muy grande de vistas, ¿vale? A su vez, pues son bastante más rápidas, dice las columnas,

01:40:54.760 --> 01:41:01.880
o sea, las filas, perdón, que tienen muchas vistas dentro, dependen de estas de estas inyecciones de

01:41:01.880 --> 01:41:07.880
dependencias por environment, no directamente, ¿vale? Pues se nota que muchos menos refrescos y

01:41:07.880 --> 01:41:13.320
que va bastante más rápido. Así que yo me alegro porque todavía he cacharreado, ¿vale? pero todavía

01:41:13.320 --> 01:41:20.880
no me he atrevido a empezar a migrar a algunos desarrollos en los que trabajo, pero bueno, son

01:41:20.880 --> 01:41:26.880
muy buenas noticias. Sobre todo me ha sorprendido la parte, porque lo de esto de que se refrescan

01:41:26.880 --> 01:41:33.720
menos y demás, ya lo sabía, pero la parte está de que ya sólo compilando contra el nuevo framework

01:41:33.720 --> 01:41:43.240
de, o sea, perdón, contra el SDK de iOS 17, ya se nota que SubUI han movido las tripas para hacerlo

01:41:43.240 --> 01:41:49.680
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,

01:41:49.680 --> 01:41:57.520
eso sí. Sí, además he tenido alguna que otra, algún que otro cruce de post, porque ya no se

01:41:57.520 --> 01:42:03.720
llaman tweets, algún que otro cruce de post con él, ¿vale? Claro, este fue uno de los que apostó

01:42:03.720 --> 01:42:09.440
por Mastodon, a las pruebas me remito, pero luego por razones obvias, como todo el mundo, ha ido

01:42:09.440 --> 01:42:15.200
volviendo a Twitter, porque Mastodon, pues, no tiene la... Solamente Steven Troughton Smith es

01:42:15.200 --> 01:42:21.200
el único que sigue ahí, sin querer volver, ¿vale? Debe ser que le tiene demasiada tirria a Elon Musk,

01:42:21.200 --> 01:42:31.280
pero él, al final, ha empezado también a publicar en lo que es Twitter, lo que sería ahora X,

01:42:31.280 --> 01:42:41.120
pues, principalmente por eso, ¿vale? Porque obviamente no tiene la misma incidencia en lo

01:42:41.120 --> 01:42:50.960
que sería su nueva aplicación, ¿vale? Pero, desde luego, lo que cuenta es bastante interesante,

01:42:50.960 --> 01:43:01.280
¿vale? Porque creo que, al final, claro, tener una experiencia como esta, de una aplicación bastante

01:43:01.280 --> 01:43:08.920
importante, bastante grande, en ese sentido, pues, hombre, siempre es bastante curioso, ¿vale? Este

01:43:08.920 --> 01:43:18.080
señor, Thomas Ricouart, ¿vale? Pues eso, tiene en su... Podéis seguirlo como arroba Dimillion,

01:43:18.080 --> 01:43:26.280
¿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

01:43:26.280 --> 01:43:31.880
Cubes, ¿vale? Y contar un poco también, pues, cómo lo ha hecho, tal. Siempre te cuenta un poco todo

01:43:31.880 --> 01:43:36.040
este fregado. Bueno, la aplicación es Open Source, ¿eh? Tienes el código... La aplicación es Open

01:43:36.040 --> 01:43:41.120
Source, efectivamente. Podéis descargaros el código, verlo. Además, es multiplataforma porque

01:43:41.120 --> 01:43:46.480
funciona también en Mac, funciona en iPad, en iOS, ¿vale? Es una auténtica maravilla. De hecho,

01:43:46.480 --> 01:43:50.400
es el cliente de Mastodon que yo tengo instalado, ¿vale? Es el que yo tengo puesto, ¿vale? Y,

01:43:50.400 --> 01:43:57.080
de hecho, es muy gracioso porque, cuando te llega un Tooth, o un Republish de ese Tooth,

01:43:57.080 --> 01:44:03.040
o lo que sea, o un Like, o lo que sea, de Mastodon, se escucha el sonido de unos cubitos de hielo en

01:44:03.040 --> 01:44:08.040
un vaso, ¿no? Clic, clic, clic, ¿no? Porque se llama la aplicación Cubitos de Hielo, ¿no? Entonces,

01:44:08.040 --> 01:44:13.320
pues, la verdad que está, en ese sentido, bastante bien. Y, bueno, pues demuestra que,

01:44:13.320 --> 01:44:18.320
efectivamente, esto es una apuesta importante de Apple, ¿no? Que yo, lo que he estado probando,

01:44:18.320 --> 01:44:24.800
lo realmente interesante de Observable es, precisamente, esto que comenta, ¿vale? Que

01:44:25.920 --> 01:44:32.840
ya no necesitas pasarlo todo a través de los Environment Objects, sino que, como un Observable

01:44:32.840 --> 01:44:38.600
conecta con el siguiente y hace que la vista se refresque, pues, claro, es que ahora es un cambio

01:44:38.600 --> 01:44:43.160
importante, es que ahora puedes tener lógica de los modelos, ¿vale? Es decir, el problema que

01:44:43.160 --> 01:44:50.480
tenía SwiftUI hasta ahora es el uso de los Massive View Model, en este caso, ¿vale? Porque, al final,

01:44:50.480 --> 01:44:58.880
terminabas por tener todo el código de gestión de cada modelo, más todo el código de el tema de,

01:44:58.880 --> 01:45:06.400
pues, de la gestión, ¿no? No solo del almacén, sino de lo que es toda la lógica de negocio,

01:45:06.400 --> 01:45:10.280
la tenías que tener en el View Model, porque si no estaba en el Observable Object, cuando

01:45:10.280 --> 01:45:15.160
actualizabas la fuente de datos, la vista no se actualizaba, ¿vale? Si lo ponías aparte,

01:45:15.160 --> 01:45:21.440
tenías que capturar, o sea, si tú cogías y ponías un Observable Object y dentro de él,

01:45:21.440 --> 01:45:26.640
o sea, ese Observable Object lo instanciabas en otro Observable Object y ese Observable Object

01:45:26.640 --> 01:45:31.360
estaba en la vista, no funcionaba. El primer Observable Object que forma parte del segundo,

01:45:31.360 --> 01:45:36.440
cuando sufre un cambio, la vista no se entera de ese cambio, porque la instancia es del segundo

01:45:36.440 --> 01:45:41.800
Observable Object, no del primero. Tenías que enganchar a través de Combine el Object Will

01:45:41.800 --> 01:45:50.160
Change para que propagara del primer View Model al segundo y que el segundo lanzara el Object

01:45:50.160 --> 01:45:56.560
WillChange.Send para provocar, entonces es un parche, en fin, de aquella manera. Ahora ya no hace

01:45:56.560 --> 01:46:02.200
falta, ahora pones arroba observable y una instancia, arroba observable, puesto como,

01:46:02.200 --> 01:46:07.600
o sea, una clase, arroba observable, puesto como instancia en otra clase, arroba observable,

01:46:07.600 --> 01:46:14.600
cuando yo la pongo en la vista, a través de un State, pues hace que el primer observable,

01:46:14.600 --> 01:46:20.840
al actualizar, propague el cambio y propague el cambio, por lo que puedo tener las lógicas de

01:46:20.840 --> 01:46:27.160
negocio de todos mis datos y los almacenes separados y enganchados a través de un mismo

01:46:27.160 --> 01:46:33.240
View Model. Entonces, claro, el cambio es brutal a nivel de organización, por lo que ahora ciertos

01:46:33.240 --> 01:46:39.480
tipos de datos que sean secundarios no tienes por qué meterlos desde el Environment Object,

01:46:39.480 --> 01:46:44.280
sino que los usas cuando te interese, como una dependencia del View Model de la pantalla que

01:46:44.280 --> 01:46:50.280
estés usando. Y si para una pantalla no necesitas ese dato, no lo recoges y punto, pelota. Y por

01:46:50.280 --> 01:46:55.080
lo tanto, obviamente, tienes muchos menos refrescos inintencionados que no tienen nada

01:46:55.080 --> 01:46:59.800
que ver. Si tú tienes un dato secundario, pero quieres que sea afectado, eso refresca solo tres

01:46:59.800 --> 01:47:04.320
pantallas, tienes 10 y lo enganchas en el Environment Object, un cambio de esa fuente de

01:47:04.320 --> 01:47:08.800
datos va a refrescar las 10 pantallas. Si lo tienes aislado en un observable aparte, pones

01:47:08.800 --> 01:47:13.640
la instancia, si la instancia lo coge, simplemente esas tres pantallas se actualizan y el resto,

01:47:13.640 --> 01:47:20.600
pues no. Es una cosa que, desde luego, es un cambio muy, muy, muy importante y que hace que

01:47:20.600 --> 01:47:27.960
todo sea mucho más sencillo a la hora de manejarlo. Entonces, la verdad que es un cambio, a mí me

01:47:27.960 --> 01:47:34.440
parece maravilloso. La única pega que tiene el cambio es el de siempre. Es iOS 17, porque está

01:47:34.440 --> 01:47:40.280
utilizando la macro arroba observable, está usando una instrucción, porque las macros son

01:47:40.280 --> 01:47:45.360
retrocompatibles. Todas las macros son retrocompatibles hasta la primera versión de

01:47:45.360 --> 01:47:55.400
Swift. Es decir, funcionaría hasta iOS 11. Pero, claro, si tú dentro de la macro metes una

01:47:55.400 --> 01:48:01.480
instrucción que sólo está soportada en X versión, pues entonces ya estás limitando la macro. No por

01:48:01.480 --> 01:48:06.760
la macro, sino por lo que usa la macro. La macro arroba observable está usando una función

01:48:06.760 --> 01:48:14.800
WithObservationTracking, que es una nueva forma de trazar el cambio de una operación o propiedad,

01:48:15.880 --> 01:48:24.520
y eso es iOS 17. Entonces, claro, la hemos fastidiado. Apple tendría que hacer que la

01:48:24.520 --> 01:48:30.280
librería Observation, que es la que la librería de la que forma parte arroba observable, fuera

01:48:30.280 --> 01:48:36.280
retrocompatible y se pudiera instalar en todas las versiones desde iOS 13. En ese momento,

01:48:36.280 --> 01:48:41.320
todo el mundo usaría la nueva arquitectura, todos seríamos más felices y nos olvidaríamos

01:48:41.320 --> 01:48:46.360
de los ObservableObjects, de los ObservedObjects, de los StateObjects, de los EnvironmentObjects

01:48:46.360 --> 01:48:59.480
y de todo lo demás. Pues sí, pero Julio, soñar es gratis, pero que Apple haga lo que sueñes no

01:48:59.480 --> 01:49:07.760
lo es, básicamente. Pues llevamos casi dos horas de programa y no nos hemos concentrado. Es que te

01:49:07.760 --> 01:49:17.240
enrollas que da gusto. A lo mejor no llegamos a lo que prometemos. Yo tengo una noticia más rápida.

01:49:20.200 --> 01:49:26.360
Vale, pues nada, la siguiente noticia es, lo ha publicado en Mastodon, no salimos de Mastodon,

01:49:26.360 --> 01:49:35.480
seguimos en Mastodon, Jen Simmons, que yo creo que es la sheriff en WebKit, que no es a Fanny,

01:49:35.480 --> 01:49:44.200
en WebKit. Y nada, pues ha dicho que hay una nueva versión de Swift Developer Preview,

01:49:44.200 --> 01:49:52.200
que digamos que es la versión anterior que va saliendo el canal beta de Swift, en la que nos

01:49:52.200 --> 01:50:02.240
cuenta que esta nueva versión tiene un 94 de puntuación de compatibilidad, de interoperabilidad,

01:50:02.240 --> 01:50:10.360
mejor dicho. Y por poner un poco de contexto, pues tendríamos que Firefox tiene un 90 en esta

01:50:10.360 --> 01:50:17.760
puntuación y Chrome y Edge, que por debajo tienen Chromium, que es al final lo que importa aquí,

01:50:17.760 --> 01:50:25.320
tienen un 96. Entonces todo esto de que Safari, que patin y patatán, pues naranjas de la China,

01:50:25.320 --> 01:50:36.160
porque Safari de tecnologías, digamos, está muy muy a la par de Chrome y de Edge. Pero

01:50:36.160 --> 01:50:42.640
por qué algunas web apps y algunos servicios no son compatibles? Pues yo creo que viene un poco

01:50:42.640 --> 01:50:50.000
más porque Safari tiene muchos métodos de protección, antirrastreo y demás, que por el

01:50:50.000 --> 01:50:57.160
hecho de que no sea compatible con X servicios. No sé si Julio, si tú tienes otra otra opinión.

01:50:57.160 --> 01:51:02.720
No, no, no, es así. De hecho, se supone que Chromium en breve va a empezar también a hacer

01:51:02.720 --> 01:51:08.960
tareas de obfuscación de privacidad, igual que hace Safari. Y en ese momento veremos a ver lo

01:51:08.960 --> 01:51:14.640
que hacen los desarrolladores. Pero claro, aquí el principal problema es que todo el mundo hoy

01:51:14.640 --> 01:51:20.560
día prueba lo que hace a nivel de web. O sea, los desarrolladores web ya han dicho paso de probar

01:51:20.560 --> 01:51:25.320
en navegadores. Yo pruebo en Chrome y punto. Y si lo quiere la gente en Chrome, pues en Chrome,

01:51:25.320 --> 01:51:31.320
como es el navegador más usado, pues punto pelota. Entonces claro, al final Safari lo sufre. Entonces

01:51:31.320 --> 01:51:35.560
el hecho de que haya este cambio, pues desde luego es importante. Pero sobre todo lo más importante

01:51:35.560 --> 01:51:49.560
es que el tema de la privacidad. Recordemos que Safari lo que hace es obfuscar, impedir que haya

01:51:49.560 --> 01:51:55.880
seguimiento trazado entre distintas webs. Lo que hace Safari es engañar para que esa cookie de

01:51:55.880 --> 01:52:02.120
terceros que te deja Booking.com en tu navegador, para que cuando luego vayas a la web de tal,

01:52:02.120 --> 01:52:08.200
te sugiera el viaje que te has dejado. Porque si tú entras, por poner un ejemplo empírico,

01:52:08.200 --> 01:52:16.200
tú entras en Booking.com y dices quiero irme de vacaciones a, yo qué sé, al rompío en Huelva,

01:52:16.200 --> 01:52:22.000
por ejemplo. Pues si me quiero ir ahí, busco apartamentos. Pues ahora prepárate porque vas

01:52:22.000 --> 01:52:29.480
a estar una semana viendo anuncios de apartamentos en el rompío en toda página puñetera web que

01:52:29.480 --> 01:52:39.720
entres. Claro, porque se han quedado ahí marcados. Entonces con Safari ese cruce de datos no es

01:52:39.720 --> 01:52:46.160
posible. Safari le da un identificador distinto a cada web, por lo que no tienen forma de machear

01:52:46.160 --> 01:52:53.480
los datos y por lo tanto en Amazon o en la web que sea no te va a salir nada. Pero en muchas

01:52:53.480 --> 01:52:59.800
ocasiones, y a mí me ha pasado, tienes que desactivar esa protección de datos cruzados

01:52:59.800 --> 01:53:06.080
porque resulta que están usando esa forma de datos cruzados para que una web funcione.

01:53:07.440 --> 01:53:14.880
Y entonces, claro, pues tienes que quitarlo para que o usar Chrome, que es lo que yo

01:53:14.880 --> 01:53:20.000
normalmente hago. En este caso Chrome, a ver, lo tengo instalado, pero normalmente que suelo

01:53:20.000 --> 01:53:24.680
usar ese Edge. Pero bueno, pues este cambio, desde luego, es interesante.

01:53:26.240 --> 01:53:31.560
Pues sí, pero bueno, quería dejar el mensaje este de que no engañen muchas veces, que dicen

01:53:31.560 --> 01:53:39.960
es que los de Apple vienen con Safari y aquí no hacen nada. A ver, no. Safari es un buen motor.

01:53:39.960 --> 01:53:48.080
¿Qué es mejor o peor que Chrome? Pues ni lo sé, ni creo que probablemente nadie lo sepa,

01:53:48.080 --> 01:53:54.040
porque siempre hacen test de rendimientos, pero seguro que una versión es más rápida que otra

01:53:54.040 --> 01:54:01.000
por X cosa. Luego el otro te adelanta, depende del test que hagas y todas las cosas. Que yo en

01:54:01.000 --> 01:54:06.160
mi día a día, por ejemplo, uso Safari por el tema de la sincronización de cuentas. Pero eso,

01:54:06.160 --> 01:54:13.360
que nos vengan con el cuento de que Safari es peor, es que no soporta porque están muy parejos,

01:54:13.360 --> 01:54:20.640
¿vale? Pero muchas veces el problema es ese, que no pueden hacer este cruce de datos. Entonces,

01:54:20.640 --> 01:54:27.520
pues hay muchas empresas que te lo desaconsejan. De hecho, no me acuerdo, que ya cada vez empiezan

01:54:27.520 --> 01:54:33.640
a funcionar más. Eso sí, hay algunos que te avisan. De hecho, en el programa que estamos grabando Julio

01:54:33.640 --> 01:54:41.000
y yo, yo como soy un outsider, estoy en Safari, pero ahí te avisan. Safari suele dar problemas.

01:54:41.000 --> 01:54:45.960
Pues no lo sé. O sea, me lo creeré, pero a mí no me está pasando.

01:54:45.960 --> 01:54:50.520
Yo, de hecho, como servidor de la conexión en la que está conectado Arturo, ¿vale? Arturo,

01:54:50.520 --> 01:54:56.200
ahora para grabar este podcast, ¿vale? Que seguro que lo oís en Cuonda, ¿vale? Pero

01:54:56.200 --> 01:55:01.120
este podcast también se emite en directo en Twitch, ¿vale? En twitch.tv barrapelcoding.

01:55:01.120 --> 01:55:07.120
Emitimos en directo y estamos aquí, pues en vídeo, los dos charlando, comentando. Luego el

01:55:07.120 --> 01:55:12.760
audio de este directo se posproduce, o sea, se coge el vídeo de este directo, se coge el audio

01:55:12.760 --> 01:55:17.360
que grabamos cada uno por nuestra parte, se posproduce, se deja bonito y con él se hace

01:55:17.360 --> 01:55:23.480
el podcast. Pero la grabación queda en Twitch, ¿vale? Y de hecho podéis estar atentos a lo que

01:55:23.480 --> 01:55:29.720
es el canal de Twitch, twitch.tv barrapelcoding y ahí pues podéis asistir en directo a estas

01:55:29.720 --> 01:55:37.160
grabaciones como están ahora, pues algo más, casi 35 personas ahora mismo en directo viendo cómo

01:55:37.160 --> 01:55:43.920
grabamos, ¿vale? Entonces, para hacer esta unión yo no uso ningún tipo de software como, pues yo

01:55:43.920 --> 01:55:48.560
que sé, alguno que hay por ahí de... no me acuerdo, ¿vale? Los que usa todo el mundo,

01:55:48.560 --> 01:55:54.440
StringArt, ¿no? Y cosas así, ¿vale? No, yo estoy usando aquí una herramienta gratuita,

01:55:54.440 --> 01:56:00.600
abierta, que se llama vvdo.ninja, ¿vale? Que básicamente lo que hace es construir

01:56:00.600 --> 01:56:07.080
una... un servidor web en el que yo le doy una url a Arturo, Arturo se conecta a ese servidor,

01:56:07.080 --> 01:56:14.440
recojo la url de él y como elemento de web lo pego en mi layout de OBS, ¿vale? Y entonces así,

01:56:14.440 --> 01:56:19.160
pues yo me puedo construir mis propios layouts y así es como yo funciono, ¿vale? Entonces el

01:56:19.160 --> 01:56:24.600
servidor ahora mismo está corriendo en Chrome, en mi máquina, pero Arturo, pues como es un poco outsider,

01:56:24.600 --> 01:56:31.960
a pesar de que yo le he dicho, no uses Safari, pues nada, él usa Safari para comprobar que Safari

01:56:31.960 --> 01:56:40.840
también es bueno. Así que bueno, ese sería el tema. Pues como ya llevamos casi dos horas, yo creo

01:56:40.840 --> 01:56:48.680
que lo que vamos a hacer es cerrar con la respuesta a una de las dudas que nos ha mandado uno de

01:56:48.680 --> 01:56:55.880
nuestros oyentes, ¿vale? Y luego en otros sucesivos programas iremos contestando otras dudas que nos

01:56:55.880 --> 01:57:01.000
iráis mandando, ya tenemos un par por ahí almacenadas, pero si queréis enviarnos cualquier duda nueva,

01:57:01.000 --> 01:57:08.840
pues podéis hacerlo a caffe.swift, c-a-f-f-e, swift, arroba gmail.com o a través de nuestro

01:57:08.840 --> 01:57:20.680
x que es caffe.swift, arroba caffe.swift, también con dos f. Y estamos también en Mastodon, ya que

01:57:20.680 --> 01:57:28.440
hemos hablado de Mastodon, ¿vale? También tenemos una cuenta en Mastodon que también podéis citarnos

01:57:28.440 --> 01:57:34.120
ahí, que es la en el servidor de Cuonda, ¿vale? Tenemos lo que es arroba caffe.swift con dos f,

01:57:34.120 --> 01:57:40.480
arroba cuonda.social, ¿vale? Entonces ahí pues también podéis enviarnos cualquier cuestión.

01:57:40.480 --> 01:57:46.920
Así que vamos a ir a esta última parte de las dudas de los oyentes y contestamos esta.

01:57:46.920 --> 01:58:05.600
Y cuéntanos Arturo, ¿de quién es la duda que tenemos? Porque es un viejo conocido, ¿no? De

01:58:05.600 --> 01:58:15.880
ambos. Pues sí, pues es nuestro nuestro amigo Waika, que le mandamos un saludo y un abrazo muy

01:58:15.880 --> 01:58:21.520
fuerte, al que tengo que avisar siempre cuando veo la carrera. Hablo con él de Fórmula 1 y cuando

01:58:21.520 --> 01:58:25.200
veo la carrera de Fórmula 1 tengo que avisar. Cuando no puedo verle, la voy a ver en diferido,

01:58:25.200 --> 01:58:33.960
nos avisamos. Oye, no me dijo antes nada de la carrera. Y nada, a ver si nos vemos. Nos vimos

01:58:33.960 --> 01:58:41.000
los tres la última vez en las J-POD. En las J-POD, sí, efectivamente. Sí, sí. Estuvimos ahí de cháchara

01:58:41.000 --> 01:58:49.640
y la verdad que fue interesante y estuvo estuvo guay, sí, sí. Pues sí, y pues Waika nos cuenta

01:58:54.040 --> 01:59:01.160
qué hacemos. Nos hace así una pregunta, que son varias. ¿Qué hacemos cuando tenemos una

01:59:01.160 --> 01:59:08.600
aplicación de cinco o diez años? De estas que ya tienen polvo encima. Sí, directamente la pasamos

01:59:08.600 --> 01:59:17.720
hasta a SuiteUI. Si la aguantamos y cómo le planteamos al cliente cuál es la mejor manera

01:59:17.720 --> 01:59:24.480
de poner al día o actualizar esta aplicación. Y bueno, si quieres, cuenta tú, Julio, cómo lo

01:59:24.480 --> 01:59:40.000
ves y luego te cuento yo. A ver, yo soy bastante radical. Es decir, yo soy de los que le dicen al

01:59:40.000 --> 01:59:45.840
cliente, mira, esto no... si quieres algo serio, esto lo tienes que refactorizar, ¿vale? Esto no...

01:59:45.840 --> 01:59:52.560
Y si te dicen, no, es que claro, la aplicación, tal, la funcionalidad, no sé cuánta, le dices,

01:59:52.560 --> 01:59:58.520
bueno, pues yo te la mantengo con la versión esta que tienes, incluso en Objective-C, pero que sepas

01:59:58.520 --> 02:00:05.080
que te va a costar mucho más cara, ¿vale? Porque cualquier cosa, mientras sea simplemente ir

02:00:05.080 --> 02:00:12.400
compilando, ¿vale? Y que vayamos probando que las distintas betas que vayan saliendo, ¿vale? Siga

02:00:12.400 --> 02:00:16.920
compilando y siga funcionando y hacer pruebas unitarias de todo y comprobar que todo sigue

02:00:16.920 --> 02:00:21.720
funcionando. Sobre todo, aquí hay una cosa importante a tener en cuenta, que no es lo

02:00:21.720 --> 02:00:28.240
mismo una app de Swift que una app de Objective-C, ¿vale? La app de Objective-C es más fácil que se

02:00:28.240 --> 02:00:35.640
mantenga en el tiempo con menos cambios que Swift, ¿vale? Con Swift, si la aplicación es anterior a

02:00:35.640 --> 02:00:44.080
Swift 4, la cosa empieza a ser compleja y si la aplicación es anterior a Swift 3, entonces tienes

02:00:44.080 --> 02:00:50.160
un lío muy gordo, ¿vale? Porque migrar una aplicación de Swift 1 o 2 a las versiones actuales

02:00:50.160 --> 02:00:57.280
requiere mucho trabajo, ¿vale? Porque depende de hasta dónde llegue la versión, tienes que cambiar

02:00:57.280 --> 02:01:03.560
muchas cosas y, sobre todo, lo más complejo es que los conversores de versiones de Swift están

02:01:03.560 --> 02:01:08.480
en versiones muy antiguas de Scode, ¿vale? Versiones muy antiguas que, además, no vas a poder ejecutar

02:01:08.480 --> 02:01:13.440
en versiones más modernas de los sistemas operativos, por lo que vas a tener que buscarte

02:01:13.440 --> 02:01:19.480
las castañas de un equipo que sea antiguo. Yo, por ejemplo, la última vez que hice esto, tuve que

02:01:19.480 --> 02:01:27.200
hacer una conversión usando mi MacBook Pro que se quedó en... no recuerdo, creo que fue la versión

02:01:27.200 --> 02:01:35.040
anterior a Big Sur, me parece, el MacBook Pro de 2011, que todavía tiene una versión Scode 10 u 11,

02:01:35.040 --> 02:01:43.000
que me permitió hacer la conversión de Swift 1 y 2 a Swift 3, ¿vale? Una vez ya lo tienes en Swift 3,

02:01:43.000 --> 02:01:49.600
ya sí es más simple llevárselo a las versiones superiores, entre comillas. Si te lo puedes llevar

02:01:49.600 --> 02:01:57.680
a Swift 4, mejor, ¿vale? Pero el tema es que, con Swift, insisto, es más complicado por la propia

02:01:57.680 --> 02:02:03.160
evolución que ha tenido Swift y porque, al final, ciertos cambios los tienes que hacer con el

02:02:03.160 --> 02:02:09.400
conversor, ¿vale? En mi caso, repito, si es Objective-C, es más simple porque Objective-C,

02:02:09.400 --> 02:02:18.400
si el código es Objective-C y es muy legacy, curiosamente sigue funcionando bien. Eso sí,

02:02:18.400 --> 02:02:23.080
siempre y cuando no choque con algún bug posterior que tenga la librería, como por ejemplo el que

02:02:23.080 --> 02:02:28.600
hemos comentado al principio, de que de pronto te deje de pintar correctamente los elementos, ¿vale?

02:02:28.600 --> 02:02:35.440
Pero no podemos olvidar que, desde Scode 5, ya se podía usar los Storyboards, ¿vale? Y que,

02:02:35.440 --> 02:02:40.120
también te puedes encontrar proyectos que vengan de versiones mucho más atrás,

02:02:40.120 --> 02:02:45.120
que estén usando X y B, cosa que, a día de hoy, siguen funcionando, ¿vale? Entonces,

02:02:45.120 --> 02:02:50.600
el tema es cuestión de coste y tiempo, ¿vale? Mantener una aplicación de esas características

02:02:50.600 --> 02:02:54.960
supone mucho más coste, supone mucho más tiempo y es cuestión de decirle al cliente,

02:02:54.960 --> 02:03:00.160
mira, esta aplicación no te la voy a poder evolucionar todo lo que tú quieras, no voy

02:03:00.160 --> 02:03:05.640
a poder modernizarla como tú quieras, sólo se puede mantener y que vaya funcionando versión

02:03:05.640 --> 02:03:11.600
a versión y que, si hay cualquier problema, pues se pueda anteceder el problema para ponerla al día,

02:03:11.600 --> 02:03:17.320
¿vale? Entonces, si él decide que no la quiere refactorizar, entonces, pues,

02:03:17.320 --> 02:03:24.880
es simplemente ir manteniéndola y que siga viva. Repito, si es Objective-C, ¿vale? En código legacy.

02:03:24.880 --> 02:03:33.880
Si es Swift, repito, si es Swift 1 o Swift 2, hay que hacer un proceso de migración para que compilen

02:03:33.880 --> 02:03:39.240
las versiones más nuevas porque no podemos olvidar, y esto es algo que hay que tener muy presente,

02:03:39.240 --> 02:03:45.440
que cada nueva versión de macOS prohíbe usar la versión anterior de Scope, como hemos comentado,

02:03:45.440 --> 02:03:55.840
pero en abril del año X Apple obliga a que todas las apps que se suben al App Store estén compiladas

02:03:55.840 --> 02:04:03.440
con la SDK lanzada en septiembre del año anterior, por lo que en marzo-abril de 2024 todas las apps

02:04:03.440 --> 02:04:10.240
van a tener que estar compiladas en la SDK de años 17. En abril-marzo de 2023 todas las apps

02:04:10.240 --> 02:04:15.880
tuvieron que estar compiladas, todas las apps nuevas y antiguas, o sea, nuevas y actualizaciones, tenían

02:04:15.880 --> 02:04:25.880
que estar compiladas con la SDK de, pues eso, con la SDK de años 16, ¿vale? Entonces, claro,

02:04:25.880 --> 02:04:34.480
eso supone que tú quieras o no, si quieres que tu app esté viva a día de hoy en el App Store,

02:04:34.480 --> 02:04:40.280
porque si no Apple te la va a borrar, ¿vale?, porque es código legacy, por lo tanto, si no la

02:04:40.280 --> 02:04:45.280
actualizas Apple te la borra, a mí me lo ha hecho, Apple me ha borrado a mí tres aplicaciones que yo

02:04:45.280 --> 02:04:50.920
ya no actualiceba desde hace varias versiones y me las ha borrado, ¿vale? Me advirtió, me dijo,

02:04:50.920 --> 02:04:56.640
tiene usted seis meses para actualizarla, como no la actualice se la borro, y si la quieres actualizar

02:04:56.640 --> 02:05:03.120
y que esté soportada en las últimas versiones del kit de desarrollo, tienes que coger todo ese

02:05:03.120 --> 02:05:09.080
código y pasarlo. Insisto, si es Obyectives es más fácil, si es Swift hay que hacer obligatoriamente

02:05:09.080 --> 02:05:15.000
una adaptación, que cuanto más atrás sea la versión de Swift, más coste va a tener esa adaptación

02:05:15.000 --> 02:05:20.320
hasta la última versión, ¿vale? De forma que adaptar un código de Swift 1 o Swift 2 pueden

02:05:20.320 --> 02:05:25.760
ser fácilmente dos semanas mínimo de trabajo en una aplicación para dejarla aniquelada y que compile

02:05:25.760 --> 02:05:30.640
sin ningún problema, siempre y cuando no tenga librería de terceros, porque como tenga librería

02:05:30.640 --> 02:05:35.680
de terceros y esa librería de terceros estén obsoletas a nivel de cuando Franco era corneta,

02:05:35.680 --> 02:05:42.840
o sea, olvídate, son meses de trabajo, por lo que llega un momento y dependencias que a lo mejor

02:05:42.840 --> 02:05:47.680
tienes que cambiar porque a lo mejor esa librería dejó de existir hace cinco años y tienes que

02:05:47.680 --> 02:05:52.320
buscar una nueva porque patata, ¿vale? Porque el que sea pues encontró trabajo y no le apetecía

02:05:52.320 --> 02:05:57.840
seguir, ¿vale? Entonces, o cambió a una nueva que hay que implementar desde cero, ¿vale? Por lo

02:05:57.840 --> 02:06:03.920
tanto, es una locura de volverte loco. Así que, al final, ¿qué sucede? Pues que lo más fácil en

02:06:03.920 --> 02:06:09.040
muchos casos, cuando tienes una app que es muy antigua y no hay más forma de actualizarla

02:06:09.040 --> 02:06:14.480
correctamente, pues es decirle al cliente la verdad, es decir, decirle, mira, Apple obliga,

02:06:14.480 --> 02:06:20.840
y aquí te enseño las notas y los correos que manda Apple, a que tú todos los años tienes que cumplir

02:06:20.840 --> 02:06:27.960
la, el que la aplicación se compile con la última versión de Scope y tu aplicación es imposible que

02:06:27.960 --> 02:06:33.320
se compile tal como está estructurada, tal como está hecha en una versión muy antigua de Swift o

02:06:33.320 --> 02:06:41.680
en una versión, pues en este caso, con ciertas librerías de terceros que son, pues, imposibles

02:06:41.680 --> 02:06:47.720
porque habría que usar librerías nuevas o a lo mejor la nueva versión de la librería está usando

02:06:47.720 --> 02:06:54.080
la versión 4 y la actual es la 10, ¿vale? A mí me ha pasado, ¿vale? De usar una dependencia de una

02:06:54.080 --> 02:06:59.960
aplicación que estaba en versión 3 o 4 y la última es la 10 y dices, hostia, entonces, claro, hay

02:06:59.960 --> 02:07:05.880
cambios ahí de código que rompen a nivel de compilación y tienes que refactorizar todo ese

02:07:05.880 --> 02:07:11.480
código de cero. Cuando ya llega un punto en el que ya son meses de trabajo para adaptar esa

02:07:11.480 --> 02:07:17.960
aplicación, sale mucho más rentable borrón y cuenta nueva y hacerla entera en SwiftUI porque SwiftUI

02:07:17.960 --> 02:07:26.400
tardas la mitad de lo que tardarías con UIKit y, pues, le das un nuevo aire a tu aplicación y con

02:07:26.400 --> 02:07:33.360
SwiftUI, una vez ya estás en SwiftUI y en una versión posterior a Swift 5, ¿vale? En el caso

02:07:33.360 --> 02:07:41.280
de Swift hablaríamos a partir de Swift 5.1 y en el caso de SwiftUI a partir de SwiftUI 3 para

02:07:41.280 --> 02:07:47.000
iOS 15, ¿vale? A partir de ahí ya tienes una versión lo suficientemente estable como para

02:07:47.000 --> 02:07:54.360
que el mantenimiento año tras año sea menor y, por lo tanto, sea un coste correctivo normal y

02:07:54.360 --> 02:08:00.160
que la evolución del producto, pues, pueda ser sin ningún problema. Pero, claro, también te vas a

02:08:00.160 --> 02:08:05.920
enfrentar al problema de que ahora vas a estar en iOS 15, por ejemplo, pero dentro de un año te va

02:08:05.920 --> 02:08:11.640
a decir el cliente, pues, o le vas a decir tú, oye, esto tiene que pasar a iOS 16. Entonces,

02:08:11.640 --> 02:08:16.800
¿qué vas a hacer? ¿Vas a meter los navigation stack en vez de los navigation views? O si te pide

02:08:16.800 --> 02:08:21.160
algo que tenga que ver con los navigation stack, entonces te peleas para que te deje subir a la

02:08:21.160 --> 02:08:28.000
16. Ahí ya te peleas con SwiftUI y con la puñetera de que aún no sea totalmente retrocompatible,

02:08:28.000 --> 02:08:36.080
¿vale? Entonces, bueno, pues eso sería un poco la respuesta corta. No, a ver, la verdad es que yo

02:08:36.080 --> 02:08:42.240
haría prácticamente lo mismo que os he dicho, pero hay que separar un poco primero el código y luego

02:08:42.240 --> 02:08:49.680
el framework. Serían las dos partes a estudiar. Sí que es verdad que emigrar Swift de determinadas

02:08:49.680 --> 02:08:55.640
versiones es un poco rollo, pero bueno, también la propia UIKit. Yo hace poco también me mandó

02:08:55.640 --> 02:09:00.480
a Apple en uno de esos correos de, oye, esta aplicación la tienes que actualizar. Y pues le

02:09:00.480 --> 02:09:07.800
eché un rato y vi que no me merecía la pena porque necesitaba bastante trabajo. Y luego hace un año

02:09:07.800 --> 02:09:13.760
también me pasó con otra aplicación que tengo y ahí lo que hice fue pues cargarme las dos vistas

02:09:13.760 --> 02:09:20.440
que me daban problemas y pasarlas a SwiftUI. ¿Qué es lo bueno? Que es interoperable. Entonces puedes

02:09:20.440 --> 02:09:27.080
ir paso a paso o mirar a ver dónde te trabas o dónde ha dejado de funcionar. Necesitas cambiarlo

02:09:27.080 --> 02:09:33.040
sí o sí y hacerlo. Pero bueno, la recomendación primera es cosas tan, tan antiguas y sobre todo

02:09:33.040 --> 02:09:38.200
sin mantenimiento. Lo de siempre es lo de, entonces me estás diciendo que una aplicación cada año

02:09:38.200 --> 02:09:43.880
tengo que cambiarla. No, cada año sí que hay que hacerle un pequeño mantenimiento para que no pasen

02:09:43.880 --> 02:09:50.640
cinco años y en esos, o sea, y al quinto año el mantenimiento sea horrible. Hay que ir pasito a

02:09:50.640 --> 02:09:57.160
pasito. Por eso estaban los asistentes de migración que había en su día, que te facilitaban la tarea,

02:09:57.160 --> 02:10:03.960
pero el problema era cuando lo dejabas muchos años sin, sin tocar. Y sí que es verdad. Las

02:10:03.960 --> 02:10:08.720
aplicaciones, y ya si es algo híbrido ya ni te cuento, pero bueno, quitando las híbridas, las

02:10:08.720 --> 02:10:17.040
aplicaciones nativas, sí que es verdad que hay que darles un vistazo. Y esto ya lo cuento a la gente

02:10:17.040 --> 02:10:23.920
que pide los servicios de desarrolladores para esto. Sí que es verdad que merece la pena. Si tú

02:10:23.920 --> 02:10:28.560
tienes una aplicación, no quieres cambiar, la funciona bien y tal, oye, sí que te merece la

02:10:28.560 --> 02:10:32.960
pena que cuando vaya a llegar la fecha de las nuevas versiones, oye, que hables con algún

02:10:32.960 --> 02:10:38.720
desarrollador y le digas, oye, ¿me puedes echar un vistazo a la aplicación? Porque probablemente te

02:10:38.720 --> 02:10:45.680
salve de problemas si dentro de medio año vas a querer añadirle algo o dentro de más tiempo,

02:10:45.680 --> 02:10:52.880
probablemente te salve de problemas haber dado ese paso anterior y luego te ahorrará dinero. O sea,

02:10:52.880 --> 02:10:58.080
a la larga te ahorrará dinero. Y como, porque también sí que es verdad que hay como un poco

02:10:58.080 --> 02:11:03.640
esa, y yo creo que el problema tiene las consultoras, que lo que quieren obviamente sacar máximo dinero

02:11:03.640 --> 02:11:07.840
a los clientes, algunas, perdón, porque siempre hablo así en general, algunas consultoras que lo

02:11:07.840 --> 02:11:14.800
quieren sacar dinero a toda costa de todos los proyectos y que siempre parece que está todo mal,

02:11:14.800 --> 02:11:21.480
que te voy a borrar todo. No, es que la mayoría de las veces, si es código muy antiguo, sí merece la

02:11:21.480 --> 02:11:31.120
pena el borrar ciertas cosas porque te va a salir mejor y no merece la pena enrocarse en estar

02:11:31.120 --> 02:11:36.440
poniendo parche sobre parche, porque a mí me ha pasado en muchos proyectos de, oye, estamos con

02:11:36.440 --> 02:11:43.280
este, yo qué sé, un componente X, estamos poniendo parche sobre parche y nos ha llevado, me lo invento,

02:11:43.280 --> 02:11:49.640
20 horas. Joder, es que a lo mejor en 20 horas hubiésemos tirado lo que había, hecho algo nuevo,

02:11:49.640 --> 02:11:57.920
bien testado, con test unitarios, con test de integración, utilizando async await, utilizando

02:11:57.920 --> 02:12:03.320
herramientas avanzadas, y es que a lo mejor, incluso voy más allá, a lo mejor no me lleva 20

02:12:03.320 --> 02:12:10.440
horas sino que me lleva 25, pero los cimientos que tengo para que eso vaya creciendo son mucho

02:12:10.440 --> 02:12:17.960
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

02:12:17.960 --> 02:12:22.880
paso a paso, por lo que te comentaba el otro día, que había en Scope 15 hay algo que me crasea la

02:12:22.880 --> 02:12:30.280
aplicación y que no tengo manera de preverlo, que es un fallo, pero esos fallos se dan. Entonces,

02:12:30.280 --> 02:12:36.280
si vas saltando versión a versión, eso imaginaros que esto ha sido en esta versión, pero bueno,

02:12:36.280 --> 02:12:42.800
en la primera vez que salta ya lo ves, no lo ves con dos o tres versiones de decalaje que tienes

02:12:42.800 --> 02:12:47.120
cuatro errores de este tipo que de repente te explota la aplicación y no sabes dónde. Así

02:12:47.120 --> 02:12:55.360
que yo siempre, y bueno, hace un tiempo que no trabajo en plan en un proyecto y cobrando un

02:12:55.360 --> 02:13:02.680
mantenimiento, pero sí que está bien eso de, pues bueno, ya según sea el profesional, pues los hay

02:13:02.680 --> 02:13:09.120
más honestos y menos, pero un mínimo de mantenimiento siempre recomendable para la aplicación.

02:13:09.120 --> 02:13:14.440
Yo es algo que siempre pongo en todos mis proyectos, ¿vale? Creo que lo que ha dicho

02:13:14.440 --> 02:13:24.360
Arturo es absolutamente, absolutamente clave, ¿vale? Que todas las apps tienen que tener un

02:13:24.360 --> 02:13:31.600
mantenimiento anual de revisión con las nuevas versiones de Scope y dejar funcionando tu

02:13:31.600 --> 02:13:39.640
aplicación con la nueva SDK. Si no hacemos eso en septiembre, octubre, podemos tener serios

02:13:39.640 --> 02:13:48.000
problemas porque, por ejemplo, el error que se ha encontrado Arturo con la SDK de iOS 17 es un

02:13:48.000 --> 02:13:55.400
error de cuelgue de las apps absoluto. Es decir, alguno diría, hombre, es un error de Scope 15,

02:13:55.400 --> 02:14:01.920
¿no? Perfecto, pero ¿qué es lo que pasa? Que si tus usuarios actualizan a iOS 17, ya no van a

02:14:01.920 --> 02:14:08.160
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

02:14:08.160 --> 02:14:13.720
Scope y que se cuelga la aplicación, le va a pasar a todos los usuarios que se descarguen

02:14:13.720 --> 02:14:23.960
la aplicación teniendo iOS 17 con el binario de la versión anterior. Por lo tanto, tu app va a crasear.

02:14:25.080 --> 02:14:28.920
Y ojo, vamos a poner una nota positiva que le hemos comentado en el programa.

02:14:30.440 --> 02:14:35.480
En la aplicación de Ice Cube decía que solo por el hecho de compilarlo con la última versión

02:14:35.480 --> 02:14:40.640
del SDK hacía que fuese más rápido porque compilaba contra versiones nuevas de las

02:14:40.640 --> 02:14:46.560
librerías en las que se han mejorado cosas. Claro, porque optimiza ya no sólo eso,

02:14:46.560 --> 02:14:52.440
sino que optimiza el código intermedio que genera Swift, ¿vale? Y entonces, pues ese

02:14:52.440 --> 02:14:58.240
código intermedio, lógicamente, los enlaces son más óptimos, la integración con C++ también ha

02:14:58.240 --> 02:15:04.480
permitido, porque una de las cosas que hacen que las nuevas versiones de iOS, Mac, etcétera,

02:15:04.480 --> 02:15:11.960
funcionen mucho más fluidas es la reducción de la constante traducción de tipados entre Objective-C,

02:15:11.960 --> 02:15:19.040
C y Swift, ¿vale? Porque cuando tú tienes un tipo en Swift y tienes que pasar eso a Objective-C o a C,

02:15:19.040 --> 02:15:23.840
y luego de Objective-C a C volverlo a Swift, y luego de Swift volverlo otra vez a C porque

02:15:23.840 --> 02:15:33.800
tienes una capa de abstracción que va y viene en distintos lenguajes, todo eso es muy costoso.

02:15:33.800 --> 02:15:42.080
El encontrar las equivalencias y las inferencias, etcétera, por lo que el trazado que tiene hace

02:15:42.080 --> 02:15:47.560
que todo vaya más lento. Todo eso ahora se ha optimizado y hace que todo funcione mucho mejor.

02:15:47.560 --> 02:15:54.040
Entonces, lo peor que puedes hacer, porque va a ser un problema muy gordo para ti,

02:15:54.040 --> 02:16:01.120
es dejar una app abandonada durante años, ¿vale? Porque entonces ahí es donde tienes el problema,

02:16:01.120 --> 02:16:07.720
donde yo he explicado todo ese proceso, ¿vale? Que parte de una premisa en la que te cae una

02:16:07.720 --> 02:16:13.080
aplicación que no se ha actualizado desde no sé cuántos años, ¿vale? Y por lo tanto,

02:16:13.080 --> 02:16:18.840
pues a echarla a andar en las versiones nuevas es tal. Si esa aplicación, sea Objective-C,

02:16:18.840 --> 02:16:25.360
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,

02:16:25.360 --> 02:16:31.360
y se ha ido probando año tras año, y se ha ido compilando con la versión SDK de las nuevas

02:16:31.360 --> 02:16:37.880
versiones, da igual que la aplicación tenga un código de hace 10 años. Ya lo tienes compilado

02:16:37.880 --> 02:16:44.960
en la última versión, por lo que el mantenimiento, como es progresivo, va a ser mucho menos costoso,

02:16:44.960 --> 02:16:50.840
y esa aplicación de un código de hace 10 años podrá seguir dando servicio durante otros años

02:16:50.840 --> 02:16:56.200
más sin ningún problema, y no habrá que refactorizarla. Cuando se plantea el que hay

02:16:56.200 --> 02:17:01.960
que refactorizar, es cuando coges una aplicación que hace 5, 6, 7 años que no se ha tocado,

02:17:03.320 --> 02:17:08.440
y por lo tanto, sigue en versiones antiguas, y ahora se quiere poner al día. No. Entonces,

02:17:08.440 --> 02:17:11.800
ahora ya se complica. ¿Vale? Esa es la diferencia, creo yo.

02:17:11.800 --> 02:17:20.880
Sí, sí. Exactamente, la verdad. Y eso, Waika lo pone desde que está en nuestro punto,

02:17:20.880 --> 02:17:28.600
de cómo se lo cuentas al cliente, pero bueno, yo siempre digo que está bien que los clientes

02:17:28.600 --> 02:17:37.960
sepan un poco de esto, porque sí que es verdad que hay gente mala ahí fuera. Se ha abusado mucho.

02:17:37.960 --> 02:17:44.120
Yo hace años que no trabajo directamente con estos proyectos, pero cuando trabajé en su día,

02:17:44.120 --> 02:17:51.720
venía muchísima gente rebotada, muchísima gente que decía, no, es que miran el proyecto y ya me

02:17:51.720 --> 02:17:58.160
van a cobrar no sé cuánto ya solo por abrirlo, aunque no haya que tocarlo. Bueno, eso se puede

02:17:58.160 --> 02:18:03.440
hablar. Está claro que no va a ser gratis, porque abrir un proyecto lleva tiempo, y ver el alcance

02:18:03.440 --> 02:18:09.520
de los cambios de un proyecto lleva tiempo. Hombre, ¿te cuento el último que hicimos tú

02:18:09.520 --> 02:18:19.040
y yo? Bueno, todavía la versión de Android tenía un pase, según comentaste.

02:18:19.040 --> 02:18:24.600
Julio, no cuentes que hago Android. Pero solo en ocasiones.

02:18:24.600 --> 02:18:33.720
Me lavo las manos, además, antes de tocar. Y luego lavas el teclado al abrir Android Studio y tal.

02:18:33.720 --> 02:18:44.120
Pero si estamos hablando de la versión que había en Apple, yo le tuve que cobrar horas de trabajo

02:18:44.120 --> 02:18:52.160
a este cliente, que si no me equivoco creo que al final cobramos 20 horas entre los dos o por ahí,

02:18:52.160 --> 02:18:58.560
no recuerdo ahora mismo. Pero vamos, fue una cantidad de dinero importante solo por abrir

02:18:58.560 --> 02:19:03.000
la app y ver lo que hay dentro. Porque claro, esto es algo que tú no has hecho. Entonces,

02:19:03.000 --> 02:19:09.680
esta aplicación tenía cerca de 20 dependencias de terceros, de volverte loco. Y eres como,

02:19:09.680 --> 02:19:14.200
pero bueno, pero de verdad, pero que si es una aplicación de cuatro pantallas, ¿dónde va? Con

02:19:14.200 --> 02:19:20.160
más de mil líneas de código, decenas de ficheros, no sé qué. Había montado ahí un Jirigai,

02:19:20.160 --> 02:19:28.200
una infraestructura de traducción de los textos cuando la aplicación estaba solo en inglés. Era

02:19:28.200 --> 02:19:36.040
una cosa como, pero tú estás loco. Yo creo que es lo peor que yo me he topado en mi vida. El mayor

02:19:36.040 --> 02:19:41.760
desastre de proporciones épicas que lo que hacía era que aquello ni era SwiftUI ni era nada. Aquello

02:19:41.760 --> 02:19:48.400
era un destrozo hecho por alguien que lo que había cogido era SwiftUI y lo había convertido en otra

02:19:48.400 --> 02:19:56.680
cosa que para él era más cómoda. Lo peor que he visto en mi vida. Y claro, pues simplemente el

02:19:56.680 --> 02:20:03.080
levantar y el ver cómo funcionaba aquello, obviamente tuvo un coste. Entonces, depende

02:20:03.080 --> 02:20:09.320
mucho. Cuando tú quieres dar soporte a una aplicación que no es tuya, lo primero que

02:20:09.320 --> 02:20:20.280
tienes que hacer es acceder a ese código fuente y poder validar qué te supone levantar esa

02:20:20.280 --> 02:20:25.440
aplicación. Ver cómo esa aplicación está hecha, ver qué dependencias tiene, ver cuál es el gestor

02:20:25.440 --> 02:20:30.200
de dependencias que tiene, porque en este caso por lo menos estaba usando SwiftPack y Manager,

02:20:30.200 --> 02:20:34.880
no usaba CocoaPods. En otras ocasiones yo me he encontrado proyectos con CocoaPods que han

02:20:34.880 --> 02:20:40.160
sido como un infierno. De hecho, yo con uno de los últimos clientes que tuve, no hace demasiado,

02:20:40.160 --> 02:20:45.440
al final lo que le convencí fue para que quitara CocoaPods y lo pasara todo a SwiftPack y Manager.

02:20:45.440 --> 02:20:52.080
Y al final se hizo y eso pues es una ventaja que él cogió. Por lo que aquí, como digo,

02:20:52.080 --> 02:21:00.200
el primer coste que tienes que asumir es el levantamiento de la aplicación. Y eso puede

02:21:00.200 --> 02:21:07.000
ser fácil, dependiendo de cómo esté hecha la aplicación o no, semanas de trabajo para levantar

02:21:07.000 --> 02:21:12.720
y entender cuál es la arquitectura, cómo está estructurada, cómo se conectan las clases,

02:21:12.720 --> 02:21:20.440
cómo está montada a nivel general, etcétera. Y cuanto más se aleje de lo nativo, peor en todos

02:21:20.440 --> 02:21:26.920
los sentidos. Y ya una vez tienes la aplicación levantada y ya sabes qué es lo que tiene y de

02:21:26.920 --> 02:21:33.080
qué pie cojea y qué cosas tienes que hacer, pues ya tendrás que presupuestar lo que tú

02:21:33.080 --> 02:21:39.040
consideres que sea el tiempo necesario para ponerla al día, para que puedas compilar y

02:21:39.040 --> 02:21:45.080
ejecutar en el actual sistema operativo y en la última SDK con Scope. Y luego ya a partir de ahí,

02:21:45.080 --> 02:21:51.800
si quieren meter cosas, pues tendrás que valorar el trabajo. Eso es que a veces te dicen, no,

02:21:51.800 --> 02:21:58.360
si sólo quiero meter este botón, ya claro, pero para arrancarte el proyecto con ese botón de

02:21:58.360 --> 02:22:03.360
esa aplicación que hace dos años que no tocas, pues es que es un maldito infierno y no...

02:22:04.640 --> 02:22:11.320
En esta última, porque nos decían eso, es que quiero meter un botón, pero es que para meter

02:22:11.320 --> 02:22:18.320
ese botón tengo que averiguar cómo esta arquitectura, que no es SwiftUI, mete un botón.

02:22:18.320 --> 02:22:25.240
Porque aquí estaba usando patrones setter getter, constructores de no sé qué, botones de no sé

02:22:25.240 --> 02:22:30.240
cuántas... No era poner botón y luego una llamada, no, no, no, no, no. Estaba montado sobre una

02:22:30.240 --> 02:22:35.680
arquitectura que era una auténtica basura, que para tocar cualquier cosa había que pasar por

02:22:35.680 --> 02:22:42.440
7, 8, 9, 10 clases de pendiente, ir de una en otra, saltar de un lugar a otro y luego todo

02:22:42.440 --> 02:22:48.360
controlado por una librería de terceros llamada navigation stack, que tenía que ser la responsable de

02:22:48.360 --> 02:22:54.480
todo el flujo de navegación porque no usaba la navegación nativa, porque era una librería que

02:22:54.480 --> 02:23:05.640
estaba poniendo por detrás gestiones de push y pop a través de UIKit. Entonces, claro,

02:23:05.640 --> 02:23:14.240
era un puñetero infierno. Claro, no es cuestión de poner un botón, es cuestión de cómo se pone

02:23:14.240 --> 02:23:20.680
un botón con esta mierda que ha hecho aquí el que sea, que para él será muy cómodo. Pero claro,

02:23:20.680 --> 02:23:25.280
yo no tengo un manual de instrucciones de cómo se puede poner un botón con la basura esta que

02:23:25.280 --> 02:23:31.480
me han dado. Entonces, pues claro, meter las manos en la basura no es fácil ni cómodo.

02:23:31.480 --> 02:23:39.280
Lávatelas como yo cuando acabo con Andrés. Básicamente, básicamente. Pues no sé,

02:23:39.280 --> 02:23:45.680
algo más que aportar al respecto. No, yo creo que la verdad que hemos contado un

02:23:45.680 --> 02:23:53.920
poquitillo a raíz de la pregunta de Waika el tema y sobre todo, ya te digo, yo creo que hemos

02:23:53.920 --> 02:24:00.200
dejado claro tanto de la parte de cliente como del profesional al que están contratando,

02:24:00.200 --> 02:24:07.040
que al final hay que ser honesto, pero las cosas valen lo que valen. Yo creo que es el resumen.

02:24:07.040 --> 02:24:15.640
Sí, básicamente. Y que desde luego aprendan la lección de que no se puede dejar ningún desarrollo,

02:24:15.640 --> 02:24:24.400
ya no hablamos de Apple, ¿de acuerdo? Ningún desarrollo hay que dejarlo ahí y esperar que

02:24:24.400 --> 02:24:33.520
siga funcionando, porque tal como funcionan hoy día los sistemas, no. Entonces, al menos una vez

02:24:33.520 --> 02:24:39.440
al año, cuando hay una nueva versión de lo que sea, hay que ir revisando, comprobando que todo

02:24:39.440 --> 02:24:44.240
está bien, que cada cosa está en su sitio, todo tiene que tener, todo proyecto tiene que tener

02:24:44.240 --> 02:24:52.360
como mínimo, mínimo, mínimo, mínimo, mínimo, un presupuesto destinado a un mantenimiento correctivo

02:24:52.360 --> 02:24:59.680
anual basado en los ciclos de vida de las herramientas con las que está hecho. Y a ver,

02:24:59.680 --> 02:25:04.280
si hablamos de web, pues imagínate, ¿vale? No hay nada peor en este mundo que, yo que sé,

02:25:04.280 --> 02:25:09.920
por ponerte un ejemplo radical, ¿vale? Montarte un WordPress, pones una página web y la dejas ahí.

02:25:09.920 --> 02:25:15.040
Pues hostia, cuando empiezan a salir versiones de WordPress nuevas, empieza a subir la versión de

02:25:15.040 --> 02:25:20.360
PHP, empieza no sé qué, ahora tú dile a alguien que trabaja con WordPress que coja una web que se

02:25:20.360 --> 02:25:25.840
hizo en WordPress hace siete años y que la ponga al día con todos los plugins que han metido ahí

02:25:25.840 --> 02:25:34.120
para eso. O sea, se te suicida. Pues te voy a decir una cosa, tengo, bueno, es que me he encontrado con

02:25:34.120 --> 02:25:41.200
un proyecto con WordPress, pero que encima está metido por FTP en el servidor, que bueno, bueno,

02:25:41.200 --> 02:25:46.600
una magia, una magia me he encontrado ahí, pero es que a lo mejor me tienen una semana intentando

02:25:46.600 --> 02:25:52.440
averiguar dónde estaba ese WordPress y porque tampoco sabía dónde estaba la web y me dio por

02:25:52.440 --> 02:26:00.080
poner el barra wp barra guionadmin y dije, ah, vale, es un WordPress, porque no sabía ni cómo estaba

02:26:00.080 --> 02:26:09.000
hecha la web. De un proyecto abandonado. De un proyecto abandonado, que además no podemos olvidar

02:26:09.000 --> 02:26:15.760
que WordPress, por terminar el ejemplo, es el CMS más utilizado en web y lógicamente también es el

02:26:15.760 --> 02:26:22.160
más atacado, por lo que o vas parcheando cualquier tipo de problema de seguridad o te arriesgas a que

02:26:22.160 --> 02:26:29.920
te secuestren la web y empiecen a ponerte ahí lo que les dé la gana, desde venta de criptomonedas

02:26:29.920 --> 02:26:38.200
falsas hasta ponno o lo que sea menester. Y nada, pues yo creo que ha quedado claro,

02:26:38.200 --> 02:26:45.280
lo sentimos. El próximo día haremos otro programa de respuesta a preguntas donde realmente respondamos

02:26:45.280 --> 02:26:50.680
a vuestras preguntas, pero podéis hacernos llegar más preguntas al correo, podéis hacernos...

02:26:50.680 --> 02:26:58.560
¿Qué es? Ay, se me ha ido el correo. Cafésuif arroba... ¿Cafésuif podcast?

02:26:58.560 --> 02:27:10.240
No, Cafésuif arroba gmail.com, a Twitter, a Mastodon, arroba Cafésuif en x, perdón,

02:27:10.240 --> 02:27:24.080
y arroba Cafésuif arroba uonda.social. Y nada, yo creo que no nos liamos más y vamos con la despedida.

02:27:24.080 --> 02:27:44.080
Pues poco más, básicamente. Muchísimas gracias por escucharnos, espero que hayáis aprendido algo

02:27:44.080 --> 02:27:55.040
nuevo. Ya sabéis que podéis encontrarme a mí en x como arroba jcfmunoz, en Mastodon como jcfmunoz,

02:27:55.040 --> 02:28:06.520
Mastodon.social, en BlueSky jcfmunoz arroba como es bsky... no sé qué, ni idea.

02:28:06.520 --> 02:28:16.120
Yo es que tengo BlueSky desde hace poco y solo es... a veces cuando grabamos y veo que publicas

02:28:16.120 --> 02:28:23.440
y luego Alex Barredo tiene, y sí que está todo el día ahí, pero la verdad es que entro poquito.

02:28:23.440 --> 02:28:33.840
Igual, pues mira, efectivamente es jcfmunoz.bsky.social, ese sería en BlueSky, BlueSky es

02:28:33.840 --> 02:28:44.080
el Twitter del antiguo dueño de Twitter. Y luego el resto igual, podéis encontrarme como jcfmunoz,

02:28:44.080 --> 02:28:52.400
de hecho las dos redes donde estoy más activo es en x y también en Linkedin,

02:28:52.400 --> 02:29:04.080
linkedin.com barra in barra igual jcfmunoz. No obstante, podéis encontrar toda mi información en

02:29:04.080 --> 02:29:09.520
mypublicinbox, si entráis en mypublicinbox barra jcfmunoz, pues tenéis ahí toda la información,

02:29:09.520 --> 02:29:15.320
todas las redes, todo donde estoy y así podéis seguirme en ellas. Por la calle no, pero en

02:29:15.320 --> 02:29:20.400
cualquier red podéis seguirme sin problema. ¿Y dónde puede encontrarte la gente a ti, Arturo?

02:29:20.400 --> 02:29:26.680
Pues a mí donde más estoy también es en nx.arturoribasa, en Mastodon,

02:29:26.680 --> 02:29:36.480
arturoribasa.mastodon.cloud. En Linkedin también es arturoribasa. Y luego en mi otro podcast,

02:29:36.480 --> 02:29:44.600
que es Vidas Digitales, donde somos algo menos cafeteros. Y bueno, podéis encontrar toda la

02:29:44.600 --> 02:29:51.040
información sobre mí en www.arturorribas.com. Así que lo dicho, muchísimas gracias a todos por

02:29:51.040 --> 02:29:56.480
estar ahí estas más de dos horas de programa, donde espero que hayáis aprendido un montón de

02:29:56.480 --> 02:30:04.000
cosas y nos oímos pronto si Dios quiere. Y hasta entonces, pues ya sabéis que lo que tenéis que

02:30:04.000 --> 02:30:11.280
hacer, la mejor manera de aprender a programar, a depurar, a ser mejores programadores, es jugar

02:30:11.280 --> 02:30:18.080
con el código. Así que nos vemos en la próxima. Chao. Chao.

02:30:41.280 --> 02:30:59.080
Puedes escuchar más episodios en cuonda.com, la comunidad de podcasts independientes en español.