El iPad mini se pasa a OLED y A20 Pro 📱💧 Lo que nos importa como devs: hasta 4,5× en IA para Foundation Models en local, modo oscuro con negros reales, más uso en horizontal y Liquid Glass ajustable de cristalino a tintado 👀

Xcode 27.2 ya está en Release Candidate 🛠️

🏁 Abiertas las inscripciones para la 2ª edición del Swift Agentic Program. La primera reunió a 60 desarrolladores y agotó plazas. Esta vez vamos a “liquidificar” una app existente y adaptarla al iPhone Duo con IA: revisar la interfaz, adaptarla y verificar el resultado. Con los SDK 27 ya no hay modo de compatibilidad con el diseño anterior, así que la idea es llegar a abril de 2027 con los deberes hechos. También automatizamos las capturas: tests de UI generados con IA que recorren la app, capturas reales y composiciones para el App Store en varios idiomas. Además, todo lo de la WWDC: Xcode 27 con /plan y MCP nativo, Core AI, Siri AI y OpenClaw. 📅 30 nov – 17 dic · 19:00–22:00 (España) 💻 Online en directo · 30 h

Bienvenidos a la nueva AC Academy. Adiós Wordpress: HTML+CSS y apenas Javascript. Más moderna, 100% accesible WGAC 2.0 AA. Toda nuestra información, formaciones y un tip real de código cada vez que entras. Catálogo de particulares y empresas. ¿Qué te parece?

Tu app ya funciona en el iPhone Duo ⚠️ pero no significa que se vea bien. Desde el 23 de octubre Apple acepta apps preparadas para la pantalla plegable del iPhone Duo. Pero OJO, ten en cuenta que con la llegada de la pantalla plegable, se rompen varias suposiciones que llevamos años metiendo en el código. Échale un vistazo antes de publicar algo que funciona pero no se ve bien y no aprovecha las ventajas del dispositivo.

🏆 ¡Ya tenemos ganadores de la ACoding Hackathon 2026! 🇪🇸 Hispanohablante: Rail, de Juan Salguero Ibarrola y Desirée Rodríguez Macías 🚆 Los horarios de Cercanías Málaga siempre a mano, incluso sin cobertura, con los trenes en tiempo real sobre el mapa y widgets con tus estaciones favoritas. 🌍 Internacional: TinyStory, de Du Cheng Historias interactivas que se juegan desde el widget de la pantalla de inicio: cuatro decisiones, cuatro finales posibles y una pequeña aventura en cada partida. Elegir no ha sido nada fácil. El nivel de esta primera edición ha sido muy alto: arquitecturas cuidadas, interfaces pulidas y apps que resuelven problemas reales. Y todo ello sin una sola librería de terceros, solo con Swift, SwiftUI y el SDK de Apple. Esto demuestra que, cuando entiendes las herramientas nativas, no necesitas nada más para crear apps que funcionen bien de verdad 🤝🏆

🤯 ¡Tu app deberá estar adaptada al iPhone Duo en abril de 2027 de manera obligatoria! Así nos lo ha hecho saber Apple anunciando que ya podemos enviar las versiones adaptadas al nuevo dispositivo de Apple con la publicación de la versión RC de Xcode 27.1. 🤔 En primavera de 2027 (como suele ser habitual) será obligatorio usar la SDK de iOS 27 y Xcode 27 para enviar apps. Pero parece que Apple podría subir el escalón a la 27.1 como obligatoria este año. Según hemos podido saber por la guía publicada para que los developers podamos tener lista nuestra app para el nuevo Duo, Apple obligará a poner los screenshots de cómo se ve nuestra app en el Duo dentro de App Store Connect. 📲 Así que, por si no habéis hilado las obligaciones, para primavera de 2027 (probablemente inicios de abril, más o menos) nuestra app deberá integrar OBLIGATORIAMENTE toda su UI adaptada a Liquid Glass ya que no se podrá deshabilitar como hasta ahora con Xcode 26 y se activará por sí sola. Y además, que se vea de manera correcta en los iPhone Duo. 🛠️ Apple ha publicado en Xcode 27.1 una serie de skills que si nuestra app es nativa, bastará pedirle al nuevo modo agente de Xcode que adapte nuestra app para el Duo y hará lo necesario para una primera adaptación que pudiera pasar la criba y nos permitiera publicar. Pero si queremos dar funcionalidad específica, tendremos que trabajar más con ello. Os dejamos la guía de Apple en el primer comentario. 🫠 ¿Qué? ¿Qué os parece esto? ¿Bien que Apple obligue a todos los developers? ¿Cuántos cambios tendrás que hacer en tu app? ¿Está ya preparada? ¿Será complicado? Te leo.

"Usar agentes en Xcode" no es "pedirle a la IA que programe." Hoy vamos a estar en directo con @jcfmunoz construyendo una app desde cero con los agentes de Xcode 27. Spoiler: el criterio técnico sigue siendo tuyo, no del agente 😉 youtube.com/watch?v=XRQhuSar…

El próximo lunes, nuestro primer directo de la temporada 26/27... y no podía ser otro que sacarle el máximo provecho a Xcode 27 y no su nuevo modo de trabajo basado en agentes. Activa la campanita para que Youtube te avise: youtube.com/live/XRQhuSarPtc…

🤯 Apple lanza Xcode 27.2 beta 1. Sí, has leído bien ¿Y la 27.1? Ni está ni se la espera… al menos en beta. Y tiene todo el sentido del mundo. 📱 Xcode 27.1 no va a tener betas. Llegará a finales de mes directamente como versión final y con soporte para iPhone Duo. ¿El motivo? iOS 27.1 es el sistema con el que se estrena el Duo y su código está plagado de referencias al dispositivo. Una beta pública sería regalarle el pastel a todo el que destripa binarios buscando filtraciones. Así que Apple se lo guarda y nos da ya la 27.2, que saldrá en octubre. 🗣️ ¿Qué trae? Lo primero para el usuario: SiriAI habla por fin español. Y francés, japonés, coreano y portugués. Hace unos días llegó con iOS 27 solo en inglés. Ojo, que esto no es solo una noticia para el usuario: cuando millones de personas empiecen a hablarle a Siri en su idioma, se va a notar muchísimo qué apps tienen sus acciones bien expuestas con App Intents… y cuáles no existen para el sistema. Nosotros en @benativeapp ya hemos expuesto toda la información de la app, integrada la reproducción de audio sin abrir la app, la gestión de notas sin abrir la app, búsquedas directas desde Siri hacia la app, deeplinks del contenido directo... Pronto tendremos actualización. ¿Y tú? 👨🏻‍💻 Y para nosotros, developers, dos novedades muy gordas. La primera: el adiós (opcional, de momento) al project.pbxproj. Sí, ese archivo lleno de IDs hexadecimales que nadie entiende y que te destroza cualquier merge. Xcode 27.2 trae el nuevo project.xcproj en JSON dentro del .xcodeproj: estructura en árbol como la que ves en Xcode, nombres y rutas legibles y cada archivo declara a qué target pertenece. Diffs limpios, muchos menos conflictos. Lo conviertes desde el inspector de archivos o con xcodebuild. ¿Y para quién está pensado? Apple lo dice claro: para que los agentes de IA lo lean y lo modifiquen. Dato curioso: casi 20 años sin que a nadie le importase que un humano pudiera leerlo, y ha tenido que llegar una máquina. Interesante. 🔄 La segunda: migración de datos entre apps con distinto bundle ID. ¿Alguna vez has tenido que rehacer una app desde cero con un bundle nuevo? Entonces sabes el drama: el usuario lo perdía todo. Ahora designas la app sucesora y el sistema le ofrece al usuario llevarse sus datos y ajustes: permisos, notificaciones, modos de concentración, widgets, CarPlay, Live Activities… Y la app antigua se borra sola. Solo entre apps del mismo desarrollador y la API aún está por detallar, así que toca seguirla beta a beta. 🎯 Fíjate en la jugada: el proyecto de Xcode ya no se escribe solo para ti, se escribe también para tu agente. ¿Todavía no te has formado para el cambio en la forma de desarrollar? Hazlo: por tí mismo, con nosotros en Apple Coding Academy o con quién tu quieras: pero tener criterio y usar los agentes ya no es opcional. Es la única forma de sobrevivir profesionalmente.

