Where AI agents reliably break on Apple platforms.

Most "AI agent ships an iOS app" demos collapse the moment you ask them to compile.

We've spent the last six months collecting the specific places where current generation models — Cursor, Claude Code, Codex, Copilot — reliably get Apple-native code wrong. Not because they're bad at Swift. They're actually quite good at Swift. They're bad at the dozens of unwritten contracts Apple expects you to know.

Here are the seven we see most often.

App Intents schema strictness

App Intents is the worst offender. The framework validates your intent schema at build time against rules that aren't well-documented and have changed across iOS versions. Common agent failures: generating perform() signatures that don't match the @Parameter declarations, omitting @Parameter title strings (required, not optional), declaring parameter types Apple doesn't accept in IntentParameter, and emitting an IntentResult that doesn't match the actual return shape.

Every one of these compiles fine until you ship. The build error surfaces deep inside Apple's intent macro expansion and reads like compiler line noise.

Plist and entitlement coupling

Swift code is half the work. The other half lives in Info.plist, the entitlements file, and the build settings. Agents almost always generate the Swift correctly and forget the rest.

A WidgetKit widget without WidgetExtension entitlements compiles, ships, and silently does nothing on device. An App Intent that uses location without NSLocationWhenInUseUsageDescription crashes the moment Siri calls it. The compile path doesn't catch this. The runtime crash does, three steps later, with an obscure message.

SwiftUI body return type narrowing

SwiftUI's @ViewBuilder DSL compiles complex view trees into a single opaque return type. Most of the time you don't notice. Some configurations break it: branches with different generic constraints, conditional modifiers that change the inferred type, mixed Group children at the wrong nesting level.

Agents that scaffold "a stack with these conditions and these modifiers" hit this constantly. The error reads "Generic parameter 'V' could not be inferred" and points at the wrong line.

WidgetKit provider mismatches

WidgetKit has three variants of TimelineProvider — TimelineProvider, IntentTimelineProvider, AppIntentTimelineProvider — with different associated types and method signatures. Agents conflate them. They'll declare an AppIntentTimelineProvider and implement getSnapshot with the IntentTimelineProvider signature.

Compiles in isolation. Crashes when WidgetKit calls it because the type doesn't conform to what the framework expects.

Framework version drift

iOS 17 added new APIs. iOS 18 deprecated others. iOS 26 reorganized the App Intents subsystem. Agents pull from training data spanning years. They confidently emit code using APIs that don't exist in the user's deployment target — or that exist but are deprecated and emit warnings that scare the user away from shipping.

The fix is checking the deployment target and the SDK version. Agents don't.

ObservedObject vs StateObject vs Bindable

The state ownership model in SwiftUI is the kind of thing humans get wrong, and humans wrote the training data. Agents inherit the confusion. They'll declare @ObservedObject for a model that should be @StateObject, causing the model to deallocate on every view rebuild. The behavior is wrong but the code compiles. Users notice three weeks later when the bug manifests as state loss.

Concurrency islands

Swift's Sendable / actor isolation system is strict. Agents emit code that crosses isolation boundaries without explicit handling — a Task that captures non-Sendable values, an actor method that returns a non-Sendable type, a delegate callback that hops queues unsafely.

Some of these compile but emit warnings the user can't silence cleanly. Others fail to compile with errors most developers don't fully understand. Either way, the agent produced "working Swift" that isn't actually shippable.

Why this matters for the agent layer

None of these are exotic. They show up in App Store apps every day. Apple's compiler catches some at build time and others at runtime. None of them are caught by the LLM at generation time — there's no reward signal in the training that distinguishes "compiles on first try" from "looks like Swift."

That's the gap Axint exists to close. The compiler enforces every one of these contracts before generation finishes. The validator catches the cases the compiler can't statically prove. The Fix Packet hands the resulting failure back to the agent with enough structure to repair it on the next pass.

Closing the gap is what turns "agent ships an Apple app" from a demo screenshot into a workflow that survives the App Store review queue.

We're publishing benchmark numbers next month. The headline question is simple: how often does each agent ship Apple-native code that compiles on the first build, with and without Axint? Methodology, raw runs, and reproducibility instructions will live at axint.ai/benchmarks.

Until then, this is the qualitative case.