Eso no es un filtro arbitrario. Es respeto por tu tiempo y por el nuestro.

¿Qué es el Swift Agentic Engineering Program 2026?

El Swift Agentic Engineering Program 2026 es un programa de formación intensivo de 60 horas en directo, diseñado para desarrolladores iOS con experiencia que quieren incorporar la codificación agéntica a su trabajo real.

No es una introducción a la IA. Es el siguiente paso para quien ya sabe programar y quiere seguir siendo relevante en un mercado que cambia rápido.

El programa cubre las herramientas que están redefiniendo el trabajo del desarrollador iOS:

• Claude Code
• Codex
• Open Code
• Coding Intelligence en Xcode 26

Y lo hace bajo un pilar metodológico concreto: el Spec Driven Development. El enfoque que convierte tu conocimiento de arquitectura en la única ventaja competitiva que la IA no puede reemplazar. Quien entiende lo que construye dirige el proceso. El que no, espera a que la IA adivine. Y eso se nota en el resultado.

Aplicaciones reales. Arquitectura real. Trabajo de consultora.

El programa no trabaja sobre ejercicios artificiales. A lo largo de las 60 horas construiremos varias aplicaciones completas: con su arquitectura definida, concurrencia estricta en Swift 6 y consumo de APIs reales. El tipo de trabajo que harías en una consultora profesional, no en un tutorial de YouTube.

Y lo construiremos apoyándonos en las propias herramientas que desarrollamos durante la formación. El MCP Server que creas en las primeras sesiones no queda guardado en un repositorio de prácticas: lo usas activamente en el resto del programa para trabajar de forma más eficiente, más precisa y más tuya. Así es como se aprende a integrar la IA en un flujo de trabajo real: usándola, no solo explicándola.

El proyecto central: tu propio MCP Server en Swift

La pieza más importante del programa no es un ejercicio de clase. Es una herramienta profesional que construyes tú y que puedes aplicar desde el primer día en cualquier proyecto real.

El SAEP incluye el desarrollo de un MCP Server en Swift: nativo, privado, completamente tuyo. Con búsqueda semántica por embeddings que indexa toda la documentación de tu empresa en tu propia infraestructura, sin coste de servicios externos y sin que tus datos salgan a ningún sitio.

Es la diferencia entre usar herramientas de IA de propósito general y tener una herramienta construida a medida para tu entorno de trabajo. Una ventaja real, no un ejercicio académico.

Foundation Model Framework: el LLM de Apple dentro de tu app

Una de las piezas más potentes del programa es Foundation Model Framework. El modelo de lenguaje propio de Apple, ejecutándose directamente en el dispositivo. Sin llamadas a API, sin coste por token, sin conexión a internet. Genera contenido, crea structs tipados y ejecuta las funciones de tu app a partir de lenguaje natural. Una implementación que parece magia y que llevará tu app un paso más allá de forma generativa, 100% offline y sin costes ocultos.

Para quién es esta formación

El SAEP está pensado para el desarrollador iOS que quiere seguir siendo relevante, no para el que espera a que el mercado le obligue a ponerse al día.

Si llegas al examen de acceso y lo superas, esta formación es para ti. Si no tienes la base técnica necesaria, el programa no va a funcionar de la misma manera, y ser honesto con eso también es parte de la propuesta.

Qué no es el Swift Agentic Engineering Program

No es un webinar gratuito que esconde un proceso de venta al final. No es formación genérica sobre IA válida para cualquier perfil técnico. Y no te va a enseñar a construir la misma aplicación que otros 1.500 desarrolladores suben cada día sin que nadie la distinga.

Es específico, es exigente, y está pensado para quien ya tiene criterio técnico y quiere aplicarlo en el contexto de la IA agéntica.

Acceso al programa

El proceso empieza con el examen de admisión de 12 preguntas. Si lo superas, entras. Si tienes dudas sobre si esta formación es para ti, revisa primero el contenido completo del programa.

Ver el Swift Agentic Engineering Program 2026

La entrada Swift Agentic Engineering Program 2026: formación en IA para desarrolladores iOS que ya saben programar se publicó primero en Apple Coding Academy.

Liquid Glass y Foundation Model Framework. Dos anuncios que, vistos por separado, son enormes. Vistos juntos, redefinen para qué va a servir un desarrollador Apple en los próximos años.

Liquid Glass: cuando el diseño deja de ser decoración

Apple no cambia el lenguaje visual de sus sistemas a menudo. El último gran salto fue el diseño plano de iOS 7 en 2013. Antes de eso, el skeuomorfismo que simulaba materiales físicos en pantalla. Doce años después, Liquid Glass.

No es un cambio estético. Es un cambio de paradigma. La interfaz deja de ser una superficie opaca y se convierte en algo que responde a la luz, al contenido que hay debajo, al contexto del usuario. Para un desarrollador que lleva años trabajando con SwiftUI, esto significa que muchas de las suposiciones sobre cómo construir interfaces tienen que replantearse por completo.