🤦🏻‍♂️ Tu agente de IA lleva meses escribiendo código Swift "basado en la documentación de Apple". El problema es que nunca la ha podido leer. 🕳️ Las páginas de developer.apple.com se pintan con JavaScript. Cuando un agente intenta leerlas se encuentra una página vacía, un cascarón sin contenido. ¿Y qué hace entonces? Lo que haría cualquiera con prisa: tirar de memoria. De lo que aprendió en su entrenamiento. APIs de hace varias versiones, patrones que Apple ya no recomienda y ese código que compila… con cuatro warnings de regalo. Y tú, convencido de que "la IA lo ha consultado". 🔑 El truco es simple y lo publicaba @timsneath en su X, dando gracias a @luka_bernardi por la inspiración del tip: coge cualquier página de la sección documentation y añade .md al final de la dirección. Así, sin más. La web /documentation/swiftui/view pasa a terminar en view.md y lo que recibes es Markdown limpio: firma, disponibilidad por plataforma, aislamiento de actor, ejemplos y relaciones entre tipos. Para las guías de diseño (las Human Interface Guidelines) y los tutoriales hay que hacer un paso más: insertar tutorials/data justo antes de la ruta y terminar también en .md. Algunas páginas de tutoriales, como las de presentación, no tienen versión Markdown. Para esas, cambia .md por .json y listo. 🤖 Xcode 27 ha abierto la puerta de par en par al desarrollo agéntico. Agentes de Anthropic, Google y OpenAI dentro del propio IDE, cualquier agente compatible con Agent Client Protocol, planificación interactiva, conversaciones multiturno, skills personalizadas, herramientas vía MCP, MCP en modo headless y un Device Hub con el que el agente puede lanzar el simulador y validar su propio trabajo para funcionar de forma autónoma durante más tiempo. Traducido: el agente ya no te sugiere una línea. Toca veinte archivos mientras tú vas a por un café. ⚠️ Pero fíjate en lo que ha pasado en este post. El truco no lo ha descubierto la IA. Lo ha tenido que descubrir una persona que sabía que la documentación se renderiza en cliente, que sabía por qué el agente fallaba y que sabía qué pedirle. Eso tiene un nombre: criterio. Y conocimiento. La IA ejecuta a una velocidad que ningún humano puede igualar… también cuando se equivoca. Si no eres capaz de detectar que tu agente está usando una API desfasada, no estás dirigiendo nada. Te están dirigiendo a ti. Y el mercado ya empieza a notar la diferencia entre quien escribe prompts y quien entiende lo que el código hace y sabe qué pedir y cómo. 🎯 Este truco y muchas otras cosas (cómo diseñar skills, auditar lo que genera un agente, cómo trabajar con él sin perder el control de tu arquitectura) forman parte del Swift Engineering Program que arranca el próximo 5 de octubre. Porque la pregunta ya no es si vas a programar con IA. Eso ya está pasando. La pregunta es otra: cuando tu agente se equivoque… ¿vas a saber verlo? ¿Crearás código funcional y válido sin deuda técnica o IA Slop?

⏳ Quedan dos días para cerrar las inscripciones a la Hackathon. Gratis. Online. Del 18 al 27 de septiembre. No te lo pienses demasiado o te quedas fuera. 🍎 Swift & SwiftUI nativo. Sin librerías de terceros. Monta tu MVP y gana promoción en redes + 6 meses de membresía en @benativeapp 🔗 Inscripciones: acoding.academy/hackaton26/ 🚀 #ACAHackathon2026

🔥 Si tu diseñador decidió que tu app llevara una toolbar "custom" porque los controles nativos de Apple "limitaban su creatividad"... enhorabuena: acaba de regalarle a tu empresa varios meses de trabajo. El iPhone Duo ya está aquí. Y no perdona. 📱 Apple no ha hecho "un iPhone que se dobla": ha redefinido cómo una app entiende el espacio. Dos pantallas (exterior e interior, con el pliegue en el centro) y 6 experiencias distintas que soportar: cerrado en vertical, cerrado en horizontal, abierto en vertical, abierto en horizontal, plegado como un libro y plegado como un portátil sobre la mesa. Seis. Y ojo: la pantalla interior ignora las orientaciones que tu app declara soportar. 🔑 ¿La clave de todo? Las size classes. La pantalla exterior se comporta como cualquier iPhone (ancho compacto) y la interior es regular en ambos ejes, como un iPad. Si tu layout depende de la orientación, del idiom o de UIScreen.main, tienes deuda técnica con intereses. Nada de tamaños fijos ni breakpoints: el sistema te dice el espacio disponible y tu app se adapta. 👀 Lo nuevo que debes conocer: barras verticales (el sistema mueve toolbars, tab bar y navegación al lateral, bajo el pulgar), safe areas asimétricas, reserved regions para esquivar el pliegue y la cámara bajo pantalla, ArrangementView para layouts divididos y lectura de la bisagra con onHingeChange. Todo compilando con el SDK de iOS 27.1 en Xcode 27.1. 🫵🏻 ¿Y si tu app usa controles no nativos? Apple es clara: el contenido de una barra custom NO se considera para la región vertical. Tu app seguirá funcionando, sí... pareciendo legacy: barras horizontales, contenido que no esquiva el pliegue y franjas negras en la pantalla interior si no recompilas. Quien respetó los frameworks nativos adapta su app en días. Quien "sabía más que Apple", en meses. 🤖 ¿Y Flutter o React Native? Apple no lo dice, no hace falta: si tu UI no la dibujan los frameworks nativos, no hay adaptación automática. Ni barras verticales, ni reserved regions, ni bisagra. Dependes de que el framework adopte estas API y de rehacer a mano lo que SwiftUI o UIKit dan gratis. Los propios contributors de React Native ya piden ese soporte. 🎯 Una app no es una página web: es un ciudadano de un sistema operativo. Cuando respetas el sistema, el sistema te cuida. Dinos, ¿tu app está lista para plegarse? Porque si no, en Apple Coding Academy y nuestro Swift Engineering Program lo hará.

Te podemos intentar convencer y puede que nos creas o no sobre lo que ofrecemos... pero lo que nos cuentan nuestros antiguos alumnos cuando se ofrecen a hablar públicamente para que todos conozcáis su opinión... ahí están ellos... creedlos o no. Pero lo que ellos transmiten no tiene precio.

