WWDC 2026 e IA en iOS: la IA ya está dentro de tu pipeline

Apple acaba de convertir Xcode en una plataforma de agentes de IA, ha abierto Foundation Models a cualquier modelo y ha reconstruido Siri sobre un modelo de Google. Te cuento qué cambia de verdad para un equipo iOS enterprise y, sobre todo, dónde está la deuda técnica que nadie te va a avisar.

La keynote de este año —la última de Tim Cook como CEO— se vendió como un WWDC de IA. Y lo es. Pero si eres CTO, VP of Engineering o Tech Lead de una app en producción, el titular que te debería quitar el sueño no es el Siri nuevo ni el modelo de billón de parámetros. Es mucho más prosaico: a partir de iOS 27, una parte creciente de tu código Swift lo va a escribir una IA, y Apple lo ha puesto carísimo de fácil.

Llevo tiempo usando agentes de IA a diario para escribir Swift, y también dedico parte de mi trabajo a auditar código iOS generado con IA antes de que llegue a producción. Desde esas dos sillas, WWDC 2026 se lee distinto. Este post se centra solo en lo que toca IA; el resumen completo de iOS 27 (Swift 6.3/6.4, SwiftUI, Liquid Glass v2, rendimiento) lo cubro en otro artículo.

El anuncio que sí cambia tu día a día: Xcode 27 es agéntico

Xcode 27 integra agentes de codificación nativos de Anthropic (Claude), Google (Gemini) y OpenAI (GPT/Codex) dentro del propio IDE. Pones tu API key, pagas al proveedor, y el agente planifica (/plan), responde en múltiples turnos, escribe y ejecuta tests, usa Playgrounds aislados, valida vistas con Previews y maneja el simulador a través de un nuevo Device Hub. Hay además Agent Skills oficiales —reglas reutilizables que guían al modelo— y soporte para Model Context Protocol (MCP), con GitHub y Figma entre los primeros conectores. Apple es explícita al respecto: presenta al agente como colaborador, no como quien decide; el criterio del ingeniero sénior tiene siempre la última palabra.

Traducido a lenguaje de negocio: Apple ha bendecido el flujo AI-first y lo ha metido en la herramienta que tu equipo abre cada mañana. Esto ya no es Cursor o Claude Code como experimento de un dev curioso; es el camino por defecto, dentro del IDE oficial.

Y aquí es donde quiero ser directo, porque es mi terreno: esto multiplica la velocidad de producción de código, pero también la velocidad de producción de deuda técnica oculta. No lo digo solo yo.

Lo que la comunidad ya está documentando (y deberías revisar)

En las semanas alrededor de la WWDC, las voces más respetadas del mundillo iOS han convergido en el mismo punto, y no es casualidad.

Antoine van der Lee (SwiftLee) publicó un análisis demoledor en vídeo: código Swift generado por IA que parecía perfecto —compilaba, se leía limpio, pasaba la revisión a ojo— hasta que Xcode Instruments destapó lo que escondía debajo. Es exactamente el patrón que veo una y otra vez cuando audito proyectos: el problema del código de IA rara vez es que no compile; es que compila y funciona en el happy path mientras filtra memoria, retiene ciclos de referencia o cruza mal los hilos en los caminos que tu QA no toca.

Donny Wals lo cuenta desde el otro lado, el del entusiasmo legítimo: se le crasheó su app a mitad de un entrenamiento, subió el crash report a su agente, y al terminar la serie tenía un pull request esperándole. Es real y es potente —y, para su mérito, Wals ha montado todo un pipeline con revisión automática y tests que corren antes del merge, precisamente para no fiarse a ciegas—. Pero fíjate en lo que ese flujo normaliza: que el primer borrador funcional de un cambio lo escriba una IA y llegue a la puerta del merge sin que ningún senior haya mirado todavía qué hace por dentro. Si no tienes el pipeline de Wals, esa puerta se queda abierta de par en par.

Y la señal de mercado más clara de todas: Paul Hudson, probablemente el mayor divulgador iOS del mundo, ha dedicado su esfuerzo de estos meses a publicar una agent skill open source para SwiftUI —parte de una colección más amplia— cuyo único objetivo es detectar y corregir los errores típicos que cometen Claude, Codex y Gemini —uso incorrecto de APIs modernas, problemas de rendimiento, accesibilidad rota—. Cuando el referente técnico de una comunidad invierte su tiempo en arreglar lo que escribe la IA, te está diciendo exactamente dónde está el problema.

La conclusión no es "la IA es mala". Yo la uso todos los días. La conclusión es que la IA ha desplazado el cuello de botella: ya no está en escribir el código, está en validar que lo que se ha escrito aguanta en producción. Y eso, en una app de banca, retail o seguros con millones de usuarios, no es opcional.