Y eso, lejos de ser un problema, es exactamente el tipo de reto que hace que este ecosistema siga siendo emocionante después de tanto tiempo.

La sesión más importante de diseño este año es la que explica los principios detrás de Liquid Glass. No para copiar el estilo de Apple sin criterio, sino para entender el razonamiento. Porque cuando entiendes por qué Apple toma una decisión de diseño, empiezas a tomar mejores decisiones en tus propias apps. Y esa es exactamente la diferencia entre un desarrollador que sigue instrucciones y uno que tiene criterio.

Foundation Model Framework: la IA que no manda tus datos a ningún servidor

Esto es lo que más nos ha cambiado el año internamente. Foundation Model Framework es la capacidad de ejecutar modelos de lenguaje directamente en el dispositivo, sin llamadas a servidores externos, con la privacidad como garantía de Apple por defecto.

Para quienes llevamos años hablando de inteligencia artificial en el contexto del desarrollo Apple, este anuncio tiene una dimensión que va mucho más allá de lo técnico. Significa que cualquier desarrollador iOS puede, a partir de ahora, integrar inteligencia real en sus apps sin depender de APIs de terceros, sin costes por petición, sin latencia de red. Solo el chip A-series haciendo lo que mejor sabe hacer.

¿Es un modelo on-device mejor o peor que GPT-4? La pregunta está mal planteada. Son herramientas para contextos diferentes. Un modelo que corre en tu iPhone y que no envía tus datos a ningún servidor es, para la mayoría de casos de uso reales, exactamente lo que necesitas. Y añade algo que ninguna API externa puede garantizarte: funciona sin conexión.

Las sesiones que no te puedes perder

Ocho años de WWDC nos dan perspectiva para separar el ruido de lo que importa de verdad. Este año la WWDC no ha sido la más extensa en número de sesiones, pero sí una de las más relevantes en impacto. Estas son, en nuestra opinión, las imprescindibles:

Diseño con Liquid Glass. Empieza por «Designing with the new look of Apple platforms» antes de tocar una sola línea de código. Comprender la dirección estética primero ahorra horas de trabajo después.

Foundation Model Framework: introducción y sesiones avanzadas. Tres sesiones, densas, necesarias. Si solo vas a ver tres cosas de la WWDC 25, que sean estas. La IA ya no es un extra que puedes ignorar si desarrollas para Apple.

Swift 6.1 y concurrencia estricta. La concurrencia sigue siendo el tema que más preguntas genera en nuestros programas. La sesión «Embrace Swift Concurrency» es la mejor explicación oficial hasta la fecha. Si aún no has cerrado tu migración a Swift 6, este es el año.

SwiftUI: animaciones y navegación. Cada año Apple expande SwiftUI de forma significativa. Este año el foco está en las transiciones de navegación y las animaciones. El resultado es que construir experiencias fluidas que antes requerían UIKit ahora son nativas en SwiftUI.

Xcode y herramientas. Las mejoras en el compilador y en el depurador de concurrencia son sustanciales. Dedica tiempo a conocer las nuevas capacidades antes de la temporada de actualizaciones de septiembre.

Por qué la WWDC importa más allá de las novedades

En Apple Coding Academy no enseñamos tecnología. Enseñamos a pensar como un desarrollador Apple. Y la WWDC es, cada año, el documento más importante que Apple publica sobre qué significa exactamente eso.

Los desarrolladores que han pasado por nuestros programas llevan este ritmo integrado: WWDC en junio, comprensión de las nuevas APIs durante el verano, apps actualizadas antes de que lo haga la competencia. No porque seamos rápidos. Porque entendemos la dirección antes de que se convierta en obligación.

Liquid Glass y Foundation Model Framework son los temas del curso 2025-2026. No como novedades que hay que añadir al temario. Como el nuevo estándar.

Quien los domine primero, tendrá una ventaja que los demás tardarán años en recuperar.

La entrada La WWDC 25 y el año en que Apple cambió las reglas para siempre se publicó primero en Apple Coding Academy.

Eso no es un dato estadístico. Es una declaración de intenciones de Apple sobre qué tipo de software quiere en su ecosistema.

Qué significa «calidad» en el desarrollo iOS

La palabra calidad es de esas que todo el mundo usa y nadie define. En el contexto del desarrollo de apps para Apple, calidad tiene una traducción muy concreta: una app de calidad es aquella que hace exactamente lo que promete, sin que el usuario tenga que pensar en cómo hacerlo, y que lo hace igual de bien en un iPhone 16 Pro que en un iPhone 13 Mini con la batería al 20% y cinco apps abiertas en segundo plano.

Me explico: la calidad no es una capa que se añade al final del proceso. No es el momento en el que se «pule» la app antes de enviarla a revisión. Es una decisión que se toma en la primera línea de código y que se refleja en cada decisión de arquitectura, en cada llamada a red, en cada transición de pantalla.