⚠️ Ver un solo warning en un proyecto me pone de los nervios. TOC. Todo el TOC. Uno. Imagina 47. Y sé que hay gente que convive con ello tan tranquila. Pero a veces hay que gestionarlos por el ciclo de desarrollo, y ahora Swift 6.4 nos da la herramienta para hacerlo. 🔕 El problema del warning no es el warning. Es que se acumulan hasta convertirse en papel pintado. Una API deprecada que aún no puedes migrar porque la sustitución es radicalmente distinta y necesitas tiempo. Un patrón heredado que vas a tocar "el mes que viene". Y ahí se quedan, sumando líneas amarillas, hasta que el warning número 48, el que sí importaba, el que te iba a explotar en producción, pasa desapercibido entre el ruido. ¿Y qué opciones teníamos? Dos, y las dos malas: tragar, o desactivar la comprobación en TODO el proyecto. Un interruptor global para un problema local. Eso nunca es ingeniería, eso es barrer y levantar la alfombra. 🔬 El nuevo atributo @diagnose trabaja donde tiene que trabajar: en la declaración concreta. Le dices a UNA función que ignore un grupo de diagnósticos, escribes el motivo dentro del propio atributo, y ese silencio no contamina nada más. Pero lo bueno viene en dirección contraria, y es lo que casi nadie está contando: @diagnose también enciende diagnósticos apagados por defecto y asciende warnings a errores. 🤌🏻 Por ejemplo, activas StrictMemorySafety y te obligas a auditar cada uso de APIs unsafe en ese punto exacto. ¿Warnings que Swift convertirá en error dentro de dos versiones? Los conviertes en error HOY, en tu código, cuando tú decides y no cuando te obligan. Holly Borla, manager del equipo de Swift, lo eligió como su función favorita de esta versión justo por eso: permite migrar al modo de lenguaje Swift 6 de forma granular, módulo a módulo, función a función. Nada de saltos al vacío. 🫵🏻 Y aquí va lo que quiero que se te quede: silenciar un warning y gestionar un warning se escriben casi igual y significan justo lo contrario. Silenciar es esconder. Gestionar es decir "conozco este aviso, sé exactamente por qué está ahí, dejo escrito el motivo y asumo la deuda". @diagnose te obliga a lo segundo, porque el motivo viaja en el código, a la vista de quien lo lea dentro de dos años. Que serás tú, con menos memoria de la que crees. Así que la pregunta no es cuántos warnings tienes. Es: ¿cuántos de ellos podrías justificar por escrito ahora mismo, sin buscar en Google? Esos son los que controlas tú. El resto te controlan a ti 🤷🏻‍♂️

🖼️ AsyncImage es un bluf. ¿Por qué? No cacheaba. Bajas por un scroll, las imágenes se cargan, subes de nuevo... y se vuelven a descargar. ¡Pero ya se arregló en iOS 27! (Ya tocaba) Apple lo reconoce con todas las letras en la sesión de SwiftUI de este año: AsyncImage no mantenía las imágenes en memoria, así que al reaparecer en pantalla volvían a pedirse. Motivo por el que en clase hacemos nuestra propia librería que además nos enseña a gestionar la re-entrada del actor. Motivo por el que muchos tenéis librerías de terceros (mala cosa 😉) 📡 En la SDK de las versiones 27, AsyncImage soporta caché HTTP estándar por defecto, respetando las cabeceras que envía el servidor. Sin tocar una línea de tu código y 100% retrocompatible. Basta compilar en Xcode 27 y ya. Han conectado AsyncImage con el mecanismo de URLCache para la web. Incluso puedes pasarle tu propio URLRequest con la política de caché que quieras, o montar un URLSession con un URLCache del tamaño que decidas y enchufárselo a la vista con el modificador asyncImageURLSession. 🤔 100% concurrencia estricta, sin dolores, sin presiones... fácil, rápido y sencillo. Y sin tocar una sola línea si ya usas AsyncImage. ¿Sabías esto? ----- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

Swift Engineering Program 2026 → ⏳🚀

¡¡Enorme cambio en el App Store!! Por eso nuestra próxima formación, Swift Engineering Program, incluirá un módulo específico del App Store, subidas, marketing, material... todo con las nuevas prácticas para las versiones 27. Te cuento qué es... Hasta ahora teníamos el icono, las capturas y los App Previews. Ahora llegan los Creative Assets: imágenes y vídeos que podrán aparecer en la cabecera de la ficha de producto, en los resultados de búsqueda e incluso cuando Apple destaque nuestra aplicación. Es decir, la App Store deja de ser una simple ficha con capturas y empieza a convertirse en un espacio creativo mucho más parecido a una verdadera landing de producto. Y hay más. Todos los recursos aprobados estarán centralizados en una nueva Asset Library de App Store Connect. Podremos reutilizarlos, enviarlos a revisión sin depender necesariamente de una nueva versión de la app, previsualizar cómo se verán en distintos contextos y gestionarlos también mediante la API de App Store Connect. Además, estos nuevos recursos podrán utilizarse en páginas de producto personalizadas y probarse mediante Product Page Optimization. Esto cambia bastante el trabajo de ASO. Ya no será suficiente con preparar unas capturas bonitas al final del desarrollo. Habrá que pensar en la presencia visual de una aplicación como una parte más del producto: qué contamos en la búsqueda, qué mostramos al entrar en la ficha, cómo presentamos una campaña estacional y qué recursos convierten mejor. Apple da una recomendación que parece obvia, pero no siempre aplicamos: una sola idea clara por recurso, comprensible de un vistazo y centrada en la experiencia real de la aplicación. En definitiva: más posibilidades para destacar, más capacidad para experimentar y también bastante más trabajo para quienes publicamos aplicaciones. Pero es un cambio enorme. Y creo que merece la pena empezar a prepararse ya. Por el Swift Engineering Program que empieza en octubre ya lo ha tenido en cuenta y en nuestras próximas formaciones para empresas que empiezan en septiembre, ya está incluido como opción para quien esté interesado. ¿Qué te parece? Te leo...

Swift Engineering Program. 9ª edición. Primero programar. Después IA. 40 plazas 👉 5 de octubre Apple no busca cantidad. Busca criterio.

Hoy abrimos las inscripciones del Swift Engineering Program 2026 y, desde el cariño, déjanos contarte por qué esta edición importa más que ninguna. El App Store va camino de recibir más de un millón de apps nuevas este año, récord histórico... y las descargas solo crecen un 2%. Un millón de apps que nadie descarga. Apple rechazó 1,2 millones de apps nuevas el año pasado, ha duplicado las eliminaciones hasta las 167.000 y las colas de revisión han llegado a los 45 días por la avalancha del vibe coding. ¿El problema es la IA? No. Nosotros la usamos a diario. El problema es usarla sin criterio, porque la IA no distingue lo correcto de lo que solo compila. Y el criterio no se copia ni se genera: se entrena. Eso hacemos en esta novena edición, renovada de arriba abajo. Primero te enseñamos a programar y luego a dirigir agentes con el Agentic Coding de Xcode 27. El agente como tutor, después como compañero al que auditas y al final como equipo que tú diriges. Formamos al engineer que las empresas piden, porque escribir código ya no es el trabajo: decidir qué código merece llegar a producción, sí. Del 5 de octubre al 27 de noviembre, 40 plazas, sin experiencia previa:

🚨 Cada primavera se repite la misma jugada y casi nadie aprende la lección: lo que en la beta de junio era "advertencia amarilla en consola", en abril del año siguiente es rechazo directo en App Store Connect. Ya lo vivimos con el SDK de las versiones 26 desde el pasado 28 de abril. Y siguiendo el mismo patrón que llevamos años observando, en primavera de 2027 le tocará el turno a iOS 27. 🤔 ¿Qué significa esto en la práctica? Que llegado ese momento, absolutamente TODOS los desarrolladores (da igual el tamaño de tu app, tu empresa o cuánto tiempo lleves sin tocar ese proyecto "que ya funciona") tendrán que subir cualquier actualización compilada con Xcode 27 y el SDK de iOS 27 como mínimo. Y este salto no es solo un número de versión: trae condiciones concretas que, si no las conoces, te van a explotar en la cara justo cuando menos tiempo tengas para reaccionar. 👉🏻 UIScene deja de ser una sugerencia. Si tu app sigue viviendo solo de AppDelegate sin ciclo de vida basado en escenas (esa advertencia que Apple lleva mostrando por consola desde iOS 26), con el SDK de iOS 27 directamente no arranca. Se queda en pantalla negra. Apple lo documenta en TN3187 con todo el detalle técnico: adóptalo ahora, no en marzo del año que viene con la fecha límite respirándote en la nuca. 👉🏻 Pantalla de lanzamiento declarada de forma explícita. Apple ha publicado TN3208, el technote específico que regula este requisito desde iOS 27 e iPadOS 27: tu Info.plist debe declarar UILaunchScreen, UILaunchStoryboardName (o sus variantes) o tu build se queda fuera antes de que un humano la revise. 👉🏻 Liquid Glass sin vía de escape. El flag UIDesignRequiresCompatibility, esa puerta trasera que muchos usasteis para posponer la adaptación visual del año pasado, previsiblemente deja de tener efecto con el SDK de iOS 27. Tu interfaz hereda el nuevo lenguaje visual quieras o no, así que si tienes UIKit muy personalizado (barras, fondos, translúcidos) este es el verano para probarlo, no el próximo marzo para sufrirlo. 🫵🏻 La pregunta que de verdad importa no es técnica: ¿vas a auditar tu app ahora, con meses de margen, o vas a descubrir estas tres condiciones en plena fecha límite con un rechazo delante y un cliente preguntando por qué no sale la actualización? El plazo es el mismo para todos. La diferencia la marca quién decide moverse antes de que se lo exijan. ¿Ya has probado tu app con el SDK de iOS 27 en el simulador? Cuéntanos en comentarios cuál de las tres te va a dar más guerra. Por cierto, si necesitas ayuda, ofrecemos esta para tu proyecto desde @GabhelStudios, ¿lo sabías?. ------ Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

