SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps.
1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each modifier doesn't actually modify the main view but it modifies what the modifier before it decided to return. This makes no sense as the modifiers should each be modifying the main view to make everything predictable and easy to debug. I'm convinced no one (not even senior devs with 5 years of SwiftUI experience) understands how the ordering of modifiers works. It's just swap them until it does what you want it to.
2. The view lifecycles and code execution path seem random and hidden behind layers of "magic," making it incredibly difficult for developers to trace and debug issues.
3. It is practically impossible to set breakpoints for rendering and view construction, it's impossible to really figure out when re-renders happen and what drives them. I'm convinced SwiftUI apps are incredibly slow not because the SwiftUI implementation itself is slow, it's because, even Apple's own apps probably do a bunch of unnecessary re-renders and one no one seems to have any idea. This is unfortunately another design issue that can't be solved by just making SwiftUI more efficient. It requires simplification and tooling to help developers not footgun themselves.
4. Lots of issues start appearing later on in the development cycle because, for simple apps, bad SwiftUI design decisions and footguns have unnoticeable effects, until the apps gets more complex and things start breaking. Fixing these issues sometimes requires rewriting whole features or spending hours debugging.
5. There seems to be almost no documentation on Liquid Glass. It's laughable that after more than 1 year, Apple has simply refused to document or provide good examples for Liquid Glass, except for maybe couple pages that resemble the brain dump of an engineer that has never passed a writing class in college?
6. Stuff seems to be rapidly changing and breaking from version to version. It took days to make my app look and work the same in iOS 27 as it did on iOS 26, even though iOS 27 is supposed to be a minor bug fix release. We don't even use anything non-standard and don't do any hacks. This defeats the whole purpose of a simple UI framework that can be easily adopted to different platforms (this never used to happen with UIKit).
7. View debugger still has no SwiftUI equivalent. It used to make things so much simpler in UIKit when you could just see the view bounds, pick views apart and understand what's actually happening. SwiftUI has no equivalent other than `.background(.red)`. Terrible.
I don't know how Apple can salvage this beyond just undoing some of these terrible design decisions and making it 1. super simple to work with, 2. stop relying on magic, making things more explicit, and 3. providing actual 1:1 UIKit feature parity.
1. It's not really the builder pattern, which, in Java, is what you describe as wanting: mutating a single instance. SwiftUI uses result builders to compute a single generic View from the "DSL", but you could do the same thing without the custom syntax, it would just be more verbose.
2. Documentation issue. The lifecycle is standardized, but Apple is terrible as documenting it all in one place. I found this year's "Dive into lazy stacks and scrolling with SwiftUI" WWDC video actually had a pretty good explanation, at least for the lifecycle within lazy containers.
3 and 7. Yes, Apple's tools suck pretty bad. Preview canvas is also still terrible, despite multiple attempts to improve.
4. Not something I've experienced, not sure what you mean.
5. Yeah, Apple's docs suck.
6. Not sure what you mean here either, our stuff looks pretty much the same.
Just a couple points because your opinions aren’t wrong, they’re just your lived experience.
2. There’s no magic here. There is poor documentation. The biggest trick — small views, think about what values are going to trigger a refresh. Avoid cascading view refreshes.
6. You might have missed a couple big iOS releases (iOS 7 was one to remember) where many of our apps fell over in UIKit. Swift was another ‘DOA’ for YEARS with the same issues you’re making here, each new version broke the old, but here we are in a day and age where it’s the standard.
Apple seems to be loved by users, but hated by developers (and for good reasons). They just seem to not give a shit about the developer experience.
You mention some examples, I have experience with lower-level stuff: terrible. Poorly documented, and actually not really working well.
IMO they should focus on improving the developer experience instead of wasting money on the joke that is Liquid Glass (even users don't like it, right?). But anyway, too late for me: I'm soooo happy that I can develop iOS apps in Kotlin now, and just endure Xcode for building and occasional debugging.
This used to be different. NeXTstep and early MacOS-X were pretty much the finest platforms to develop on.