Y aquí está el problema real: nadie te lo dice cuando empiezas. Nadie te advierte de que una arquitectura mal planteada en la primera semana de desarrollo se convierte en deuda técnica que pagarás durante años. Que un hilo principal bloqueado durante 16 milisegundos se nota. Que el usuario no sabe por qué la app «va pesada», pero lo siente, y desinstala.

El 17% que falló por diseño dice más de lo que parece

Volvamos a los datos. Un 17% rechazado por diseño. A primera vista parece poco, pero hay que entender qué significa «rechazado por diseño» en los criterios de Apple: interfaces que no cumplen las Human Interface Guidelines, navegación confusa, elementos que no responden al toque de forma esperada, texto ilegible en condiciones de luz real.

Diseño, en este contexto, no es si los colores son bonitos. Es si la app respeta los modelos mentales del usuario. Si donde el usuario espera un botón, hay un botón. Si el flujo de navegación sigue una lógica que alguien que no ha visto la app nunca pueda entender en menos de diez segundos.

Apple lleva décadas construyendo esas expectativas en sus usuarios. Cuando tu app las rompe, aunque sea ligeramente, el usuario siente que algo está mal aunque no sepa exactamente qué. Y esa sensación es difícil de superar con cualquier cantidad de funcionalidades nuevas.

La cultura de calidad que diferencia el ecosistema Apple

Hay una razón por la que una app bien construida para iOS tarda más en desarrollarse que una equivalente para otras plataformas. No es ineficiencia. Es estándar.

Apple ha creado en sus usuarios una expectativa de pulido que no existe de la misma forma en ningún otro ecosistema. Esa expectativa es simultáneamente la mayor exigencia para el desarrollador y su mayor ventaja competitiva. Porque si consigues construir algo que cumple ese estándar, tienes algo que el usuario va a querer pagar.

En AC Academy llevamos años viendo la diferencia entre desarrolladores que entienden esto desde el principio y los que lo descubren tarde. Los primeros construyen con cuidado desde el primer commit. Los segundos pasan los últimos meses de desarrollo intentando reparar decisiones que tomaron cuando aún no entendían las consecuencias.

La calidad no es el objetivo final del desarrollo. Es la condición de partida.

Qué hacer con esta información

Si estás desarrollando ahora mismo una app o si estás aprendiendo a hacerlo, guarda estos tres principios:

El hilo principal es sagrado. Nunca hagas trabajo pesado en el hilo principal. Cualquier operación que pueda tardar más de unos pocos milisegundos va al fondo, en concurrencia. Si aún no dominas async/await en Swift, eso es lo primero que tienes que resolver.

Mide antes de optimizar. Instruments existe para algo. Usa el Time Profiler antes de decidir que algo «va lento». El cuello de botella casi nunca está donde crees que está.

El diseño no empieza en Figma. Empieza en las Human Interface Guidelines de Apple. Son públicas, están actualizadas y son el documento más valioso que un desarrollador iOS puede leer antes de abrir Figma.

El 64% de los rechazos por rendimiento no es un problema de habilidad técnica. Es un problema de cultura. Y la cultura se construye desde el primer día.

La entrada El 64% de las apps que Apple rechaza fallan por lo mismo. ¿Sabes qué es? se publicó primero en Apple Coding Academy.

Programación Orientada a Protocolos

🤔 La orientación a objetos (OOP) ha sido el estándar durante años, pero también presenta limitaciones, especialmente en cuanto a la herencia. Este paradigma puede ser rígido cuando tratamos de construir componentes reutilizables y multipropósito, ya que, en muchos casos, encajar los elementos en una jerarquía de clases puede ir en contra de la flexibilidad y modularidad que buscamos. POP resuelve estos problemas.

⚙️ En la programación orientada a protocolos, en lugar de centrarnos en la herencia de clases, diseñamos nuestras soluciones basándonos en funcionalidades específicas. Los protocolos actúan como contratos que cualquier tipo puede adoptar, sin las limitaciones de una estructura rígida. Y con las extensiones, podemos agregar código por defecto, lo que facilita aún más la creación de módulos reutilizables y componentes escalables. Esto nos permite hacer que nuestros proyectos sean mucho más flexibles y con menos dependencias. Y podemos heredar protocolos, pero como suma de requisitos.

🚀 Usar POP supone, además, re-pensar todo desde cero. No basta con tomar los conceptos de la OOP y aplicarlos aquí, porque este paradigma requiere un cambio completo de mentalidad. Pero una vez que logras integrar esta forma de pensar en tu flujo de trabajo, descubres un potencial enorme para crear estructuras de datos complejas, potentes y ligeras.

💡 En conclusión, POP es una herramienta moderna, flexible y eficaz que cada vez más desarrolladores están adoptando y que en nuestras formaciones como el próximo Swift Mastery Program es pivote central: por algo Swift es un lenguaje orientada a protocolos y no a objetos. ¿Lo has usado ya en tus proyectos?

La entrada Programación Orientada a Protocolos se publicó primero en Apple Coding Academy.