Últimos días para unirse al Swift AI Engineering Program 2026 🤖 os aseguramos de que os cambiará la vida como programadores 👇 🔗 acoding.academy/formaciones/…

Acabamos de publicar el anuncio del Swift Agentic Engineering Program 2026. No tiene promesas imposibles. Tiene una sola pregunta. La IA no va a quitarte el trabajo. Te lo va a quitar alguien que sabe usarla. Y la diferencia entre ese alguien y tú no está en saber más Swift — está en saber dirigir agentes con el criterio técnico que ya tienes y que, ahora mismo, probablemente estás dejando fuera de la ecuación. Enlace en el perfil. Si después del vídeo quieres saber qué hay dentro del programa, en la misma página está todo.

Hoy Lil Finder Guy se ha pasado por las oficinas de la academia a saludar. Él y Swifty son colegas de hace mucho tiempo y han pasado todo tipo de aventuras.

🗓️ La WWDC26 ya tiene fecha: 8–12 de junio. IA, nuevas plataformas y herramientas. Una semana que lo cambia todo. ¿Ya tienes el 8 en el calendario? 👇 En Apple Coding Academy estaremos al tanto de todas las novedades, síguenos para no perderte nada!

Episodio completo: youtu.be/LyKt23lHDpQ

🤯 ¿8GB en un Mac? ¿En 2026? Pues sí. Y haciendo locuras como editar vídeo 4K, abrir decenas de apps o correr juegos triple A. Porque la forma en que macOS gestiona la memoria es muy eficiente. En nuestro último podcast os contamos el secreto, así como muchas otras claves que permiten que un equipo como MacBook Neo funcione mejor que cualquier equipo en su categoría de otros fabricantes y sistemas. 🤷🏻‍♂️ No es opinión ni fanboy: en Apple Coding Academy hablamos de hechos, así enseñamos a nuestros alumnos: con datos concretos y reales. Dato mata relato. 📹 Puedes ver el podcast completo en nuestro canal de Youtube.

Y esto es lo que cambia todo: La barrera ya no es el hardware. Es saber usarlo 🚀

⚡️Apple no ha actualizado el M5. Lo ha reconstruido desde cero. El primer cambio arquitectónico REAL desde el M1.

Apple no ha presentado “más potencia”. Ha presentado un cambio de arquitectura. ➡️ M5 Pro y M5 Max = Fusion Architecture, doble die, Neural Accelerators en cada GPU y hasta 614 GB/s de memoria. Te lo explicamos todo aquí👇 youtu.be/phuZnm1sFmY?si=uetN…

Apple acaba de meter IA agéntica dentro de Xcode - Xcode 26.3 ya puede trabajar solo: desglosa tareas, toma decisiones y ejecuta código de forma autónoma. - Claude + Codex integrados en el IDE. Y si no te gustan, puedes conectar tu propio agente via MCP ⚠️ But oh wait! Que no se te olvide, para que el agente de Claude y Codex aparezca en Xcode, necesitas tener macOS Tahoe instalado

Ya están abiertas las inscripciones para el Swift Developer Program de primavera ⭐️ 8a edición 👩‍💻 40 Plazas disponibles 💻 Clases en directo de lunes a jueves ☕️ Proyecto final real Plazas limitadas. Empieza el 7 de abril. Reserva tu entrevista gratuita ahora: applecodingacademy.youcanboo…

🤯 El pasado 15 de febrero, un protocolo DeFi llamado Moonwell perdió 1,78 millones de dólares en minutos. No fue un hacker con años de experiencia. No fue un fallo de arquitectura complejo. Fue una línea de código mal calculada... escrita con IA, aceptada sin revisar, en un proyecto donde la desarrolladora principal subía 423 commits al día. ¡423!. 🤖 Opus 4.6 aparece como coautora oficial en el Pull Request que causó el desastre. El error fue de manual: el oráculo de precios tomó el ratio cbETH/ETH (≈1,12) y olvidó multiplicarlo por el precio real del Ethereum en dólares. Un cbETH que vale 2.200 dólares apareció valorado en 1,12. Los bots lo detectaron antes de que parpadeara nadie y se llevaron más de mil unidades pagando prácticamente nada. ¡1,78 millones de dólares de pérdidas que la empresa ha tenido que asumir! 🤦🏻‍♂️ La IA no revisa. La IA genera. Y cada sesión empieza desde cero, sin memoria de lo anterior, sin saber si lo que te acaba de escribir es una práctica segura o una bomba de relojería. La IA no distingue entre un cálculo correcto y uno catastrófico si tú no le das la información adecuada y, sobre todo, si tú no supervisas el resultado con criterio real. Si no le das el contexto necesario y herramientas para que cada inicio de sesión tenga una "memoria" de trabajo y supervisas lo que hace, como si fuera un junior. 😎 El "vibe-coding" (generar código con IA a velocidad de vértigo sin saber qué haces) es un cáncer. Y este es solo un ejemplo de una pérdida millonaria real e irreversible, porque en blockchain no hay un "undo". Y ojo, que Moonwell ya había tenido otro incidente en noviembre de 2025 con un millón de dólares. 🧠 La IA es la herramienta más potente que ha llegado al desarrollo en 50 años. Es como tener robots que ponen ladrillos para construir casas a velocidad de vértigo para montarlas en días y no en años. Pero sin un arquitecto detrás que diga dónde tienen que ir las paredes, el reparto de peso, los pilares, la distribución... la casa se caerá al primer soplido de viento. 🔨 Una herramienta en manos de alguien que no entiende lo que está haciendo no es productividad: es riesgo. Nosotros somos los responsables de lo que generamos, se haga con IA o sin ella. ¿Te dejarías diagnosticar una enfermedad por tu cuñado fontanero que preguntó por tus síntomas a ChatGPT? --------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

Puedes ver el podcast completo en Youtube: youtu.be/y9HEICi9yNc Puedes oír el podcast en Cuonda: cuonda.com/apple-coding/entr…

🤯 Los discípulos de Angela Yu que tras un curso de Udemy optan a entrevistas técnicas donde hacen las pruebas con ChatGPT... parece increíble, pero es una realidad y uno de los motivos por los que la selección se ha vuelto tan dura en las entrevistas. 🤔 ¿Quieres usar IA en tu trabajo como programador? Perfecto, porque hoy día es una obligación, no una opción. Pero, ¿crees que si ponemos robots en la obra de una casa a poner ladrillos más rápido que un humano... basta con eso? Porque te garantizo que sin un arquitecto detrás que sepa cómo pedir y supervisar, esa casa se caerá al primer soplo de viento. Un MVP de tutoriales hecho por la IA no es una app: es una demo de lo que molas. Bastante 💩 hay ya en el App Store. 🎙️ Escucha la entrevista completa con @mhergon, en Youtube y en podcast. Enlaces en el primer comentario.

