Seven years after Apple announced SwiftUI in 2019 as a modern alternative to UIKit, the framework continues to struggle with fundamental issues that have frustrated senior engineers, according to a detailed retrospective published online.
The framework was promoted as a solution to eliminate tedious Auto Layout challenges, offering declarative syntax, single source of truth, built-in animation, instant previews, and cross-platform code reusability. Instead, developers report that SwiftUI remains in what one engineer describes as “perpetual beta” state, with ongoing problems in core areas.
Data Flow Challenges
One persistent pain point is SwiftUI’s data flow system. The framework initially relied on @State, @Binding, and ObservedObjects, but Apple later introduced the Observation framework and @Observable macro after recognizing poor performance and excessive view re-rendering. However, developers report the improvements remain incomplete. According to the analysis, SwiftUI’s reactivity is unpredictable—it “reacts to changes it should ignore, and it ignores the changes you actually care about.” Even using undocumented debugging APIs does not provide complete visibility into when and why views update.
Layout System Problems
SwiftUI’s layout engine, built on size negotiation, proves unreliable in real-world applications. The analysis points to Apple’s own official SwiftUI tutorial project, which contains broken interface elements when built with current Xcode and macOS versions—a problem that has persisted for over two years without correction. The layout system’s fragility causes interfaces to “fall apart in the most unexpected ways,” requiring developers to work around limitations using tools like GeometryReader, which ironically requires manual coordinate calculations similar to the Auto Layout approach SwiftUI was supposed to replace.
API Stability Issues
API stability remains problematic. Modern SwiftUI codebases frequently contain #available checks to handle varying feature support across iOS versions, contradicting the original promise of writing “less code and better code.” This constant branching logic defeats one of SwiftUI’s stated benefits.
The analysis suggests SwiftUI was created partly in response to competition from React Native and Flutter, and to encourage Mac App Store adoption. However, the framework’s trajectory reflects what the author characterizes as a broader shift toward “good enough” products rather than uncompromising engineering.
Key facts
- SwiftUI was announced in 2019 with promises to end Auto Layout frustrations and enable cross-platform code reuse
- Seven years later, developers report ongoing issues with view re-rendering, layout unpredictability, and API instability
- Apple’s own official SwiftUI tutorial contains broken interface elements that have remained unfixed for over two years
- The framework’s data flow system is described as a “black box” that makes predictable behavior difficult to achieve
- Developers frequently resort to manual coordinate calculations using GeometryReader, replicating the complexity SwiftUI was designed to replace