Así que lo digo yo: el desarrollo multiplataforma es un compromiso. No una solución, no el futuro, no la manera inteligente de llegar antes al mercado. Un compromiso. Y como todo compromiso, tiene un precio que alguien acaba pagando.

Qué significa «multiplataforma» en la práctica

Flutter, React Native, .NET MAUI: distintas implementaciones del mismo principio. Escribe el código una vez, despliégalo en iOS y Android. En teoría, eficiencia máxima. En la práctica, una capa de abstracción entre tu código y el sistema operativo que se manifiesta de maneras que no anticipas hasta que ya es tarde.

El rendimiento es el primero. No siempre es crítico, no siempre es perceptible para el usuario casual. Pero está ahí. Las animaciones tienen ese milisegundo de más que el usuario de iOS nota aunque no sepa nombrarlo. El arranque tarda un poco más. El consumo de memoria es mayor. En un iPhone 16 Pro con suficiente RAM, quizás no importa. En el dispositivo de hace tres años de tu abuela, importa mucho.

El segundo es el acceso a las APIs del sistema. Cada vez que Apple lanza una API nueva en la WWDC, los frameworks multiplataforma tardan meses en tener soporte. A veces un año. A veces nunca. ¿Quieres integrar Foundation Model Framework, las nuevas animaciones de Liquid Glass, las funcionalidades de watchOS del año que viene? Espera. O escribe el código nativo de todas formas, que es exactamente lo que querías evitar.

El tercero es más sutil: la experiencia de usuario. Las apps nativas se sienten como apps nativas porque respetan los patrones de interacción del sistema operativo. El gesto de deslizar para volver, las transiciones entre pantallas, el comportamiento del teclado, la integración con el sistema de notificaciones. Cosas pequeñas que, sumadas, crean la diferencia entre una app que parece de Apple y una que parece un portal web disfrazado.

Cuándo el desarrollo multiplataforma sí tiene sentido

Sería deshonesto decir que nunca tiene sentido. Tiene sentido cuando la app es fundamentalmente un formulario con datos. Cuando la lógica de negocio es simple y el diseño no es diferencial. Cuando el presupuesto y el tiempo son genuinamente limitados y las funcionalidades avanzadas del sistema no son necesarias.

Una app interna para la gestión de almacén de una empresa mediana no necesita ser nativa. Una app de reservas con un calendario y un perfil de usuario probablemente tampoco. No todo tiene que ser una obra de arte del ecosistema Apple.

Pero si tu app es tu producto, si la experiencia de usuario es tu diferencia competitiva, si quieres integrar lo que Apple lanza cada año antes que la competencia, si quieres publicar en el App Store y que Apple no la rechace por problemas de rendimiento en los primeros meses, entonces el debate entre nativo y multiplataforma ya no es un debate. Es una decisión tomada.

Por qué en AC Academy enseñamos Swift

No enseñamos Swift porque seamos fundamentalistas de la plataforma. Lo enseñamos porque nuestro objetivo no es que nuestros alumnos sepan usar un framework. Nuestro objetivo es que entiendan el sistema operativo lo suficientemente bien como para construir cualquier cosa sobre él.

Un desarrollador que entiende Swift y SwiftUI puede aprender React Native en semanas si el proyecto lo requiere. La inversa no siempre es cierta. Alguien que ha aprendido desarrollo móvil a través de un framework de abstracción tiene un techo que los desarrolladores nativos no tienen.

Y hay algo más que rara vez se menciona: el mercado laboral para desarrolladores iOS nativos en España, y especialmente en empresas internacionales con equipos remotos, sigue siendo un mercado donde la demanda supera a la oferta. No hay suficientes buenos desarrolladores Swift. Eso tiene consecuencias directas en los salarios y en la empleabilidad a largo plazo.

El desarrollo multiplataforma no es el enemigo. Es una herramienta con un caso de uso específico. El problema no es usarla. El problema es usarla cuando no es la herramienta correcta, y no darte cuenta hasta que ya llevás dos años de deuda técnica encima.

La entrada La verdad sobre el desarrollo multiplataforma que no te cuentan en ninguna charla de ventas se publicó primero en Apple Coding Academy.

Esto no es un artículo de opinión sobre cuál es mejor. Es una guía sin marketing para entender qué es cada cosa y en qué situación tiene sentido cada una.

Desarrollo híbrido: la web dentro de una app

Un app híbrida es, en esencia, una aplicación web empaquetada dentro de un contenedor nativo. Frameworks como Ionic, Cordova o Capacitor te permiten construir con HTML, CSS y JavaScript una interfaz que después corre en un WebView dentro de la app.

La ventaja es obvia: si ya sabes desarrollo web, puedes construir algo que se instale en el móvil sin aprender Swift ni Kotlin. La desventaja es igualmente obvia en cuanto usas la app: se siente como una web. Porque es una web. El acceso al hardware del dispositivo es limitado, el rendimiento depende del motor del navegador y la experiencia de usuario raramente se integra de forma natural con los patrones del sistema operativo.