Programar no es escribir código: en 2026 el código lo escribe una IA. Pero si no sabes programar: entender patrones, arquitecturas, algoritmos, procesos, cómo dividir una tarea en subtareas y ordenar en el orden preciso... si no sabes diseñar una pantalla amigable, con buena experiencia de usuario, con su accesibilidad para cualquier tipo de usuario independiente de sus capacidades... Programar no es escribir código: es saber cómo se crea el software. Si no sabes qué pedirle a una IA ni cómo pedírselo conociendo la herramienta... tienes el mismo mérito que quien usa una cámara de 6.000€ para hacer fotos en automático. Puede que alguna foto salga bonita, pero no eres fotógrafo.

🤯 Ayer estuvimos migrando una app con Core Data a Swift 6 con la concurrencia estricta. Pusimos a la IA a ayudar. ¿Sabéis cuál fue su "brillante" solución? Meter las clases de la base de datos en MainActor (spoiler: son Sendable) y "arreglar" los singleton poniéndole un let al static. Como quien pone una tirita en una tubería rota. Compiló. 🧠 Y aquí está el problema que nadie quiere ver. La IA, cuando actúa como agente, tiene un único propósito: que compile. Pero un código que compila no es un código que esté bien hecho. No es un código seguro. No es un código eficiente. Es un código que pasa el compilador. Punto. 🫵🏻 Y esto nos lleva a la gran paradoja: AHORA es cuando más necesitas saber programar. Necesitas entender patrones, cómo funcionan los frameworks por dentro, cómo se estructura un código para que escale, cuándo un singleton tiene sentido y cuándo es un antipatrón disfrazado. Porque si no lo sabes, no puedes corregir a la IA. Y si no corriges a la IA, estás generando deuda técnica a una velocidad que si antes era posible corregir porque un desarrollador malo generaba deuda técnica despacio... ahora, con la IA, la genera a velocidad industrial. Y cuando explote... ¿quién arregla el lío? ¿La IA? 🤔 Hay algo más que nos preocupa que es la otra cara de esta moneda. Es cómo se configura la propia IA. Usar la IA, dicen. No... hay que saber usarla. Cómo se crea un skill, un agente, cuándo usarlo, qué conocimiento darle para que haga lo que tiene que hacer de verdad. 🤦🏻‍♂️ Y alucinamos: hemos pasado de usar librerías de terceros que no sabes cómo están hechas, donde asumes sus errores de seguridad, su código obsoleto, sus decisiones de diseño... ¿y ahora usamos skills de otros como si nada? Un skill mal hecho puede dar instrucciones erróneas a un agente. Y uno malintencionado podría estar configurado hasta para introducir puertas traseras en tus apps o sistemas. Es cambiar un problema por uno peor. 💡 Por eso decimos que este es, paradójicamente, el mejor momento de la historia para aprender a programar de verdad. No para copiar y pegar. No para rezar para que compile. Para ENTENDER. Entender qué hace cada línea, por qué la concurrencia estricta existe, qué implica un MainActor donde no debe estar, cómo funciona Core Data por debajo, qué es un índice, por qué un patrón es mejor que otro. Porque solo desde ese conocimiento puedes usar la IA como lo que es: una herramienta que multiplica tu capacidad. Pero si no tienes capacidad... multiplicas cero. Y cero por mucho que lo multipliques, sigue siendo cero. 🎓 Por todo esto, el Swift Developer Program 2026 que impartirá @mhergon no es un curso más. Es la base que necesitas para entender el código, dominar Swift 6, la concurrencia estricta, las arquitecturas nativas y saber usar la IA desde el conocimiento, no desde la fe ciega. 🤔 Porque el futuro no es de quien usa la IA. Es de quien sabe usarla y, sobre todo, corregirla.

¿Cómo funcionará la nueva Siri con Gemini? El otro día, en directo, os conté TODO alrededor de la misma: - El contexto personal y cómo funciona internamente con embeddings vectoriales para entender tu información y encontrar lo que necesite. - El modelo FerretUI que permitirá leer tu UI y guiarte en el uso de las apps. - Cómo funciona los Intents para que Siri pueda invocar acciones en tus apps, de forma similar a cómo funciona MCP (Model Context Protocol) - Cómo funcionará el modelo Gemini dentro del ecosistema de Apple Intelligence y los flujos que veremos en el futuro Chatbot. ¿Cómo sé todo esto? No es opinión: son hechos, conocimiento, funciones con las que ya estoy trabajando hace meses... No opino que será así: sé que será así. Te dejo el enlace al directo en el primer comentario.

🙃 30 tips de concurrencia con Swift... TIP 3/30, 🫥 NSOperation... así funcionaba la concurrencia (1/2) 🦖 Antes de async/await, hacer concurrencia en Swift era... interesante. Dos herramientas reinaban: NSOperation (hoy Operation) y Grand Central Dispatch (GCD). Si llevas tiempo en esto, seguro que las has sufrido. Si no, bienvenido a la primera clase de historia: NSOperation. 🧱 NSOperation nació en los tiempos de Objective-C. La idea era crear "operaciones" como objetos, meterlas en una cola, y dejar que el sistema las ejecutara. Podías definir dependencias entre ellas, cancelarlas, incluso crear subclases con lógica compleja. Muy potente... y muy "verboso". Y tenías que crear una clase para cada operación. 🧶 Mira el código del slide 1: para hacer algo simple necesitas crear una clase, sobreescribir métodos, gestionar estado. Y ese código en Swift 6 da warning. Operation es @ unchecked Sendable y el compilador te exige que tu subclase reafirme esa conformidad explícitamente. Traducción: Apple te está diciendo "esto es legacy, asumes tú el riesgo". Cuando el propio compilador desconfía de tu código... 🤯 ¿El problema real? Aparte del código un poco meh y recuperar el resultado como el slide 2 usando el OperationQueue.main... puedes crear un data race y no te enterarás hasta que la app explote en producción un martes a las 3AM. No hay verificación en tiempo de compilación. No hay seguridad. Solo fe y tests. 🙋‍♂️ ¿Y tú? ¿Usaste NSOperation? Contenido ofrecido por Apple Coding Academy.

Novedades IMPORTANTES para Xcode 26.3! 🚀 Xcode 26.3 incorpora Agentic Coding. ¿Qué pueden hacer estos agentes? → Descomponer tareas complejas automáticamente → Tomar decisiones sobre arquitectura → Explorar docs y estructura de archivos → Capturar Previews e iterar fixes Lo más potente es que un agente puede: 1. Construir UI en SwiftUI 2. Pedir captura del Preview a Xcode 3. Validar visualmente el resultado 4. Detectar errores y corregirlos Funciona con Model Context Protocol (MCP) Estándar abierto == no estás limitado a Claude Code o Codex. Cualquier agente compatible puede usar las capacidades de Xcode. Dos flujos: terminal o dentro de Xcode. Disponible ya como release candidate para Apple Developer Program.

🙃 30 tips de concurrencia con Swift... TIP 2/30, 🫥 Data races: el enemigo invisible 💣 Un data race ocurre cuando dos operaciones intentan modificar el mismo dato a la vez. Imagina que tú y tu pareja miráis la cuenta: hay 100€. Ambos sacáis 80€ al mismo tiempo. El banco os deja... porque cuando mirasteis, había dinero. Resultado: -60€ y un problema gordo. 🤯 La CPU no suma "de golpe". Lee el valor, calcula, guarda el resultado. Si dos hilos leen el mismo valor ANTES de que el otro guarde... ambos creen que tienen razón. Y ninguno la tiene. 🧵 Los hilos que trabajan en concurrencia (varias operaciones a la vez) puede provocar este problema. Y es aleatorio porque la CPU nunca hace lo mismo en el mismo orden. A veces pasa, a veces no. ¿Recuerdas esos cuelgues fantasmas de tu app en el App Store que no sabes por qué son? Lo más probable, es que sean Data Races. 🤦🏻‍♂️ Prueba el código de ejemplo en un Playground (en modo Swift 5) y comprueba por ti mismo qué sucede. 👀 Sígueme para más tips de Swift y conceptos... nos quedan 28 todavía. Contenido ofrecido por: Apple Coding Academy.

