Last week I asked Claude for a settings page. Same request twice: the React version first — worked on the first try, compiled, ran, styled. Then the SwiftUI version — didn't even compile.

The model isn't bad. SwiftUI's path these past few years has just been wild.

1. The model's memory is stuck last year

Since its birth in 2019, SwiftUI has churned through roughly three generations of core APIs:

  • State: BindableObject → ObservableObject + @Published → @Observable
  • Navigation: NavigationView → NavigationStack / NavigationSplitView
  • Data flow combos, with a new correct answer every WWDC

The training corpus contains all three generations, and by volume the old stuff still dominates. So the model grabs a handful of 2019 and mixes it with 2026: NavigationView wrapped around @Observable. Good luck compiling that.

// What the model gives you
NavigationView { ... }  // deprecated two years ago
 
// What you actually write
NavigationStack { ... }

Compare with React: useState and useEffect have been rock solid since 2019, so ten years of corpus all speak the same API. Of course the model writes React fluently — not because it favors the web, but because the web doesn't churn.

2. The UI you can't see

Debug a web UI: hit F12 and the DOM is just there — elements, hierarchy, styles, all inspectable. SwiftUI's render tree is a black box: between what you declared and what you see sits a layer of runtime magic, and when something breaks, the agent can only guess.

Previews should have been the lifeline. In practice they're half a trap: the reason a Preview crashes often differs from why the real app fails, and the error message somehow points at a different line. Humans have to burn incense for this — let alone a model.

3. The Swift 6 wall

Once it finally compiles, Swift 6's strict concurrency checking is waiting behind it. Some callback the agent casually wrote gets slapped awake by a @Sendable error. My own app's background-queue callback got bitten by an actor isolation assertion once — an entire afternoon gone.

Strict concurrency is good — good for humans. For a model it's a speed bump: a big chunk of the Swift in its corpus is old Swift that never cared about concurrency.

4. So where's the awkwardness

It's now clear: SwiftUI is Apple's most modern framework and the framework agents write worst. Flip it around — AppKit's API has been steady as an old dog for thirty years, and the model answers AppKit questions fast and accurately.

What kind of API does the AI era reward? Stable, textual, greppable, failing at compile time when possible. SwiftUI is almost the exact opposite: changes yearly, declarative black box, blows up at runtime.

But I don't think SwiftUI is doomed. A human steering via Previews while the agent does the heavy lifting is actually a great pairing. The awkward part isn't that SwiftUI is bad — it's that it keeps changing, while the model's memory is forever stuck last year.