- UI that is more stateful (like text fields, which have a selection range, etc.) aren't well supported. Say you want a button to insert text at the insertion point in a text field. You'll need to drop down to UIKit/AppKit for that.
- Slow compile times due to the static typing of the view hierarchy.
- Error messages that have little to do with where the problem is (you learn to read the tea leaves).
- Gotchas e.g. a view can't have more than 10 children, and the error has little to do with that.
- Declarative syntax is confusing, adds complexity to the language, and makes the error messages even worse. I still haven't figured out when I can and can't use normal syntax.
- Poor performance for simple UIs. It's all built on top of AppKit/UIKit and chooses very heavy weight widgets for things like lists. You have to be careful about what gets regenerated, which is funny for displaying ~100 simple things on a screen.
One of the biggest positives though is to finally be rid of autolayout, which was just utterly awful.
That being said, hopefully these issues will get better with time. Swift 5.2 includes a new diagnostics architecture  that is supposed to greatly improve SwiftUI error messages. The 10-subviews limitation will be removed once we have variadic generics; a Swift Evolution proposal is currently being drafted  and is expected to land in Swift 6.
An Apple engineer  said the nested generics were used for SwiftUI because it makes diffing view hierarchies easy and makes identities stable, eliminating a class of bugs caused by changing view hierarchies during interactions or animations.
But does potential dynamism actually cause problems in practice? (I haven't used other reactive UI toolkits.)
It seems to me that most of the pain in using SwiftUI stems from the heavy reliance on generics. Hopefully it's worth it.
they didnt have to go all the way to something like xml but right now its in the uncanny valley of DSLs imo; it should have been different enough that its quick to prototype and understand what's possible and whats not vs swift-like dsl we currently have
There's a whole new diagnostics engine in Swift which has been designed to specifically solve the kind of error ambiguity that happens all the time with the insanely-nested generic SwiftUI types.
For example, <NavigationView> + <NavigationLink> doesn't update a History state object that you can control, push, or pop.
So for the NavigationLink example, there is an isActive parameter which takes a Binding<Bool>. If you set that value as true, the navigation will be made active. Likewise, you can read whether the navigation link is active by reading the bound parameter.
Instead of pushing navigations onto a history object stack, you return a view that represents the nested navigations based on state.
Bindings like 'isActive' are discretionary because the NavigationLink can provide the appropriate (if non-persisted) state if your application logic doesn't care.
Hacking with Swift is impressive in how much ground it covers.
The point of reactive UI is to not deal with events that affect data that affect presentation. Instead, you construct "presentation" every time the data changes, and the framework makes sure to reflect that in an optimal way.
They just happen to be handling it entirely within their view component instead of making it a function on some controller/ViewModel/whatever object that then goes and updates the bool. Each framework then has its own code gen or library or runtime magic that makes that bool change get reflected in other views.
(Not to be confused with what Apple, for example, calls MVC, which is more like MVP).
IMO, it's not very well done and you should look elsewhere to learn about SwiftUI.
Stick with RxSwift MVVM/MVP if you want reactive functional programming.
I overheard someone once say they used NotificationCenter as the data binding mechanism in an MVVM app. Big Yikes.
Another pain point IMO is the uncertainty of not knowing Apple's plans and timelines. For example, why did Apple take so long to release ABI stability for Swift? When will ObjC be finally deprecated? Is SwiftUI going to replace UIKit and Cocoa? If yes, when will that happen? Is it worth it to invest serious dev time into a new macOS Cocoa product if SwiftUI or even Catalyst will be the de facto option in, say, 3 years?
iOS devs seem to be happy rewriting their products every year after WWDC and chasing after Apple's decisions which doesn't really seem a sustainable business model.
Using SwiftUI is the first time ui programming on iOS has clicked for me.
For anyone getting into this, I suggest you take a look at apple's very well done tutorial series before using other sources:
I spent about 3 days to go through the entire series and the time investment was well worth it.