🙃 30 tips de concurrencia con Swift... TIP 1/30, ¿Qué es concurrencia y por qué importa? ⛓️ La concurrencia es cuando múltiples tareas pueden ejecutarse a la vez, mientras que la serialización es cuando hacemos una a una y hasta que una no acabe no pasamos a la siguiente. 🧵 La concurrencia depende de los hilos, donde destaca el hilo principal o Main Actor (en Swift). Este hilo es donde todos los procesos de la UI de tu app se ejecutan: entre ellos su dibujado, animaciones, control de usuario, scroll... todo. 🪡 Cada hilo siempre es serializado y la concurrencia es ejecutar distintos procesos en distintos hilos. 🥶 Si ejecutas un tarea pesada en el hilo principal, puedes congelar la app y que deje de responder. Por eso estas tareas las llevamos a otros hilos, usando concurrencia. 👀 Sígueme para más tips de Swift y conceptos... nos quedan 29 todavía.

🤔 iOS 26.2.1. Una actualización de punto. Soporte para AirTag 2, algún bug corregido y poco más, ¿no? Pues no. Resulta que Apple ha modificado más de 60 componentes del sistema, más de 20 archivos Metal Shader relacionados con el procesamiento de imagen y vídeo, ha actualizado el firmware de audio con casi 9.800 funciones, y ha reforzado el Secure Enclave con nuevas capacidades de cifrado. ¿Te parece menor? 🔍 Y aquí está la lección: las actualizaciones "menores" de Apple rara vez lo son. Detrás de ese número de versión que parece intrascendente hay refinamientos en la canalización de la cámara, mejoras en el reconocimiento de voz de Siri, un nuevo firmware de Bluetooth y hasta cambios en cómo se descargan e instalan las propias actualizaciones. Cosas que no ves, pero que notas: mejor estabilidad, fotos más limpias, conexiones más fiables. Apple trabaja en silencio donde realmente importa. 👨🏻‍💻 Así que la próxima vez que veas un .1 o un .2, no lo desprecies. Actualiza. Como desarrolladores debemos entender que el sistema sobre el que construimos evoluciona constantemente bajo la superficie, y conocer esos cambios marca la diferencia entre un profesional y alguien que solo copia y pega código esperando que funcione. El detalle importa. Siempre. ------ Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

Descubre todos los detalles en nuestro último podcast: youtube.com/watch?v=unxmnEUa…

🤯 Apple y Google firman un acuerdo oficial para que Apple Intelligence use versiones de Gemini 3 como modelo LLM en su infraestructura: un nuevo AFM. ¿Qué significa esto? 🤦🏻‍♂️ No: Apple no cambia OpenAI por Google. No: Apple no usará "la misma IA" que en Android. No: Apple no usará los servicios de Google. NO: Apple no se echa a un lado para que Google domine su IA porque ellos no saben. 👨🏻‍🏫 Apple Intelligence es una infraestructura que funciona en local y en la nube con dos modelos AFM (Apple Foundation Model) creados por la propia Apple. Este AFM es un SLM (modelo de lenguaje pequeño) en local y un LLM en la nube (modelo grande de lenguaje). Este modelo es el encargado de Siri y de las herramientas de escritura que permiten hacer resúmenes, corregir texto y estilos, respuestas automáticas en mail o mensajes o resúmenes de notificaciones. Nada más. 🤔 A partir de ahora, Apple licencia el modelo Gemini 3 para hacerlo su nuevo AFM e integrarlo en su actual infraestructura de Apple Intelligence. Pero dichos modelos correrán en el dispositivo del usuario (como hasta ahora) y en la propia nube de Apple. No se usarán servicios de Google ni se cambiará nada. Es como si en Cursor pasas de usar GPT 5.2 Codex a usar Opus 4.5. Solo cambias el modelo, pero Cursor sigue siendo el mismo. No hay más. 👏🏻 En primavera, con la nueva Siri, Apple incorporará estos modelos pues son mejores que los suyos y responden mejor a las nuevas funciones de Siri que tendrán un mayor control del sistema y acceso a nuestra información personal. Pero garantizando la privacidad y todo dentro de los dispositivos Apple. Google solo pone el modelo de lenguaje. Nada más. 🙃 De hecho, Gemini será el corazón de Foundation Model Framework a partir de primavera. Si queréis saber más, os invito a escuchar el Apple Coding Daily que lancé ayer que lo explica todo en detalle. Lo tenéis en el primer enlace. ------ Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

🤯 El 85% de los desarrolladores ya usa IA para programar. Los agentes autónomos como Claude Code, Cursor o Codex no completan líneas: entienden repositorios enteros, ejecutan refactorizaciones y corrigen errores en múltiples archivos. Ahora puedes enseñarles tus patrones con Agent Skills, MCP les conecta con tus herramientas y los equipos más avanzados ya ejecutan varios agentes en paralelo como si fueran un equipo de ingenieros virtuales. 📊 Según un estudio de Stanford, el empleo de desarrolladores junior ha caído un 20% desde 2022. ¿Por qué? Porque la IA hace muy bien lo que hacen los juniors. Quien no entiende el código, no puede dirigir a quien lo escribe por él. 🎯 Esto ha cambiado la formación más que nunca. Ya no basta con saber Swift, SwiftUI o cómo funciona un actor. Necesitas saber POR QUÉ funciona así, cuándo usarlo, cuándo no y cómo explicárselo a una IA para que trabaje contigo sin destrozar tu arquitectura o inventarse algo obsoleto o no escalable. 👨🏻‍🏫 Por eso para este año, reconfiguramos el Swift IA Mastery Program para, no solo aprender a programar: aprender a pensar como un arquitecto de software. Cada patrón, cada framework, cada decisión tiene un por qué que entiendes en profundidad. Y mientras construyes esa base sólida, incorporamos herramientas como Claude Code, Codex, LM Studio, Goose para crear tus agentes en local... configuración de Skills y uso de MCP como parte natural del flujo de trabajo. No como un parche: como una extensión de tu conocimiento. 💡 La IA multiplica. Pero multiplicar por cero sigue siendo cero. Los desarrolladores senior son quienes mejor aprovechan estas herramientas porque saben qué pedir, detectan cuándo la IA se equivoca y pueden corregir el rumbo antes del desastre. Nuestro objetivo es que llegues a ese nivel: que entiendas el código como quien entiende un idioma, no como quien copia frases de un traductor. Y entonces, sí, la IA se convierte en el mejor compañero que puedas tener. Primero maestría, después multiplicación. Ese es el camino. 🤷🏻‍♂️ Si quieres saber más... mira nuestros enlaces y el primer comentario.