Foundation Models: ahora «cualquier LLM dentro de tu app» (y un matiz de compliance)

El año pasado Apple metió un LLM on-device en el sistema. Este año ha madurado el framework de Foundation Models hasta convertirlo en algo mucho más serio para enterprise:

• Entrada multimodal: puedes pasarle imágenes (UIImage, CGImage, buffers de vídeo, URLs de archivo) además de texto.
• Una sola API para todos los proveedores. A través de un nuevo protocolo LanguageModel, el mismo punto de llamada sirve para el modelo on-device, para Private Cloud Compute, para modelos que empaquetas tú en local sobre la Neural Engine (Core AI) o de la comunidad (MLX), y para proveedores externos —Claude y Gemini, que Anthropic y Google publicarán en breve—. Esto es enorme desde el punto de vista de arquitectura: puedes empezar on-device y escalar a cloud sin reescribir tu capa de IA.
• Dynamic Profiles: cambiar modelo, herramientas o instrucciones del sistema sobre la marcha, sin pasar por App Store review.
• Acceso fuera de Xcode: un CLI fm preinstalado en macOS 27 (fm respond/chat/schema, on-device o PCC) y un SDK de Python (Apple Silicon) para prototipar y montar pipelines de evaluación. Como el framework pasa a ser open source, corre también en Linux para Swift en servidor.
• El modelo de Private Cloud Compute es de razonamiento: ventana de contexto de 32.000 tokens y niveles de reasoning configurables —más cómputo a cambio de mejores respuestas—, sin gestionar claves ni cuentas y sin almacenar prompts.
• RAG local con Spotlight: una herramienta de búsqueda integrada que da al modelo acceso a conocimiento personal o de dominio del propio dispositivo a través del índice de Spotlight, para retrieval-augmented generation sin que los datos salgan del teléfono.
• El framework se abre: el núcleo de Foundation Models pasa a ser open source, así que usas la misma capa de IA allá donde corra Swift —incluidos servidores Linux— y la combinas con proveedores como Anthropic o Google. Menos lock-in.
• Framework de Evaluations: una API nueva para verificar que tus features de IA se comportan bien en condiciones dinámicas, más allá de lo que cazan los unit tests. Que Apple lo meta de serie confirma la tesis de este post: validar la salida de la IA ya es parte del trabajo, no un extra.
• Sin coste de API en cloud para apps inscritas en el App Store Small Business Program con menos de 2 millones de primeras descargas totales en el App Store: el modelo servidor de Private Cloud Compute queda disponible con un límite diario por usuario, ampliable con iCloud+. Se solicita en la web de desarrolladores de Apple.

// Misma llamada, distinto backend. Empiezas on-device,
// escalas a cloud sin tocar el call site.
let session = LanguageModelSession(model: .systemDefault)

let resumen = try await session.respond(
    to: "Clasifica esta incidencia y extrae los campos clave.",
    generating: ClasificacionIncidencia.self
)

Para el mercado europeo esto es relevante por una razón que va más allá de lo técnico: arquitectura GDPR-compliant por diseño. Un modelo on-device no envía datos del usuario a ningún sitio. Y cuando un caso exige escalar a Private Cloud Compute, las garantías se mantienen: los datos no se almacenan y la privacidad ha sido verificada por investigadores independientes, sin claves ni cuentas que gestionar. Es el tipo de feature de IA que un CTO puede aprobar sin sentar a su DPO en cada sprint. Si tu caso de uso lo permite —clasificación de texto, extracción de información, resúmenes—, on-device debería ser tu primera opción, no la última.

El reset del contrato: App Intents obligatorio, SiriKit deprecado

Este es el cambio que más equipos va a pillar con el pie cambiado, y es la puerta por la que la IA de Apple entra en tu app. SiriKit (2016) queda formalmente deprecado. A partir de ahora, la única forma de que Siri llegue a tu app es a través de App Intents. Las apps que no expongan App Intents son, sencillamente, invisibles para el nuevo Siri.

Hay una ventana de migración de unos 2-3 años (alrededor de iOS 29), pero no es un renombrado: es una reescritura de cómo tu app expone sus acciones al sistema. App Intents ha ganado tipos de entidad más ricos, respuestas en streaming, follow-ups multi-turno, una nueva API de anotaciones de vistas (para que Siri entienda lo que hay en pantalla) y —esto importa para regulados— manifiestos de privacidad por intent, donde declaras si una interacción puede ir a cloud o debe quedarse on-device.

struct BuscarMovimientoIntent: AppIntent {
    static let title: LocalizedStringResource = "Buscar movimiento"

