SwiftUI at year seven: still not trusted for serious apps
A detailed retrospective on SwiftUI after seven years of existence landed well on HN. The core complaint is unchanged: documentation gaps, missing APIs, and Apple's pattern of shipping things that look complete but have load-bearing holes that only surface when you build something real. Solo developers reported still not being able to ship full apps with it.
The comment thread framed this as a systems-decay problem: 'The problem with complex systems is that you can be dead long before you realize you are dead.' SwiftUI keeps looking fine from a distance because of inertia from the surrounding ecosystem, but the gaps compound over time for anyone building non-trivial apps.
This is triggering the perennial question of whether Flutter or Kotlin Multiplatform is now the rational default for new mobile projects. No consensus, but the fact that it is being asked seriously about a seven-year-old Apple-native framework is itself a signal.
So what?
If you are starting a new consumer mobile app, the SwiftUI question deserves a deliberate answer rather than an assumption. For cross-platform teams, Flutter's continued appearance as a credible alternative to native Apple tooling is worth factoring into your platform bet. For Apple-focused founders, the documentation gap is real and should be budgeted as engineering time, not assumed away.