¿Tiene casos de uso legítimos? Sí. Aplicaciones empresariales internas donde la experiencia visual no es crítica, herramientas de productividad simple, apps de catálogo. Donde no tiene sentido es en cualquier app que vaya a competir en el App Store por la atención del usuario.

Desarrollo multiplataforma: un lenguaje, dos sistemas

Aquí la cosa se complica, porque bajo el paraguas de «multiplataforma» conviven aproximaciones muy distintas en calidad y filosofía.

Flutter (Google) compila a código nativo y dibuja su propia interfaz con un motor de renderizado propio. El resultado es un rendimiento considerablemente mejor que el híbrido y una consistencia visual notable, aunque el estilo visual puede diferir de las convenciones de cada plataforma. React Native (Meta) usa un puente JavaScript que llama a componentes nativos reales: más fiel a la apariencia del sistema, pero con el overhead del puente y actualizaciones que siempre van por detrás de las APIs del sistema.

.NET MAUI (Microsoft) es la evolución de Xamarin: usa C# y compila a código nativo por plataforma. Es la opción preferida de equipos que ya trabajan en el ecosistema Microsoft.

Lo que comparten todos: dependen de que terceros implementen soporte para las nuevas APIs del sistema. Cuando Apple presenta algo nuevo en la WWDC, los desarrolladores nativos pueden usarlo en semanas. Los equipos multiplataforma esperan meses. A veces un año. A veces el soporte nunca llega con la misma profundidad.

Desarrollo nativo: sin intermediarios

Nativo significa escribir en el lenguaje del sistema operativo, con las herramientas del fabricante, accediendo directamente a todas las APIs disponibles sin ninguna capa de abstracción.

Para iOS: Swift con SwiftUI (o UIKit para apps con requisitos específicos). Para Android: Kotlin con Jetpack Compose. Para Apple en general: Swift en todas sus plataformas, desde iOS hasta macOS, tvOS y visionOS.

El precio es el mismo código no funciona en Android. Necesitas dos equipos o un equipo que sepa ambas plataformas, o decides especializarte en una. El beneficio es acceso completo al hardware, rendimiento máximo, integración perfecta con el sistema y capacidad de adoptar cualquier API nueva el mismo día que Apple la publica.

Cómo elegir sin que te influya el marketing

Hay tres preguntas que definen la decisión:

¿La experiencia de usuario es tu diferencia competitiva? Si tu app compite por la atención del usuario en el App Store, si el diseño y el rendimiento son parte de tu propuesta de valor, la respuesta es nativo. Sin excepciones.

¿Necesitas acceder a hardware o APIs específicas de Apple? Face ID, el Secure Enclave, HealthKit, ARKit, Foundation Model Framework. Si tu app necesita cualquiera de estas cosas en profundidad, el desarrollo nativo no es una opción, es un requisito.

¿Cuál es el ciclo de vida real de esta app? Una app interna con un año de vida esperado tiene otros criterios que una app de producto que vas a mantener cinco años. La deuda técnica de los atajos se paga con el tiempo. Cuanto más larga sea la vida de la app, más caro sale no haberla construido bien desde el principio.

No hay una respuesta universal. Pero sí hay una regla: elige la tecnología en función de los requisitos reales de tu proyecto, no del framework que ya conoces o del que alguien te presupuestó más barato.

La entrada Híbrido, multiplataforma o nativo: la guía sin marketing para tomar la decisión correcta se publicó primero en Apple Coding Academy.

Lo que más nos ha enseñado ese tiempo no es sobre Swift ni sobre Xcode. Es sobre quién aprende a programar y quién no. Y la respuesta, invariablemente, no tiene nada que ver con el perfil técnico de partida.

El problema no es la dificultad. Es el relato.

La tecnología, y en particular el desarrollo de software, ha construido durante décadas un relato de exclusividad que no tiene ninguna justificación técnica. El estereotipo del desarrollador como un perfil de características muy específicas (joven, masculino, con cierta inclinación hacia las matemáticas desde la infancia) no es una descripción de quién puede programar. Es una descripción de quién llegó primero al campo cuando nadie explicaba bien que había sitio para todos.

En España, la proporción de mujeres en carreras de ingeniería informática lleva años estancada alrededor del 12-15%. No porque las mujeres tengan menos capacidad para programar (los resultados en nuestros programas no muestran ninguna diferencia sistemática en rendimiento). Porque nadie les dijo a tiempo que era una opción para ellas, y porque el entorno en el que se aprende programación en la mayoría de los centros educativos sigue siendo un entorno que no invita.

Lo que sí funciona, según lo que hemos visto

La curiosidad se activa cuando el problema a resolver tiene sentido para quien lo resuelve. Eso parece obvio pero raramente se aplica en la enseñanza de programación. Los ejercicios abstractos («calcula el factorial de n») no conectan con la motivación real de la mayoría de las personas que aprenden a programar. Lo que conecta es construir algo que puedas usar, que puedas enseñar, que resuelva un problema que tú tenías.

