SwiftUI remains a perpetual beta seven years after launch, critique argues
A software engineer published a lengthy critique of SwiftUI, Apple's declarative UI framework, seven years after its 2019 debut, arguing it still behaves like a perpetual beta. The piece began as a video and is posted as an article carrying its transcript. It opens with a demonstration: Apple's own official, first-party SwiftUI tutorial project (called Landmarks) still contains a broken sidebar layout that the author says was first noticed more than two years ago and remains unfixed.
The author traces SwiftUI's origin to competitive pressure: by the mid-2010s, React on the web and its offshoots, React Native and Google's Flutter, had made native app development look unappealing to businesses that wanted one codebase across platforms. SwiftUI, announced in 2019, was meant to keep developers inside Apple's native ecosystem and make it easier to port apps to a Mac App Store that had grown quiet, given Apple's 30% cut on App Store transactions.
On data flow, the author says SwiftUI moved from @State, @Binding and ObservedObjects to the newer Observation framework and @Observable macro after the original approach caused excessive view re-rendering, but the layout engine still cannot reliably explain when or why a view updates, even with the undocumented Self._printChanges() debugging method.
On layout, the author calls SwiftUI's size-negotiation-based engine unpredictable, saying developers end up wrapping views in GeometryReader to regain manual control, which the author calls the ultimate admission of defeat since it forces manual coordinate math that can break again on the next SwiftUI update. The real-world app UTM is cited as an example of a serious project whose reliance on SwiftUI still makes it feel like an early prototype.
On API stability, the author lists gaps versus UIKit and AppKit: dismissing the keyboard on scroll, available in UIKit since iOS 7, only reached SwiftUI at iOS 16; AsyncImage for loading networked images arrived only in iOS 15; and, as of July 2026, SwiftUI's image-caching API is still in beta. NavigationView was replaced outright by NavigationStack rather than fixed, forcing developers to maintain separate code branches for older and newer OS versions. The author contrasts this with Google's Jetpack Compose on Android, which ships as an updatable package through a dependency manager and, per the author, delivers identical UI on devices as old as 2014.
On performance, the author ran a head-to-head comparison between a UIKit and a SwiftUI version of the same image-gallery screen from an older version of the author's own app, tested on an older iPhone. Even with optimizations such as decoding images on background threads, the SwiftUI grid scrolled noticeably less smoothly than the UIKit equivalent, which the author argues points to an architectural problem rather than a need for faster hardware.
The text available for this retelling cuts off mid-sentence at the start of a section on SwiftUI's cross-platform promise, before the author reaches a verdict on that topic.
Key facts
- The author's own head-to-head test found the SwiftUI version of an image gallery scrolled noticeably less smoothly than the UIKit version, even with background-thread image decoding.
- Apple's own first-party SwiftUI tutorial project ships with a broken sidebar layout that the author says has gone unfixed for over two years.
- Basic UIKit features took years to reach SwiftUI: dismissing the keyboard on scroll, available in UIKit since iOS 7, arrived only at iOS 16, AsyncImage only at iOS 15, and image caching is still in beta as of July 2026.
- Apple replaced the buggy NavigationView with NavigationStack rather than fixing it, forcing developers to maintain separate code paths for old and new OS versions.
- The author contrasts SwiftUI with Android's Jetpack Compose, which ships as an updatable package delivering identical UI on devices as old as 2014.
Why it matters
SwiftUI was Apple's 2019 answer to the rise of React Native and Flutter, meant to keep developers building native apps and to make porting software to a quieting Mac App Store easier. Seven years on, this critique argues it still has not delivered the production-grade stability Apple promised, keeping open the gap between Apple's native tooling and its cross-platform rivals.
Who it affects
iOS, macOS, iPadOS, watchOS and visionOS developers who build on SwiftUI, especially senior engineers working on non-trivial apps who run into the layout and data-flow problems the author describes. The piece cites UTM, a real shipping app, as an example of a serious project still fighting SwiftUI's limitations.
How to use it
The author's workarounds double as a practical field guide: use the undocumented Self._printChanges() method to debug unexplained view updates, reach for GeometryReader when the layout engine's size negotiation breaks down (at the cost of losing SwiftUI's declarative model), and keep if #available checks and parallel code branches ready for APIs Apple has renamed or gated behind newer OS versions, such as NavigationStack replacing NavigationView.
How solid is it
The critique is one engineer's detailed technical argument, not an independent benchmark study. Its strongest evidence is directly reproducible: readers can download Apple's own official Landmarks tutorial project and see the broken layout themselves, and the author links to several other independent write-ups describing the same category of SwiftUI problems. The performance comparison is the author's own test on an older iPhone, described qualitatively as SwiftUI scrolling much less smoothly, rather than with measured frame-rate figures.
Risks and caveats
This is opinion and technical critique, not a report of an event; treat the claims as one experienced developer's assessment, since the source includes no response from Apple. The available text cuts off mid-sentence just as the author begins the section on SwiftUI's cross-platform promise, so no conclusion on that topic is included here. The author's identity is not given in the text, and the specific benchmark figures behind the smoothness verdict are not disclosed.
“Once you use the GeometryReader, you've lost the declarative benefit entirely.”
— the article's author, on SwiftUI's layout system