SwiftUI After 7 Years

Original Article ↗ Hacker News Discussion ↗

Seven years after its debut, Apple’s SwiftUI framework is seen by many developers as powerful for simple, declarative interfaces but unreliable and underpowered for complex, performance‑sensitive apps, especially compared to UIKit/AppKit and older Cocoa patterns. Commenters highlight opaque state management, layout fragility, missing or unstable APIs, and tight coupling to evolving Swift language features as core problems, while a minority report good experiences on the latest OS versions and argue it’s “good enough” if you accept its trade‑offs. The debate broadens into concerns about Apple’s software direction, the cost of yearly breaking changes, and whether alternatives like Flutter, Kotlin Multiplatform, or even classic Objective‑C–based stacks now offer a more sustainable path.

SwiftUI’s value proposition and reality

  • Many see SwiftUI as great for simple, “surface-level” UIs: lists, forms, basic CRUD, simple admin tools, and visual effects (blur, masks, Metal-backed views).
  • For complex apps (heavy lists, custom layouts, complex navigation, sophisticated macOS windowing, precise animations), people report performance issues, layout fragility, and lots of “escape hatches” down to UIKit/AppKit.
  • Several call it a “newbie trap”: easy demos, hard real-world work. Bugs and odd behavior often emerge late in larger projects.

State, declarative UI, and architecture

  • Big debate over declarative‑reactive vs imperative:
    • Supporters: state-as-source-of-truth and declarative views reduce update‑logic bugs and make common cases easier.
    • Critics: SwiftUI’s reactivity is opaque; view update timing is hard to reason about; @State/@Binding/@Observable and tools like GeometryReader are seen as “magic” footguns.
  • Long subthread revisits classic MVC: some argue “proper” MVC already solves most state‑sync issues without heavy reactive machinery; others say MVC itself has practical problems (event storms, batching updates, layout performance).

APIs, stability, and tooling

  • Frequent complaints about:
    • API churn (e.g., evolving navigation APIs, state systems), OS-version conditionals, and behavior differences between iOS versions.
    • Poor or scattered documentation; reliance on WWDC videos and third‑party blogs.
    • Weak debugging and profiling support (view hierarchy inspection, understanding re-renders), though a few mention newer Instruments support.
  • Some argue SwiftUI is “very good” from iOS 26–27 onward if you can drop older OS support; others say even current versions still stutter and are CPU‑heavy in real apps.

Swift, UIKit/AppKit, and Apple culture

  • Strong nostalgia for Objective‑C + Cocoa/AppKit/UIKit: seen as elegant, powerful, and better suited to complex native apps; Swift is viewed by some as overcomplicated with limited appeal outside Apple platforms.
  • Others say Swift is a major improvement and now their primary language everywhere; they see AppKit/UIKit as verbose and dated.
  • Several blame leadership and KPI‑driven decisions for shipping Swift/SwiftUI “half‑baked” for a decade, contrasting with earlier NeXT/Cocoa era.

Alternatives and cross‑platform discussion

  • Flutter, Kotlin Multiplatform + Compose, Qt, React Native, WPF, MAUI, HTML/CSS/JS are all discussed as alternatives, each with different trade‑offs.
  • Some now prefer UIKit + AI assistants over SwiftUI, arguing AI erodes SwiftUI’s “easy layout” advantage.
  • Consensus: there is no single “right way”; tool choice depends on app complexity, target platforms, and tolerance for SwiftUI’s quirks.