Swift Playgrounds es uno de los mejores ejemplos de que esto funciona en la práctica. Apple diseñó una herramienta que permite explorar programación de forma visual, iterativa y con resultados inmediatos. No es casualidad que sea la herramienta que más se usa en los programas de Apple de introducción a la programación en colegios.

Pero la herramienta sin el entorno no basta. Lo que marca la diferencia entre alguien que abandona en las primeras semanas y alguien que continúa no es la aptitud. Es si tiene a alguien que le diga, cuando se atasca, que atascarse es parte del proceso y no una señal de que esto no es para ellos. Esa persona puede ser un docente, un compañero, un mentor o una comunidad. Lo que no puede ser es nadie.

Las STEM como vocación, no como destino

Hay un error de framing en cómo se presentan las carreras STEM a los estudiantes más jóvenes. Se presentan como un destino («estudia ingeniería y tendrás trabajo») cuando lo que realmente engancha a la gente en la tecnología es el proceso, no el destino.

Nadie aprende a programar porque quiera un trabajo estable. Aprende porque en algún momento construyó algo que funcionó y esa sensación fue adictiva. La primera app que corre en tu propio dispositivo, la primera función que hace exactamente lo que le pediste, el primer bug que llevas horas persiguiendo y que de repente entiendes. Esos momentos no tienen que ver con el sector ni con el salario. Tienen que ver con la satisfacción de construir.

Esa es la historia que hay que contar a los estudiantes. No la del mercado laboral ni la de la brecha salarial ni la de las estadísticas de contratación. La historia de que programar es construir, y construir es una de las actividades más fundamentalmente humanas que existen. El lenguaje cambia (hoy es Swift, mañana será otro), pero la capacidad de convertir una idea en algo que funciona no caduca nunca.

Lo que ocho años nos han confirmado

Cualquiera que quiera aprender a desarrollar puede aprender a desarrollar. No cualquiera en cualquier circunstancia: necesitas tiempo, necesitas acceso a herramientas, necesitas un entorno que no te haga sentir que estás en el sitio equivocado. Pero no hay ningún requisito de partida que sea innegociable salvo la motivación.

Las personas que llegan a AC Academy sin experiencia previa y con más dudas que certezas sobre si esto es para ellas son, con frecuencia, las mismas que un año después trabajan como desarrolladoras en empresas reales. Eso no es un argumento de ventas. Es lo que hemos visto repetirse suficientes veces como para creerlo sin reservas.

El talento está distribuido de forma bastante uniforme en la población. La oportunidad, todavía no.

La entrada Lo que ocho años formando desarrolladores nos han enseñado sobre quién aprende a programar (y quién no) se publicó primero en Apple Coding Academy.

Los datos dicen lo contrario. Los desarrolladores iOS ganan sistemáticamente más, las apps de iOS generan considerablemente más ingresos en el App Store que sus equivalentes en Google Play, y las empresas que quieren desarrolladores nativos de calidad encuentran más dificultad para cubrir posiciones iOS que Android. Explícame eso.

El mercado no es el usuario

La cuota de mercado de Android es real pero engañosa como indicador económico. El 76% del parque mundial de smartphones Android incluye dispositivos que cuestan 80 euros en mercados emergentes donde la app economy funciona de forma completamente diferente. Muchos de esos usuarios no compran apps. Muchos de esos mercados tienen una capacidad de gasto por usuario que es una fracción de la del usuario iOS medio.

El usuario de iOS tiene, estadísticamente, mayor poder adquisitivo, mayor disposición a pagar por apps de calidad y mayor retención en las plataformas de suscripción. No es un prejuicio: es el dato que explica por qué muchos estudios de desarrollo priorizan iOS aunque Android tenga más dispositivos activos. Un 22% del mercado con una conversión a pago mucho mayor puede generar más ingresos que un 76% con una conversión menor.

El ecosistema lo es todo

Hay otro factor que los números de cuota de mercado no capturan: el ecosistema de Apple es uno solo. Un desarrollador que sabe Swift puede construir para iPhone, iPad, Mac, Apple Watch, Apple TV y Vision Pro con el mismo lenguaje, las mismas herramientas y una gran parte del mismo código.

Eso no tiene equivalente en Android. El universo de Android es una fragmentación de fabricantes, versiones del sistema operativo y resoluciones de pantalla que hace que el desarrollo y el testing sean considerablemente más complejos. No imposibles, pero más complejos.

Para una empresa que quiere estar en el ecosistema Apple con presencia en todas las plataformas del fabricante, un desarrollador iOS senior es más valioso de lo que el 22% de cuota de mercado sugiere. Puede cubrir seis plataformas. Eso tiene un precio en el mercado laboral.

El mercado laboral en España y en remoto

En España el mercado de desarrolladores iOS nativo es, desde hace años, un mercado donde la demanda supera a la oferta. Las empresas que buscan desarrolladores Swift de calidad tienen dificultad para encontrarlos. Las que trabajan en remoto para clientes internacionales aún más.