🤯 Llevas meses configurando tu CLAUDE.md o AGENTS.md para que la IA entienda tu proyecto... y cada vez que arranca una sesión, le vuelcas TODO el contexto. ¿Sabes cuántos tokens desperdicias cargando información que ni siquiera va a usar? Hay una forma mejor: se llama Agent Skills y acaba de convertirse en estándar abierto. 🎯 La diferencia fundamental es que con CLAUDE.md o AGENTS.md es contexto estático que siempre se carga en el sistema. Todo. Cada línea. Cada vez. Los Agent Skills funcionan con "progressive disclosure": solo se carga la información cuando es relevante para la tarea. 🙈 ¿Estás trabajando un PDF? El skill de PDF entra en contexto. ¿Compilando tu app iOS? El skill de desarrollo Apple toma el control. Esto significa que puedes tener decenas de skills instalados sin contaminar tu ventana de contexto hasta que realmente los necesites. Y lo mejor: el mismo formato funciona en Claude Code, Codex de OpenAI, GitHub Copilot, Cursor o VS Code. Write once, use everywhere. 📂 Un skill es simplemente una carpeta con uno varios archivos .md que contiene metadatos YAML (nombre y descripción) más instrucciones en Markdown. Opcionalmente puedes añadir scripts ejecutables, referencias y assets. Claude lee primero solo el nombre y descripción de cada skill instalado; si detecta que es relevante para tu petición, entonces (y solo entonces) carga el contenido completo. ¿Tienes documentación extensa? La mueves a references/ y Claude la lee bajo demanda. ¿Scripts repetitivos? Los ejecuta sin cargarlos en contexto. Esto es diseño inteligente: el contexto es un recurso limitado y los skills lo respetan. 🛠️ Para instalarlo es muy sencillo: en Claude Code creas la carpeta .claude/skills/ en tu proyecto (o ~/.claude/skills/ si lo quieres global). En Codex CLI es ~/.codex/skills/. En VS Code y Copilot, .github/skills/. Creas una subcarpeta con el nombre de tu skill, dentro pones los .md y listo. La IA lo descubre automáticamente. ¿Sigues volcando todo tu contexto de golpe o empiezas a trabajar de forma inteligente? -------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

🤯 Si piensas que copiar y pegar código que te da la IA es programar, lo siento pero llegas 20 años tarde. Con Stackoverflow ya hubo toda una generación de programadores frustrados que pensaron que copiar el código que otros publicaban como respuesta a sus dudas era saber programar. No: maquetaban código. Y eso NO servía. No servía hace 20 años y sigue sin servir ahora aunque cambies quién te lo da. Cambia el medio, no el problema. Si usas la IA para que te resuelva ejercicios, haga tus trabajos o apruebe tus exámenes, bienvenido al siglo XIX donde lo primero que todos sabían es que quien copia en un examen no aprende la materia. El mundo es cíclico y repetimos los mismos errores en distintos medios. 📖 ¿Sabes cuál es la mejor forma de aprender a escribir en un idioma? Leer. ¿Sabes qué es lo que más hace un novelista para mejorar su profesión? Leer otras novelas. Si no eres capaz de leer código por ti mismo, como quien lee un libro, no eres programador. Y en la era de la IA esto es más crítico que nunca: el código que genera un LLM no es de fiar. Será obsoleto, usará malas prácticas y nunca será el mejor en la primera respuesta. La IA necesita equivocarse primero para, basada en su error, darte algo mejor. Igual que un humano. Un verdadero programador lee código al igual que lo escribe. Y un verdadero programador dirige a la IA, no la usa para que haga su trabajo. ✨ Vivimos en la época dorada de la creación: la diferencia entre un junior y un senior no es el tiempo, es la experiencia. La calidad de lo que hace. La cantidad de conocimiento acumulado y lo que es capaz de resolver. Tu primera app será regular tirando a mala, la siguiente aceptable, la tercera mejor, la cuarta ya empezará a merecer la pena... pero solo creando, creando, creando generas esa experiencia. Como cualquier entrenamiento: solo corriendo consigues correr más rápido. Tu entrenamiento es crear apps cada vez más complejas. Y la IA puede ser tu sparring, no tu sustituto. 🎊 ¡Feliz 2026 y comencemos el año con energía de renovación! --------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

¡Feliz Navidad para todos los Good Apple Coders! Que Santa Swifty os traiga mucho código de calidad y vuestros mejores deseos sean cumplidos. ¡Gracias a todos por seguir ahí!

🤯 4 de 5 días con 30 alumnos en nuestro Swift Refresh Workshop. Hemos llegado a lo más profundo de la concurrencia, entendido cómo funciona en el nuevo modo MainActor y sus ventajas (e inconvenientes). Cuándo usar el modo nonisolated o este... y luego un repaso por arquitecturas tanto en UIKit como SwiftUI. 🙈 Tal vez lo que más les ha sorprendido es la nueva arquitectura basada en SwiftData donde cada @Query es un ViewModel en sí y entender cómo se orquestan este tipo de apps, incluso con conexiones en segundo plano... y ayer cuando vieron UIKit reaccionar sin tocar nada actualizando cambios (como hace SwiftUI) fue el momento boom... 🥰 ¡Qué feliz nos hace crear nuevas conexiones sinápticas en las mentes de nuestros alumnos!

Liquid Glass es clave para Apple pero los desarrolladores no terminan de darse cuenta... no hay cambios importantes en la mayoría de apps del App Store. Parece que los responsables de las apps no son conscientes que este cambio será obligatorio desde Xcode 27... y que iOS 27 tendrá TODOS, sin excepción, los controles a través del prisma de Liquid Glass. Empezar hoy no es una opción. Apple lo sabe y por eso mueve de nuevo su poder y convoca charlas por todo el mundo (inclusive Madrid, en febrero de 2026) para hablar de Liquid Glass y de Foundation Model Framework, otra funcionalidad que casi nadie está usando y que Apple quiere empujar en las apps. ¿Cómo está tu app? ¿Ya funciona con Liquid Glass? ¿La has adaptado convenientemente? Be Native ya es 100% Liquid Glass desde su lanzamiento y además retrocompatible en diseño a iOS 18.

Vivimos el cambio más importante en el desarrollo en más de 50 años y eso ha creado miedo e incertidumbre por igual. ¿Se acabó ser developer? Responder a esa pregunta requiere experiencia, por eso Tirso López Ausens, que lleva años trabajando con IA, nos lo aclara. Porque seamos sinceros: se acabó la puerta fácil de entrada en la que con un cursito podías empezar a trabajar... la demanda se ha reducido en cantidad, pero ha subido exponencialmente en exigencia. Ahora, más que nunca, hay que ser un Maestro... ¿qué opinas? ----------- Somos Apple Coding Academy. Formamos a desarrolladores y empresas desde la especialización, entendiendo el código y usando IA como herramienta productiva. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

🤷🏻‍♂️ ¿Sabías que gran parte del código Swift que genera hoy la IA ya nace obsoleto? No hablo de errores de compilación. Hablo de algo peor: código que funciona, que compila, que "parece" correcto... pero que esconde una bomba de relojería llamada deuda técnica. 🧨 El ejemplo perfecto: la concurrencia. Cuando pides a una IA que gestione tareas en segundo plano, en un altísimo porcentaje te devolverá DispatchQueue.main.async o DispatchQueue.global().async. ¿Por qué? Porque en su entrenamiento hay años y años de código con GCD (Grand Central Dispatch), mientras que async/await de Swift Concurrency apenas tiene 3 años de vida. La IA no elige lo mejor: elige lo más probable. Y lo más probable es lo antiguo. ⚠️ El problema real es que Swift 6 ya está aquí con su concurrencia estricta. Y ese código con DispatchQueue que "funciona" hoy, es un monstruo lleno de data races, errores de Sendable y crashes aleatorios que nadie sabrá de dónde vienen. Porque compilar no significa que esté bien. Significa que el compilador no ha encontrado errores de sintaxis. Nada más. La semántica, la arquitectura, la corrección... eso lo tienes que supervisar tú. O alguien tendrá que pagarlo en el futuro no muy lejano. 🤔 La IA es un junior con esteroides: escribe rápido, pero necesita supervisión constante. Si no sabes qué es MainActor, qué implica Sendable, o por qué await no es solo azúcar sintáctico... no estás usando la IA. La IA te está usando a ti. Y tu código se convertirá en el legado maldito que otro desarrollador heredará maldiciendo tu nombre. ¿De verdad quieres eso? 📖 Esta es la entrega I de X de posts que escribiré con ejemplos completos que podríamos llamar: "Lo que la IA hace cuando tú no miras". Hay que tomarse esto en serio, ya. ------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

