SwiftUI at Seven Is Winning Adoption and Losing Trust

Yakov Manshin's essay "SwiftUI After 7 Years: A Story of Mediocrity" hit the Hacker News front page in July, and it's tempting to file it under the genre that's existed since 2019: seasoned Apple developer discovers the declarative future still has rough edges. But the timing matters. Paulo Andrade published a detailed account in May of building his Mac app Shopie entirely in SwiftUI — verdict: "you're fighting the framework for things the Mac solved 20 years ago." John Gruber piled on in June with a piece bluntly titled "SwiftUI Only Makes It Easy to Develop Bad Apps." Three prominent voices, three months, one conclusion. Something has shifted from grumbling to consensus.

What's shifted isn't SwiftUI. It's the expiration of the excuse. For years, every gap could be answered with "it's early." Seven years in — longer than the entire gap between the original iPhone SDK and Swift itself — that answer is gone.

The complaints haven't changed, and that's the indictment

Read the 2026 critiques next to the 2020 ones and the overlap is uncomfortable. Manshin catalogs gaps that took years to close: dismissing the keyboard on scroll didn't arrive until iOS 16. AsyncImage — table-stakes remote image loading — landed in iOS 15 and still ships without real caching control, which is why every production app still pulls in Nuke or Kingfisher. The NavigationView-to-NavigationStack migration forced codebases into if #available branches, the exact boilerplate the framework promised to eliminate.

State management has been rebooted three times — ObservableObject, then Combine-flavored refinements, then the @Observable macro in iOS 17 — and Manshin's sharpest observation is that developers still can't reliably predict how often a view body re-evaluates without reaching for Self._printChanges(), an underscored debugging API Apple has never properly documented. When your framework's core abstraction (view = function of state) requires undocumented introspection to reason about, the abstraction is leaking.

Andrade's Mac-specific list is worse because it's not about missing conveniences — it's about missing fundamentals: no API to know a context menu is open (so you can't highlight the target row), no visibility into drag sessions from the source side, keyboard navigation that dies the moment a TextField has focus. Gruber's example is the most damning: an undo bug in Apple's own SwiftUI-built Journal app that eats entire sentences. Undo has worked in AppKit since before the web existed.

The structural problem nobody at Apple can fix with effort

Here's the analysis the individual posts circle but don't land on: SwiftUI's real handicap isn't engineering quality, it's distribution. SwiftUI ships inside the OS. Bug fixes and API additions arrive once a year, in September, and using them means raising your deployment target — which for most teams means waiting another year or two. A bug Apple fixes in 2026 reaches a typical app's user base in 2028.

Compare the competition. Jetpack Compose is a library: Google ships fixes on a weeks-long cadence, decoupled from Android releases, back to API 21. React Native and Flutter update on npm and pub timelines. Those frameworks have their own deep problems — React Native's architecture rewrite took most of a decade to go default — but their feedback loop between "developer hits wall" and "fix ships" is measured in weeks, not OS cycles. SwiftUI's loop is the slowest in the industry, and it's a deliberate Apple choice (OS-bundled frameworks are how Apple has always shipped). That choice was defensible for AppKit, which was finished. It's fatal for a framework still growing basic limbs.

That's why seven years of iteration produced less convergence than anyone expected. It's not that Apple's engineers are worse than Google's. They get one at-bat per year.

Meanwhile, adoption climbs anyway

Now the paradox: while the critiques sharpen, the numbers go the other way. Alexandre Colucci's binary analysis of iOS 18 found SwiftUI usage inside Apple's own OS grew more than 50% year over year, against roughly 8% for UIKit. WidgetKit is SwiftUI-only, so anyone shipping widgets already has it in the build. Job listings, new-project templates, Apple's sample code, WWDC session hours — every signal points the same direction. SwiftUI has won the default for new code without ever matching the ceiling of the frameworks it replaces.

That's the "mediocrity" Manshin names, and he's right that it's more corrosive than outright failure. A broken framework gets abandoned or fixed. A good-enough framework gets adopted everywhere while its ceiling quietly becomes the platform's ceiling — see macOS System Settings, the SwiftUI rewrite that's been a punchline since Ventura, or the prototype-feel Manshin flags in apps like UTM.

What this means for your codebase

The practical takeaway isn't "avoid SwiftUI" — that ship sailed. It's to stop treating UIKit/AppKit interop as a temporary bridge and start treating it as your permanent architecture.

The pattern that actually works in production in 2026: SwiftUI for settings screens, forms, onboarding, widgets, and anything shaped like a hierarchy of mostly-static content — it genuinely is 3–5x faster to build there. Drop to UIViewRepresentable/NSViewRepresentable for the surfaces where the critiques concentrate: high-throughput scrolling (Manshin's grid test found SwiftUI "much less smooth" than UIKit even with tuned image decoding), serious text editing, and — per Andrade — essentially any Mac app that wants to feel like a Mac app. Budget the escape hatches at project start, not when you hit the wall in month four.

And do the deployment-target math honestly. Minimum iOS 16 buys you NavigationStack; 17 buys @Observable. Anything older and you're writing the compatibility branches SwiftUI was supposed to kill.

The bet on declarative UI was correct — every platform made it, none are reversing it. The bet that Apple's version would reach parity with what it replaced has, seven years in, quietly failed to pay out. Plan like parity is never coming, because structurally, it can't arrive faster than one September at a time.