Eso tiene una consecuencia directa: los salarios de los desarrolladores iOS senior en España están por encima de la media del sector de desarrollo, y en posiciones remotas para empresas de fuera de España la diferencia es todavía más pronunciada.

La escasez de buenos desarrolladores iOS no es temporal. Es estructural. Lleva años siendo así y no hay señales de que vaya a cambiar pronto. Y en gran parte tiene que ver con que la barrera de entrada para hacer las cosas bien en iOS es más alta que en Android o en multiplataforma. Eso protege a quienes la han superado.

Entonces, ¿iOS o Android?

La pregunta tiene una respuesta simple si se reformula: ¿quieres especializarte en el ecosistema con más demanda insatisfecha de talento, los salarios más altos del segmento y la posibilidad de cubrir seis plataformas del fabricante más valorado del mundo con un solo lenguaje? Pues ya está.

Eso no significa que Android sea una mala opción. Es una opción perfectamente válida con su propio mercado, su propia demanda y sus propios casos de uso. Pero si la pregunta es en qué especializarse cuando partes de cero, los datos apuntan en una dirección bastante clara.

El 76% de cuota de mercado de Android es un dato impresionante. No es el dato relevante para decidir dónde construir tu carrera como desarrollador.

La entrada Android tiene el 76% del mercado. Los desarrolladores iOS ganan un 40% más. ¿Cómo es eso posible? se publicó primero en Apple Coding Academy.

En 2019, Apple presentó SwiftUI. Ese segundo anuncio fue, en mi opinión, más importante que el primero. Y tardó bastante más en ser entendido.

Qué es SwiftUI y por qué importa la forma en que funciona

SwiftUI es un framework para construir interfaces de usuario de forma declarativa. Eso requiere una explicación, porque «declarativo» es una de esas palabras que el sector tecnológico usa con frecuencia sin tomarse el tiempo de explicar qué significa en la práctica.

El modelo anterior, UIKit, era imperativo: tú describías el cómo. Creabas los elementos de la interfaz, los colocabas en la pantalla, definías qué pasaba con ellos cuando el estado de la app cambiaba. El código era una secuencia de instrucciones que el sistema ejecutaba en orden. Funciona. Es poderoso. Y se convierte en complejo rápidamente cuando la interfaz tiene muchos estados posibles.

SwiftUI invierte el modelo. Tú describes el qué: cómo debe verse la interfaz dado un determinado estado de los datos. El framework se encarga de calcular qué ha cambiado y de actualizar la pantalla de forma eficiente. Cuando los datos cambian, la vista se recalcula. No tienes que gestionar la transición manualmente.

El resultado es código considerablemente más corto, más legible y más fácil de mantener. Una pantalla que en UIKit requería cien líneas de código puede expresarse en SwiftUI en veinte. No como truco de compresión sintáctica, sino porque el modelo declarativo elimina categorías enteras de código de gestión de estado que UIKit requería.

Multiplataforma de verdad, dentro del ecosistema Apple

Hay algo de SwiftUI que raramente se menciona en los artículos de introducción y que tiene implicaciones enormes para cualquier desarrollador o empresa que quiera estar presente en más de una plataforma de Apple.

El mismo código SwiftUI corre en iPhone, iPad, Mac, Apple Watch y Apple TV. No con modificaciones menores: el mismo código base, adaptándose de forma inteligente a las convenciones y capacidades de cada dispositivo. Las diferencias entre plataformas se resuelven con modificadores específicos donde es necesario, pero la lógica central de la interfaz se escribe una sola vez.

Eso es multiplataforma real: dentro del ecosistema de Apple, sin compromisos de rendimiento, con acceso completo a todas las APIs de cada plataforma. Muy diferente a la promesa del desarrollo multiplataforma que incluye Android, donde «el mismo código» implica una capa de abstracción con las limitaciones ya conocidas.

Por qué en AC Academy SwiftUI es la base del currículo

Cuando Apple presentó SwiftUI en 2019, tomamos una decisión pedagógica que no todo el mundo en la industria compartía en ese momento: enseñar SwiftUI como base, no como complemento de UIKit.

El razonamiento era simple. UIKit tiene décadas de código en producción y va a seguir siendo relevante durante años, especialmente para apps con requisitos muy específicos. Pero SwiftUI es la dirección en la que Apple lleva invirtiendo recursos desde 2019. Cada WWDC expande sus capacidades. Las herramientas de Xcode están cada vez más optimizadas para él. Los nuevos frameworks de Apple asumen que el desarrollador usa SwiftUI.

Enseñar a alguien a desarrollar para iOS hoy empezando por UIKit es como enseñar fotografía empezando por el carrete de 35mm: perfectamente válido para entender los principios, completamente desconectado de donde está el trabajo real.

Los alumnos que han pasado por nuestros programas aprenden SwiftUI desde el primer día. Cuando necesitan entender UIKit para un proyecto específico o para trabajar con código heredado, tienen la base conceptual para hacerlo. La inversa no siempre funciona igual de bien.

