WWDC 2026 and AI on iOS: the AI is already inside your pipeline

Apple has just turned Xcode into a platform for AI agents, opened Foundation Models up to any model, and rebuilt Siri on a Google model. Here's what really changes for an enterprise iOS team and, above all, where the technical debt nobody is going to warn you about is hiding.

This year's keynote — Tim Cook's last as CEO — was sold as an AI WWDC. And it is one. But if you're a CTO, VP of Engineering or Tech Lead of an app in production, the headline that should keep you up at night isn't the new Siri or the trillion-parameter model. It's far more prosaic: from iOS 27 on, a growing share of your Swift code is going to be written by an AI, and Apple has made it dirt cheap and easy.

I've been using AI agents daily to write Swift for a while now, and I also spend part of my work auditing AI-generated iOS code before it reaches production. From those two seats, WWDC 2026 reads differently. This post focuses only on the AI side; the full iOS 27 round-up (Swift 6.3/6.4, SwiftUI, Liquid Glass v2, performance) I cover in another article.

The announcement that actually changes your day-to-day: Xcode 27 is agentic

Xcode 27 integrates native coding agents from Anthropic (Claude), Google (Gemini) and OpenAI (GPT/Codex) right inside the IDE. You drop in your API key, you pay the provider, and the agent plans (/plan), responds across multiple turns, writes and runs tests, uses isolated Playgrounds, validates views with Previews and drives the simulator through a new Device Hub. There are also official Agent Skills — reusable rules that steer the model — and support for Model Context Protocol (MCP), with GitHub and Figma among the first connectors. Apple is explicit about it: it presents the agent as a collaborator, not as the one who decides; the senior engineer's judgement always has the final word.

Translated into business language: Apple has blessed the AI-first workflow and put it inside the tool your team opens every morning. This is no longer Cursor or Claude Code as a curious dev's experiment; it's the default path, inside the official IDE.

And here's where I want to be blunt, because this is my turf: this multiplies the speed at which code is produced, but also the speed at which hidden technical debt is produced. And it's not just me saying it.

What the community is already documenting (and you should review)

In the weeks around WWDC, the most respected voices in the iOS world have converged on the same point, and it's no coincidence.

Antoine van der Lee (SwiftLee) published a devastating video analysis: AI-generated Swift code that looked perfect — it compiled, read cleanly, passed an eyeball review — until Xcode Instruments exposed what it was hiding underneath. It's exactly the pattern I see over and over when I audit projects: the problem with AI code is rarely that it won't compile; it's that it compiles and works on the happy path while it leaks memory, retains reference cycles or gets threading wrong on the paths your QA never touches.

Donny Wals tells it from the other side, that of legitimate enthusiasm: his app crashed in the middle of a workout, he uploaded the crash report to his agent, and by the time he'd finished his set he had a pull request waiting for him. It's real and it's powerful — and, to his credit, Wals has built a whole pipeline with automated review and tests that run before the merge, precisely so as not to trust it blindly. But notice what that flow normalises: that the first working draft of a change is written by an AI and arrives at the merge door without any senior having looked yet at what it does inside. If you don't have Wals's pipeline, that door is left wide open.

And the clearest market signal of all: Paul Hudson, probably the biggest iOS educator in the world, has spent his effort these past months publishing an open-source SwiftUI agent skill — part of a wider collection — whose sole purpose is to detect and fix the typical mistakes Claude, Codex and Gemini make — incorrect use of modern APIs, performance problems, broken accessibility. When a community's technical reference invests his time in fixing what the AI writes, he's telling you exactly where the problem is.

The takeaway isn't "AI is bad". I use it every day. The takeaway is that AI has shifted the bottleneck: it's no longer in writing the code, it's in validating that what's been written holds up in production. And that, in a banking, retail or insurance app with millions of users, is not optional.

Foundation Models: now "any LLM inside your app" (and a compliance nuance)

Last year Apple put an on-device LLM in the system. This year it has matured the Foundation Models framework into something far more serious for enterprise:

• Multimodal input: you can pass it images (UIImage, CGImage, video buffers, file URLs) in addition to text.
• A single API for every provider. Through a new LanguageModel protocol, the same call site serves the on-device model, Private Cloud Compute, models you bundle yourself locally on the Neural Engine (Core AI) or from the community (MLX), and external providers — Claude and Gemini, which Anthropic and Google will publish shortly. This is huge from an architecture standpoint: you can start on-device and scale to cloud without rewriting your AI layer.
• Dynamic Profiles: switch model, tools or system instructions on the fly, without going through App Store review.
• Access outside Xcode: an fm CLI preinstalled on macOS 27 (fm respond/chat/schema, on-device or PCC) and a Python SDK (Apple Silicon) for prototyping and building evaluation pipelines. As the framework is going open source, it also runs on Linux for server-side Swift.
• The Private Cloud Compute model is a reasoning model: a 32,000-token context window and configurable reasoning levels — more compute in exchange for better answers — with no keys or accounts to manage and no prompt storage.
• Local RAG with Spotlight: a built-in search tool that gives the model access to personal or domain knowledge from the device itself through the Spotlight index, for retrieval-augmented generation without the data leaving the phone.
• The framework opens up: the core of Foundation Models is going open source, so you use the same AI layer wherever Swift runs — including Linux servers — and combine it with providers like Anthropic or Google. Less lock-in.
• Evaluations framework: a new API to verify that your AI features behave well under dynamic conditions, beyond what unit tests catch. The fact that Apple ships it as standard confirms this post's thesis: validating AI output is now part of the job, not an extra.
• No cloud API cost for apps enrolled in the App Store Small Business Program with fewer than 2 million total first-time downloads on the App Store: the Private Cloud Compute server model is available with a per-user daily limit, extendable with iCloud+. You request it on Apple's developer website.

