Seven years after Apple introduced SwiftUI, developer Yakov Manshin has published a sharply critical assessment of the framework, arguing that it still behaves more like a beta than a predictable foundation for production interfaces. His critique focuses on performance, layout consistency, changing data-flow mechanisms and the work needed to support older platform versions.
SwiftUI arrived in 2019 with a declarative model intended to reduce the effort of building interfaces across Apple platforms. Manshin recalls promises including a single source of truth, built-in animation, immediate previews and reusable cross-platform code. The approach also aligned Apple’s tools with the reactive, declarative direction represented by frameworks such as React Native and Flutter.
In Manshin’s experience, however, the data model has accumulated complexity. SwiftUI began with property wrappers including `@State`, `@Binding` and observed objects, then added the Observation framework and the `@Observable` macro. He argues that developers can still struggle to understand why a view refreshed, how many times it updated or why a relevant change was ignored. He characterizes that behavior as a black box rather than a reliably inspectable reactive system.
Layout is the second major complaint. SwiftUI uses size negotiation between views, an approach Manshin says becomes hard to control for nonstandard components such as floating views and custom sidebars. He points to Apple’s own tutorial project as an example, claiming its standard sidebar renders incorrectly when built with the latest Xcode and run on the latest macOS. He says the issue has persisted for more than two years.
Manshin also cites UTM as a capable application whose SwiftUI interface can nonetheless resemble an early prototype. In his account, developers often resort to `GeometryReader` wrappers and other workarounds when layouts fail in unexpected ways. These examples are observations from one practitioner’s review, not independent measurements establishing failure rates across SwiftUI applications.
The critique places those technical issues within a broader competitive history. Manshin argues that Apple needed a more approachable cross-platform interface framework as businesses increasingly considered shared web and mobile codebases. He also suggests SwiftUI was meant to encourage more native Mac software instead of browser applications and Electron-based wrappers. Those explanations are his interpretation of Apple’s strategy.
Manshin’s report is not a claim that SwiftUI lacks useful features; it is an argument that convenience is undermined when state changes and layout results are difficult to predict. The practical question for engineering teams is therefore not simply whether declarative syntax shortens an example, but whether a chosen SwiftUI design remains stable, explainable and maintainable across the operating-system versions the product must support.
