SwiftUI's Perpetual Beta Is a Release-Model Problem

Seven years after SwiftUI debuted at WWDC 2019, engineer Yakov Manshin published a retrospective calling it "a story of mediocrity and falling standards" — and it promptly hit the Hacker News front page, where a 78-comment thread split along a line every iOS team will recognize. One camp: SwiftUI makes 80% of UI work dramatically easier, and dropping to UIKit for the rest is a fair trade. The other: a framework where the last 20% means fighting the layout engine, rewriting views, or bridging back to UIKit isn't done, no matter how many years it's had.

The complaints are real and verifiable. But "Apple lost its standards" is the wrong diagnosis, and it leads to the wrong prescription. SwiftUI's perpetual-beta feel isn't a craftsmanship failure. It's the predictable output of shipping a UI framework as part of an operating system.

The bill of particulars holds up

Check the specific claims and they land. SwiftUI shipped in 2019 with no first-party way to load a network image; AsyncImage arrived two years later in iOS 15 — without cache control. The fix, AsyncImage initializers that accept a URLRequest so you can actually configure caching, was announced this June at WWDC26 and is still beta in the iOS 27 SDK. That's a seven-year gap between "declarative UI framework" and "can display a remote avatar with sane caching," for a feature every networked app needs and every third-party library solved years ago. Dismissing the keyboard on scroll waited until iOS 16. Navigation got torn up and replaced (NavigationView gave way to NavigationStack in 2022), and the data-flow story was rewritten wholesale a year later when @Observable displaced the ObservableObject/@StateObject wrapper zoo.

The performance criticism survives independent scrutiny too. Jacob Bartlett's iOS 26 benchmarks reached essentially the same verdict from a friendlier angle: List is fine — it's a UICollectionView underneath, cell recycling and all — but for genuinely complex scrolling UIs, UIKit still dramatically outclasses SwiftUI, and an infinitely scrolling feed will never match a hand-tuned UICollectionView. Apple shipping a dedicated SwiftUI performance instrument in Instruments 26 is its own kind of admission.

So the retrospective's facts are sound. Its conclusion — retreat to UIKit and AppKit — is where it goes wrong.

The real problem is the release model

Compare the two declarative UI frameworks born a year apart. Jetpack Compose ships as a versioned library on Maven, decoupled from Android releases, running back to Android 5.0. When Google fixes a Compose bug, every developer gets it by bumping a dependency, and every user gets it in the next app update — including users on six-year-old OS versions.

SwiftUI is welded into the OS. Bug fixes and new APIs ship once a year, in September, gated behind an OS upgrade. If you support current-minus-two — the standard posture for any app with a real user base — an API introduced at WWDC lands in your codebase roughly three years later. That single structural choice generates almost every symptom in the seven-year indictment: the API churn (deprecated patterns must live forever in the OS), the availability-check lasagna (if #available(iOS 17, *)), the bugs that persist across releases because the fix rides the next annual train. Apple made the opposite choice with Swift itself — open-sourced, independently versioned, toolchain-updatable — and the language matured fast. The framework got the OS treatment, and it shows.

That's also why "Apple's own apps are buggy in SwiftUI" cuts less than it seems to. The macOS System Settings rewrite in Ventura was genuinely rough, but Apple's teams are the only ones who can target this year's SwiftUI. They're permanently on the framework's bleeding edge, absorbing exactly the instability the release model creates.

What to actually do with this

If you're starting an iOS app in 2026, SwiftUI is still the right default — not because it's finished, but because the decision has been made for you. Widgets, watchOS, Live Activities, and the visionOS surface are SwiftUI-only or SwiftUI-first. A greenfield UIKit app in 2026 is a bet against every incentive Apple has published for seven straight years.

The practical posture looks like this:

• Set your floor deliberately. iOS 16 buys you NavigationStack; iOS 17 buys @Observable, which eliminates most of the over-invalidation that made early SwiftUI re-render views it should have ignored. If you can justify an iOS 17 floor, much of the classic data-flow pain simply isn't there anymore.
• Budget UIKit for the hot paths. Complex feeds, custom text editing, and scroll choreography still belong in UIViewRepresentable-wrapped UIKit. Treat the bridge as a planned architectural boundary, not an emergency exit — the HN thread is full of teams who discovered mid-project that retrofitting the bridge is the expensive version.
• Keep third-party image loading. Kingfisher and Nuke aren't going anywhere; the first-party replacement is in beta and won't reach your deployment floor until the late 2020s.
• Don't adopt WWDC APIs at announcement. Price in the three-year lag instead of resenting it annually.

The teams losing here aren't SwiftUI adopters — they're the ones who believed each June's keynote meant the framework was done, shipped against beta APIs, and ate the churn. The winners treat SwiftUI as what it structurally is: a framework on a permanent annual drip, two to three years behind its own documentation for anyone with real users.

Mediocrity makes a satisfying headline, and after seven years the frustration is earned. But nothing in SwiftUI's history suggests falling standards so much as a framework paying, year after year, for being distributed like an OS component in an industry that learned to ship UI frameworks like libraries. Until Apple decouples SwiftUI from the September train — and there's zero public signal it will — "seven more years of this, planned for accordingly" is the honest forecast. Plan for it.