By ByteBot
SwiftUI turned seven this year. In software years, that’s not a toddler — it’s an adult with a job and a performance review. Apple’s declarative UI framework has had seven years to mature, fix its bugs, and earn the trust of iOS and macOS developers. Instead, it shipped a fix at WWDC 2026 for an autofocus bug that has existed since iOS 13. Seven years to fix a text field. That’s the story.
On August 3, developer Yakov Manshin published “SwiftUI After 7 Years: A Story of Mediocrity” — and 200 developers on Hacker News showed up to add their own war stories. The comments are weary, not angry. That’s worse. Anger implies surprise. These developers have stopped being surprised.
Seven Years Is a Verdict, Not a Grace Period
There’s a version of this conversation where SwiftUI is “promising but still maturing.” That version expired around year three. Seven years means the framework is what it is. The bugs that exist now existed in 2022, and 2023, and 2024. The pattern is consistent: Apple fixes some things at WWDC each June, introduces new features with new rough edges, and leaves a subset of old bugs untouched. The backlog never clears.
The community’s settled verdict: perpetual beta. Multiple independent developers used that exact phrase without coordination. When a framework ships its seventh year and experienced engineers are still using “beta” to describe it, you’re not looking at a maturity problem. You’re looking at a structural one.
The Bugs Are Specific, Not Vibes
This is not developer frustration looking for a target. The criticisms are documented, reproducible, and have names attached.
Undo/Redo destroys text. John Gruber documented this in June 2026: delete a word in a SwiftUI text editor, press Undo, and the entire sentence disappears. Unlike AppKit apps, there’s no recovery from the Undo stack. This is not a subtle edge case — it’s a data loss bug in a feature AppKit solved before SwiftUI was announced.
Autofocus in sheets doesn’t work. Max Seelemann confirmed: SwiftUI cannot autofocus a text field in an appearing sheet while bringing up the keyboard in the same animation. Every system app on iOS does this. The Messages app does this. SwiftUI cannot.
Drag-and-drop is still incomplete. WWDC 2026 shipped the third major iteration of SwiftUI’s drag-and-drop API. You still can’t simultaneously reorder within a view, drag items out of that view, and perform drop validation. Three iterations. Seven years. Still can’t do all three at once.
And then there’s performance. Jacob Bartlett benchmarked SwiftUI List against UIKit UICollectionView in July 2026 on iOS 26: SwiftUI produced 78 animation hitches in 24 seconds with 100% CPU usage at rest and 248MB of memory. UIKit: 0.7 hitches per second, 11% CPU, 92MB. Same data, same device. SwiftUI’s reactive architecture — diffing view hierarchies before every render — extracts a cost that UIKit’s direct manipulation simply doesn’t pay.
Apple Optimizes SwiftUI for WWDC, Not for Production
Here’s the structural explanation: Apple designs SwiftUI to look good in 20-minute conference sessions, not to hold up in 200,000-line production apps. WWDC demos are controlled environments. The framework shines in controlled environments. It struggles when real users do unexpected things with complex state in multi-layered view hierarchies.
The tell is Apple’s own apps. Most of Apple’s production software — the apps shipping to billions of devices — is still built on UIKit and AppKit. Apple doesn’t eat its own cooking. The Mail app is AppKit. The Photos timeline isn’t SwiftUI under the hood. When the team building a framework doesn’t use it for their real work, the bugs that only surface in real work don’t get prioritized.
Aniline Applications ran this experiment and published the result: they replaced their SwiftUI timeline implementation with pure UIKit. “It’s so much more performant,” they reported. They’re not alone. Sean Heber captured the developer experience concisely: “Right up until you hit a BRICK FUCKING WALL when it’s missing a capability or hook you need.”
Cocoa Got There. SwiftUI Hasn’t.
Apple’s prior framework transitions are instructive. Toolbox to Carbon to Cocoa: each step produced tools that were genuinely better for professional developers. Cocoa with AppKit was excellent — robust, reliable, feature-complete. Developers trusted it. SwiftUI was supposed to be the continuation of that trajectory. It broke the pattern.
The Cocoa transition worked because first-party apps were worth aspiring to. SwiftUI’s first-party examples remain unimpressive. As multiple Hacker News commenters noted: “Apple has burned a lot of developer goodwill along the way.” That’s not enthusiasm for the destination. That’s exhaustion with the journey.
The AI Angle Nobody’s Talking About
Something shifted in the last two years: AI coding agents. Claude Code, Copilot, and Cursor now handle UIKit boilerplate competently. One of SwiftUI’s original advantages was ergonomics — fewer lines of code, faster prototyping. When an AI writes the boilerplate for you, that advantage collapses. UIKit’s power becomes accessible without the tedium of hand-writing delegate methods.
If you’re using an AI coding agent to build your iOS app in 2026, the calculus has changed. SwiftUI offers ergonomics. UIKit offers control, performance, and feature completeness. When AI handles the ergonomics problem, SwiftUI loses its strongest argument. The WWDC 2026 fixes are welcome — but the framework’s competitive position just got harder, not easier.
The Verdict
SwiftUI is not going away. Apple is committed to it, and developers building for Apple platforms don’t have an exit. But after seven years, the honest assessment is this: SwiftUI is excellent for simple screens and prototypes. For anything complex — high-performance lists, text editing, drag-and-drop, nuanced animations — you’re probably dropping into UIKit for the hard parts anyway, with SwiftUI as a veneer on top.
That’s not the future Apple promised in 2019. Seven years later, 200 developers showed up on Hacker News to confirm it still isn’t. The question isn’t whether Apple will fix SwiftUI. They will, incrementally, at WWDC, every June. The question is whether “incrementally, at WWDC, every June” is fast enough for a framework that was supposed to replace UIKit.
Based on seven years of evidence: probably not.