// Same call, different backend. Start on-device,
// scale to cloud without touching the call site.
let session = LanguageModelSession(model: .systemDefault)

let classification = try await session.respond(
    to: "Classify this incident and extract the key fields.",
    generating: IncidentClassification.self
)

For the European market this matters for a reason that goes beyond the technical: GDPR-compliant architecture by design. An on-device model sends no user data anywhere. And when a case requires scaling to Private Cloud Compute, the guarantees hold: the data isn't stored and the privacy has been verified by independent researchers, with no keys or accounts to manage. It's the kind of AI feature a CTO can sign off without sitting their DPO down every sprint. If your use case allows it — text classification, information extraction, summaries — on-device should be your first option, not your last.

The contract reset: App Intents mandatory, SiriKit deprecated

This is the change that's going to catch the most teams on the wrong foot, and it's the door through which Apple's AI enters your app. SiriKit (2016) is now formally deprecated. From now on, the only way for Siri to reach your app is through App Intents. Apps that don't expose App Intents are, quite simply, invisible to the new Siri.

There's a migration window of around 2-3 years (somewhere around iOS 29), but this isn't a rename: it's a rewrite of how your app exposes its actions to the system. App Intents has gained richer entity types, streaming responses, multi-turn follow-ups, a new view-annotation API (so Siri understands what's on screen) and — this matters for regulated sectors — per-intent privacy manifests, where you declare whether an interaction may go to the cloud or must stay on-device.

struct FindTransactionIntent: AppIntent {
    static let title: LocalizedStringResource = "Find transaction"

    @Parameter(title: "Description")
    var description: String

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let transactions = try await Transactions.find(matching: description)
        return .result(dialog: "I found \(transactions.count) transactions.")
    }
}

If you have voice, Shortcuts or Spotlight functionality built on SiriKit, inventory it this week and plan the migration. It's not a weekend's work, and the clock is already ticking.

And it's worth reading one signal alongside all of the above: this year Apple shipped not one but two validation frameworks. Evaluations, to measure model output beyond what unit tests catch; and AppIntentsTesting, to exercise your intents in isolation, with no Siri in the loop. The reading is direct: the surface you have to validate has grown — from the code to the model and now to the intents — and Apple is acknowledging it with first-class tooling. And on the agentic side there's one more step: Evaluations doesn't stop at scoring the output; trajectory expectations verify that the model calls the right tools, with the right arguments and in the right order, and that it doesn't make calls it shouldn't. And it's not just a quality question: the agentic world opens a new security surface — indirect prompt injection, actions with side effects — and Apple devotes a whole session to it, with mitigations such as risk-based confirmations and lock-screen authentication.

On the new Siri and the Google model

The media headline: Siri is being rebuilt on a model from Google's Gemini family. Here it's worth separating what's confirmed from what's reported, because here you can't treat rumours as facts.

Apple confirms that its next-generation models were built in collaboration with Google and its Gemini models, that queries are anonymised, decoupled from the Apple ID, and that Google is contractually barred from training on them. What is press reporting, not Apple confirmation (via Bloomberg / Mark Gurman): a ~1.2-trillion-parameter model, a cost of ~$1bn/year and execution on Google Cloud GPUs. I'd treat that with caution in any conversation with a client: "Apple trained with Gemini" is not the same as "Siri is Gemini".

The nuance that does affect your European roadmap: Siri AI doesn't arrive at launch in the EU on iPhone and iPad (Apple cites the Digital Markets Act), and European developers can't even test those features during development. Careful: this is the DMA, not the EAA — don't confuse the two in your internal comms. The good news is that the Foundation Models API does work across the whole EU. Practical conclusion: if you're building intelligence inside your app for the European market, lean on Foundation Models, not on flows that depend on Siri.

What I'd do if I were your Tech Lead this week

1. Put rules around AI use in the team, now. Let the Xcode 27 agents write all they want, but have that code go through the same review, the same tests and the same audit as any other. This is where quality is won or lost this year.
2. Prototype Foundation Models on-device for a real case (classification, extraction, summaries) behind a provider-agnostic adapter using the LanguageModel protocol. Privacy by design and zero API cost.
3. Inventory SiriKit and plan the migration to App Intents, with per-intent privacy manifests if you handle regulated data.

WWDC 2026 isn't about a smarter Siri. It's about Apple deciding that AI will write your code and live inside your app, and lowering the barrier so it happens now. The speed is real. So is the risk of that speed turning into invisible technical debt. The difference between a team that takes advantage of this and one that sinks into production bugs isn't whether they use AI — everyone will — but whether someone with senior judgement is watching what comes out.

Sources (WWDC 2026 sessions)

• 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

---

Has your team started generating iOS code with AI and you need to make sure what reaches production holds up? At AtalayaSoft we audit AI-generated Swift code and embed as senior contractors on banking, retail and insurance projects.

Let's talk →