You fell in love with SwiftUI the day it was announced. I did too. A simpler, cleaner way to build UIs. No more boilerplate, no more storyboards. Just declarative magic. But seven years later, you’re still here, reading this, because something feels wrong. You’ve been trying to build a real app, and every time you hit a wall, you drop down to UIKit, roll your eyes, and tell yourself ‘next version will fix this.’ It won’t.
SwiftUI isn’t a framework. It’s a beautiful mirage that evaporates the moment you try to build something real.
Let’s be honest about what’s happening. The promise of declarative-reactive UI was supposed to free us from imperatives. Instead, it’s created a new kind of dependency: a need to constantly escape the abstraction. You’re not writing SwiftUI anymore. You’re writing workarounds. You’re wrapping UIKit views, patching missing controls, and praying that the next WWDC fills the gaps. But the gaps keep growing.
I’ve been tracking this since 2019. The pattern is clear: every year SwiftUI absorbs a few more UIKit features, but the core abstraction remains broken. The leaky abstraction is not a bug—it’s a feature. Apple wants you to stay in the ecosystem, not to finish your app. Because if you could build a complete app with SwiftUI, you’d realize how brittle the whole thing is.
Take the comment from a solo dev: “I fell in love with SwiftUI the day it was announced, but as a solo dev I still haven’t been able to make a full app with it yet, mostly because of the lack of documentation, and the gaps where you still need to drop down to AppKit/UIKit.” That’s not a skill issue. That’s a framework issue. The response ‘skills issue’ is the classic gaslighting of a community that refuses to admit the emperor has no clothes.
The industry is collectively gaslighting itself into believing that a half-baked abstraction is the future.
But here’s the twist: maybe the problem isn’t SwiftUI at all. Maybe the problem is the assumption that a single declarative-reactive paradigm can be the right shape for every native UI challenge. Complex, stateful, interactive apps don’t fit neatly into a view tree that updates reactively. They require direct manipulation, fine-grained control, and the ability to break the rules. SwiftUI tries to impose rules, and when you break them, you pay the price in complexity.
I’ve seen the same pattern in Flutter, in Jetpack Compose, in every declarative UI framework. They all work great for demos, for simple screens, for prototypes. But production apps with real users, real data, and real edge cases? They eventually leak. The abstraction becomes a prison.
So what do we do? Keep pretending? Or admit that the declarative dream is a useful tool, not a universal truth. Use it where it shines—simple forms, list views, rapid prototyping. But don’t bet your entire app architecture on a framework that still can’t handle a basic navigation stack without a third-party library.
The best developers don’t fight the framework. They choose the right tool for the job. And sometimes the right tool is UIKit.
Seven years in, SwiftUI is still not a complete platform. It’s a beautiful demo, a promising experiment, but a dangerous foundation for anything that matters. You’re not wrong to be frustrated. You’re paying attention.
FAQ
Q: Is SwiftUI completely useless for production apps?
A: No. It works well for simple UIs, forms, and prototypes. But for complex, production-grade apps with custom interactions, navigation, or performance requirements, the gaps force you to mix in UIKit, defeating the purpose of a pure declarative approach.
Q: What should I do if I'm starting a new iOS app today?
A: Use SwiftUI for the parts that benefit from reactivity—lists, settings, simple views. Use UIKit for anything that requires precise control, complex animations, or custom layouts. Don't commit to a single paradigm. Treat SwiftUI as a tool, not a religion.
Q: Isn't the real problem that developers expect too much from SwiftUI?
A: That's a fair counterpoint. SwiftUI is a young framework, and Apple is improving it every year. However, the core issue is that the declarative-reactive model may never fully support every native UI need. The expectation that it will is the real problem. It's a tool, not a panacea.