📖 Ya sé Kung-Fu. En los últimos meses he trabajado en muchas cosas para llevar mi conocimiento más allá, en continuo aprendizaje. Lo último: MCP en Swift. 👨🏻‍🏫 ¿Qué es MCP? Model Context Protocol. Un estándar abierto que permite a modelos de IA conectarse de forma inteligente a tu servidor y entender tu información. 👨🏻‍💻 Me explico: imagina una búsqueda en tu app. Tienes un endpoint por APIREST al que envías una búsqueda (por ejemplo parte de un título) y hace una búsqueda de tipo LIKE para buscar algo que contenga esa cadena: la devuelves y tienes que montar la forma de responder al usuario. Como se ha hecho siempre. 🤯 Ahora redefinimos la experiencia: tienes un modelo de lenguaje conectado desde tu app y este tiene acceso a tu MCP. Esto expone qué es cada estructura y cada dato, así como todas las llamadas que tiene tu servidor y qué devuelve. Todo en lenguaje natural. ¿Para qué? Para que ahora tu usuario pregunte en lenguaje natural por tus datos, el modelo busque y presente estos también en lenguaje natural, incluyendo enlaces directos en tu app al contenido que quiere ver el usuario. ¿Mejor, no? 😳 En vez de buscar por coincidencias de un campo, la IA será capaz de leer y entender tu información, procesarla y mostrarla de forma más eficiente para que si han preguntado por cursos básicos de Swift, muestre los que específicamente son básicos por su contenido (entendiendo el contenido) y no simplemente los que tengan "swift" en su nombre. Es un cambio radical en la UX de una app. 🧐 Y sí... por supuesto que estará en nuestro módulo de Vapor y server-side en el próximo Swift Mastery Program 2026. Porque la maestría solo se puede conseguir teniendo la cualificación que nadie más tiene para convertirte en un profesional único de último nivel que buscan las empresas. ¿Te apuntas? --------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

🤷🏻‍♂️ Cada día más pruebas de lo obvio: hoy la IA no sirve si no hay alguien detrás controlando. Es como dar una cámara DSLR profesional de 6.000€ a alguien que usa el modo AUTO porque no sabe fotografía: no tiene sentido. 👨🏻‍🏫 En manos de un Maestro que sepa y entienda el código su uso es increíble. Ayer, en una sesión de trabajo de 1 hora, la IA montó un sistema basado en AVAssetResourceLoaderDelegate para descargar los podcasts en segundo plano y que Be Native permita oírlos sin conexión a internet, como hace Apple Podcast. Una forma en que los recursos aparecen incluso en los Settings de la app. Pero... ¡sorpresa! La API no es aun concurrente (no podía saberse 😓) 🙈 ¿Qué hizo Claude Code? Marcar todo lo que pudo como nonisolated(unsafe), o sea desactivo la concurrencia y que sea lo que Jobs quiera, y marcar por allende Sendable no chequeados y, por supuesto, no podía faltar: ¡su maravilloso @preconcurrency a todo el import de AVFoundation! ¿Funcionaba? Sí claro... funcionaba. Hasta que alguien le de por poner más de un podcast a la vez o el sistema acceda a la cachés, o se pisen descargas pasadas o futuras o se sume más de una instancia tirando a la vez y... ¡PUM! Cuelgue. Sin olvidar que funcionaba con 9 warnings como 9 soles. 🤔 Conmigo detrás dando instrucciones, le prohibí el uso de caminos fáciles y le dije: "Los problemas de concurrencia se RESUELVEN, JAMÁS se EVITAN" (le dije que guardara eso en su memoria del proyecto). Le guié para que hiciera un actor, para que los delegados los marcara nonisolated (porque obliga el protocolo), que dentro usará un Task para manejar los componentes del actor, que saltará de forma segura entre contexto de aislamientos con await, que usara struct en vez de class donde debería para que los datos fueran Sendable... al final: compilado sin warnings ni errores en concurrencia estricta de una funcionalidad que no está preparada. Donde ella ha preparado el código y tú has guiado. 🤯 Eso es ser eficiente: eso es ser fotógrafo y sacar oro de la cámara de 6.000€ porque sabes usar la herramienta para exprimirla al máximo. Si no eres el Maestro... prepárate para código basura, lleno de problemas de rendimiento, seguridad y estabilidad. Que funcione no significa que esté bien hecho. --------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼

Así es como nuestros alumnos enfrentan el reto de una nueva clase, en esta última semana que encaramos del Swift Developer Program... hasta que haga isla.

🤯 Approachable Concurrency. Default Actor Isolation. Strict Concurrency Checking. ¿Te suenan? 🧭 Aquí va tu chuleta definitiva, la que te vas a guardar para consultar cada vez que inicies o migres un proyecto. 📋 LA CHULETA DE CONFIGURACIÓN 1️⃣ SWIFT LANGUAGE MODE → Swift 5: Concurrencia opcional, tú decides el nivel → Swift 6: Concurrencia estricta SIEMPRE (complete), errores en lugar de warnings 2️⃣ STRICT CONCURRENCY CHECKING (solo disponible en Swift 5) → Minimal: Solo comprueba Sendable donde lo hayas marcado explícitamente → Targeted: Comprueba Sendable y actor-isolation donde uses concurrencia → Complete: Comprueba TODA la concurrencia en TODO el módulo (esto es Swift 6) 3️⃣ APPROACHABLE CONCURRENCY (novedad Xcode 26) → Yes: Activa automáticamente "Infer Isolated Conformances" + "nonisolated(nonsending) by default" y hasta 5 opciones que ayudan a que el trauma sea más pasajero. → No: Desactivado (valor por defecto en proyectos nuevos, aunque Apple recomienda Yes) 4️⃣ DEFAULT ACTOR ISOLATION (novedad Xcode 26) → MainActor: TODO tu código aislado en MainActor por defecto (proyectos nuevos) → nonisolated: Sin aislamiento por defecto (proyectos existentes) 🎯 ESCENARIOS PRÁCTICOS Proyecto NUEVO con Xcode 26: Language Mode: Swift 6 Approachable Concurrency: Yes (recomienda Apple) Default Actor Isolation: MainActor Resultado: Código seguro desde día 1, errores de concurrencia detectados en compilación. Modo de concurrencia relajado y todo al Main Actor por defecto. Proyecto en MIGRACIÓN (desde Swift 5): Language Mode: Swift 5 (mantener temporalmente) Strict Concurrency: Minimal → Targeted → Complete (progresivamente) Approachable Concurrency: Yes (cuando llegues a Complete) Default Actor Isolation: nonisolated inicialmente, MainActor cuando estés listo Resultado: Migración incremental sin romper todo de golpe Proyecto LEGACY con mucho código: Language Mode: Swift 5 Strict Concurrency: Targeted (como punto intermedio) Approachable Concurrency: No (hasta que resuelvas warnings) Default Actor Isolation: nonisolated Resultado: Balance entre seguridad y pragmatismo 🔥 La realidad es que Swift 6 no te da opciones: o entiendes la concurrencia y la adoptas correctamente, o tendrás un proyecto lleno de errores que no compilará. Approachable Concurrency y Default Actor Isolation son los salvavidas que Apple te lanza para que el viaje sea menos doloroso, pero requieren que sepas exactamente qué estás haciendo. No es magia, es ingeniería. Y como en toda ingeniería: primero entiendes, luego ejecutas. Date prisa: Xcode 27 tendrá solo modo Swift 6. 🤔 ¿Cuál es tu configuración actual? ¿Ya migraste a Swift 6 o sigues en la zona de confort de Swift 5? Cuéntame tu estrategia. ------- Somos Apple Coding Academy. Formamos a empresas y desarrolladores desde la especialización para ser más competitivos y entendiendo el código. Si te gusta nuestro contenido, ve a nuestro perfil, dale a la 🔔 y síguenos. ☝🏼