SwiftUI After 7 Years: A Story of Mediocrity

Seven years after its 2019 announcement, SwiftUI was intended to be the mature, production-grade future of cross-platform UI development for Apple platforms. However, many senior engineers now view it as a framework in a perpetual beta state, trading precise engineering for an illusion of convenience.

Unpredictable Data Flow and Reactivity

SwiftUI's data flow is characterized as a "black box" where achieving predictable behavior is nearly impossible. While the "single source of truth" concept is appealing on paper, the implementation has evolved into a confusing array of property wrappers and macros.

  • Evolution of State Management: The framework began with @State, @Binding, and ObservedObject. Due to performance issues and excessive re-rendering, Apple introduced the Observation framework and the @Observable macro.
  • Lack of Transparency: Developers report that it is often impossible to know exactly how many times a view will update or why a specific update was triggered, even when using undocumented debugging APIs like Self._printChanges().

Layout Engine Fragility and the GeometryReader Trap

SwiftUI's layout system, based on size negotiation, is often described as unpredictable and fragile, particularly when building complex interfaces like custom sidebars or floating views.

  • Layout Inconsistency: Even first-party Apple tutorials are cited as having broken layouts when run on the latest macOS versions.
  • The GeometryReader Workaround: When the declarative system fails, developers often resort to GeometryReader to manually calculate coordinates. This is viewed as an "admission of defeat" because it removes the declarative benefits and increases verbosity beyond that of the legacy Auto Layout system.

API Instability and Feature Parity Gaps

SwiftUI continues to struggle with feature parity compared to legacy frameworks like UIKit and AppKit. This has led to a codebase filled with if #available checks to maintain backward compatibility.

  • Delayed Feature Implementation: Basic functionality—such as dismissing the keyboard on scroll (iOS 16) or displaying network images via AsyncImage (iOS 15)—took years to arrive in SwiftUI despite existing in legacy frameworks for decades.
  • Component Replacement: Rather than fixing buggy components, Apple has occasionally replaced them entirely (e.g., replacing NavigationView with NavigationStack), forcing developers to maintain separate code branches for different OS versions.
  • Caching Limitations: As of July 2026, certain critical APIs for image caching remain in beta, forcing developers to build custom fetchers and caching layers.

Performance Disparities

Head-to-head comparisons suggest that SwiftUI's performance often lags behind UIKit, particularly in data-heavy views.

  • Scrolling Performance: Simple image galleries and large grids in SwiftUI often feel less smooth than their UIKit counterparts, even on high-end hardware.
  • Optimization Overhead: Achieving acceptable performance often requires obscure optimization secrets, which contradicts the framework's promise of simplicity.

The "Learn Once, Apply Anywhere" Myth

While Apple markets SwiftUI as a way to "learn those tools once, and then apply them everywhere," the reality is that UI design for a 6-inch phone differs fundamentally from a 27-inch desktop.

  • Platform Divergence: Concepts learned for iOS are rarely directly applicable to macOS layouts without resulting in "alien" UIs that feel like ported iPad apps.
  • Implementation Inconsistency: The same views often have inconsistent implementations across different Apple platforms, leading to a debug-heavy workflow: "learn once, learn twice, apply somewhere, debug everywhere."

A Philosophical Shift Toward "Good Enough"

There is a growing concern that SwiftUI represents a systemic shift at Apple from uncompromising craftsmanship toward a culture of "velocity" and "good enough" products.

  • Normalization of Bugs: This shift is evidenced by persistent bugs in first-party apps (e.g., Apple Music queue jumping, duplicate Home Screen icons, and missing localization in Logic Pro).
  • Comparison to Legacy Era: This is contrasted with the original Cocoa and Aqua eras, where such visual glitches and instability would have been considered unacceptable.

Community Perspectives and Counterpoints

Developer discussions reveal a divide between those who view SwiftUI as a failure and those who see it as a powerful, if imperfect, tool.

"SwiftUI is the type of framework that makes the easy things easier to accomplish but the harder things harder. It is a newbie trap."

"I’ve been using SwiftUI without major performance issues... I profile and fix as needed. One of the early studios I worked for wrote all our games in UIKit as prototypes... when performance tanked we’d switch to the appropriate tools."

"For 90% of work, SwiftUI is good but for the 10% you would need AppKit. For my app... I needed to load and show a large number of chat items in a list, SwiftUI is really bad at this."

Some developers argue that the frustration stems from a "UIKit holdout" mentality and that for simple apps, SwiftUI is significantly more productive than the boilerplate-heavy nature of legacy frameworks.

Sources