    @Parameter(title: "Concepto")
    var concepto: String

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let movimientos = try await Movimientos.buscar(concepto: concepto)
        return .result(dialog: "He encontrado \(movimientos.count) movimientos.")
    }
}

Si tienes funcionalidad de voz, Shortcuts o Spotlight montada sobre SiriKit, haz inventario de ello esta semana y planifica la migración. No es trabajo de un fin de semana, y el reloj ya corre.

Y conviene leer una señal junto a todo lo anterior: este año Apple no ha sacado uno, sino dos frameworks de validación. Evaluations, para medir la salida del modelo más allá de lo que cazan los unit tests; y AppIntentsTesting, para ejercitar tus intents de forma aislada, sin Siri de por medio. La lectura es directa: la superficie que hay que validar ha crecido —del código al modelo y ahora a los intents— y Apple lo está reconociendo con tooling de serie. Y en lo agéntico hay un peldaño más: Evaluations no se queda en puntuar la salida; las trajectory expectations verifican que el modelo llama las herramientas correctas, con los argumentos correctos y en el orden correcto, y que no hace llamadas indebidas. Y no es solo cuestión de calidad: lo agéntico abre superficie de seguridad nueva —inyección de prompt indirecta, acciones con efectos colaterales—, y Apple le dedica una sesión entera, con mitigaciones como confirmaciones por nivel de riesgo y autenticación en pantalla de bloqueo.

Sobre el Siri nuevo y el modelo de Google

El titular mediático: Siri se reconstruye sobre un modelo de la familia Gemini de Google. Aquí toca separar lo confirmado de lo reporteado, porque aquí no vale tratar rumores como hechos.

Apple confirma que sus modelos de nueva generación se han construido en colaboración con Google y sus modelos Gemini, y que las consultas se anonimizan, se desligan del Apple ID y que Google tiene contractualmente prohibido entrenar con ellas. Lo que es reporte de prensa, no confirmación de Apple (vía Bloomberg / Mark Gurman): un modelo de ~1,2 billones de parámetros, un coste de ~1.000 M$/año y la ejecución en GPUs de Google Cloud. Yo lo trataría con pinzas en cualquier conversación con cliente: "Apple ha entrenado con Gemini" no es lo mismo que "Siri es Gemini".

El matiz que sí afecta a tu roadmap europeo: Siri AI no llega en el lanzamiento a la UE en iPhone y iPad (Apple cita la Digital Markets Act), y los desarrolladores europeos ni siquiera pueden probar esas features durante el desarrollo. Ojo: esto es la DMA, no la EAA —no las confundas en tus comunicaciones internas—. La buena noticia es que la API de Foundation Models sí funciona en toda la UE. Conclusión práctica: si construyes inteligencia dentro de tu app para el mercado europeo, apóyate en Foundation Models, no en flujos que dependan de Siri.

Qué haría yo si fuera tu Tech Lead esta semana

1. Poner reglas al uso de IA en el equipo, ya. Que los agentes de Xcode 27 escriban todo lo que quieran, pero que ese código pase por la misma revisión, los mismos tests y la misma auditoría que cualquier otro. Aquí es donde se gana o se pierde la calidad este año.
2. Prototipar Foundation Models on-device para un caso real (clasificación, extracción, resúmenes) detrás de un adaptador agnóstico de proveedor usando el protocolo LanguageModel. Privacidad por diseño y cero coste de API.
3. Inventariar SiriKit y planificar la migración a App Intents, con manifiestos de privacidad por intent si manejas datos regulados.

WWDC 2026 no va de un Siri más listo. Va de que Apple ha decidido que la IA escriba tu código y viva dentro de tu app, y ha bajado la barrera para que ocurra ya. La velocidad es real. El riesgo de que esa velocidad se convierta en deuda técnica invisible, también. La diferencia entre un equipo que aprovecha esto y uno que se hunde en bugs de producción no está en si usan IA —la van a usar todos—, sino en si alguien con criterio senior está mirando lo que sale.

Fuentes (sesiones WWDC 2026)

• What’s new in the Foundation Models framework
• Build with the new Apple Foundation Model on Private Cloud Compute
• Bring an LLM provider to the Foundation Models framework
• Meet the Evaluations framework
• Create robust evaluations for agentic apps
• Build intelligent Siri experiences with App Schemas
• Validate your App Intents adoption with AppIntentsTesting
• Build AI-powered scripts with the fm CLI and Python SDK
• Secure your app: mitigate risks to agentic features

---

¿Tu equipo ha empezado a generar código iOS con IA y necesitas asegurarte de que lo que llega a producción aguanta? En AtalayaSoft auditamos código Swift generado con IA y nos integramos como contractors senior en proyectos de banca, retail y seguros.

Hablemos →