> I can't speak for the author, but many systems programmers look at declarative/markup-based UI as a kind of black magic that you can't trust and that will get in your way sooner or later by not leaving a sane way for you to address some project requirement.
This exact scenario has played out for many trying to adopt SwiftUI. For even moderately complex projects it’s common to get 90% of the way there fairly easily, only for that last 10% to be a struggle/slog as a result of its inflexibility. AppKit/UIKit may not be trendy or sexy and might take longer to get new projects spun up with, but it’s much more rare to hit that brick wall with them; you’ll probably be able to accomplish what you need with little or no pain.
I’ve seen shades of this in Jetpack Compose too, which makes me think that these sorts of problems are just inherent to the type of UI framework.
I've seen a few blogposts on the subject over the years but wouldn't be able to reference any of them on short notice.
In short though, frameworks like SwiftUI tend to be designed around a very narrow set of use cases and if yours deviates from those in any way you're in for a bad time, and depending on how great the deviation is will likely land you with falling back to older imperative frameworks for their more customizable/hackable widgets in places (if that's an option) or dropping the declarative framework altogether.
This exact scenario has played out for many trying to adopt SwiftUI. For even moderately complex projects it’s common to get 90% of the way there fairly easily, only for that last 10% to be a struggle/slog as a result of its inflexibility. AppKit/UIKit may not be trendy or sexy and might take longer to get new projects spun up with, but it’s much more rare to hit that brick wall with them; you’ll probably be able to accomplish what you need with little or no pain.
I’ve seen shades of this in Jetpack Compose too, which makes me think that these sorts of problems are just inherent to the type of UI framework.