SwiftUI en 2026: el estado de la cuestión

En 2026, SwiftUI ya no es el futuro prometedor que era en 2019. Es el estándar actual. Las apps nuevas que se construyen para el ecosistema Apple se construyen con SwiftUI salvo que haya una razón técnica muy específica para no hacerlo. Las apps existentes en UIKit se migran progresivamente.

Hay todavía áreas donde SwiftUI tiene limitaciones respecto a UIKit para casos de uso muy específicos. Son cada vez menos, y cada WWDC cierra algunas. La trayectoria es clara.

Si estás aprendiendo a desarrollar para Apple ahora, SwiftUI no es una opción entre varias. Es el punto de partida.

La entrada SwiftUI no es el futuro del desarrollo Apple. Es el presente. Y eso lo cambia todo. se publicó primero en Apple Coding Academy.

Pues llevamos décadas haciendo exactamente eso con la programación. Y en 2026, cuando los sistemas que organizan buena parte de nuestra vida cotidiana son software, eso empieza a ser un problema que no podemos seguir ignorando.

Por qué la programación no es una habilidad técnica

El error más frecuente en el debate sobre programación en los colegios es tratarla como una habilidad técnica especializada, comparable a soldar o a calibrar maquinaria industrial. Algo útil para quien vaya a dedicarse a ello, pero prescindible para el resto.

La programación no es una habilidad técnica. Es una forma de pensar. Es la capacidad de descomponer un problema complejo en pasos más pequeños, de identificar patrones, de entender que los sistemas tienen causas y consecuencias y que esas consecuencias se pueden anticipar. Esas capacidades no son útiles solo si acabas siendo desarrollador. Son útiles en casi cualquier actividad intelectual.

Hay un dato que en AC Academy repetimos frecuentemente: muchos de los alumnos que han pasado por nuestros programas y que trabajan hoy como desarrolladores no llegaron con intención de cambiar de carrera. Llegaron porque alguien les explicó que entender cómo funciona el software los haría mejores en lo que ya hacían. Y tenían razón.

Swift como primer lenguaje: una propuesta seria

Durante años, el debate sobre qué lenguaje enseñar primero en los colegios giró entre Logo, Scratch, Python y más recientemente JavaScript. Cada uno con sus defensores y sus argumentos.

Swift tiene una ventaja que sus competidores no tienen: fue diseñado explícitamente para ser aprendible, con una sintaxis clara que reduce el ruido y errores de compilación que explican qué está mal y por qué, no solo que algo ha fallado. Swift Playgrounds lleva esa filosofía un paso más allá: un entorno interactivo donde el resultado de lo que escribes es visible de inmediato, sin configuraciones, sin terminales, sin instalaciones complejas.

Apple ha invertido recursos considerables en desarrollar currículos para colegios alrededor de Swift y Swift Playgrounds precisamente porque entiende que el problema no es solo el lenguaje: es todo el ecosistema alrededor del aprendizaje. Un estudiante de doce años no necesita aprender a configurar un entorno de desarrollo. Necesita escribir algo, ver que funciona y querer escribir más.

El reto docente que nadie quiere resolver

Hay un obstáculo real en todo esto que los debates sobre currículos ignoran sistemáticamente: los docentes. No porque los profesores no quieran enseñar programación. Porque en la mayoría de los casos nadie les ha enseñado a ellos.

Puedes tener el mejor currículo del mundo sobre pensamiento computacional en secundaria. Si el profesor que tiene que impartirlo aprendió programación hace veinte años con C++ o directamente no ha programado nunca, el resultado va a ser deficiente. No por falta de voluntad: por falta de formación actualizada y por falta de confianza en el aula cuando el alumno hace una pregunta que se sale del guión.

La solución a esto no es ignorarlo. Es formación docente real, práctica y continua. Algo que en España, lamentablemente, sigue siendo la excepción y no la regla en lo que a tecnología en el aula se refiere.

Lo que un alumno que sabe programar puede hacer que los demás no pueden

No estamos hablando de formar a todos los estudiantes para que sean desarrolladores. Estamos hablando de algo más básico: que cuando un estudiante de cualquier disciplina llegue a la universidad o al mercado laboral, entienda qué es el software, cómo funciona y qué le puede pedir a alguien que sabe construirlo.

Un biólogo que entiende programación puede automatizar análisis que de otra forma le costarían semanas. Un periodista que entiende cómo funciona un algoritmo puede cubrir noticias sobre tecnología con rigor que hoy no existe. Un médico que entiende el software que interpreta sus diagnósticos puede hacer preguntas que de otra forma ni sabría formular.

La programación en los colegios no es una inversión en el sector tecnológico. Es una inversión en la calidad de razonamiento de toda la sociedad. Y esa es una conversación que en España llevamos demasiado tiempo aplazando.

La entrada Por qué la programación debería ser tan obligatoria como las matemáticas se publicó primero en Apple Coding Academy.