[fingerlocks]

Since it’s trivially easy to bridge a UI/NSView into SwiftUI, why don’t you do that? If you think of SwiftUI as a dumbed-down children’s toy box version of the grown-up’s tools, there’s nothing to complain about. It’s really better that way since UI/NSKit has so many footguns.

[lachenmayer]

I don't see SwiftUI as a "dumbed-down children's toy box" at all -- SwiftUI is excellent conceptually. I am just frustrated that the "SwiftUI standard library" that Apple ships with it is so rudimentary, as if we didn't already have over a decade of prior art of how to implement declarative APIs for basic components.

The worst offenders by far are the scroll & list views, which are basically useless. As a starting point, there is no way to get the current scroll position from a scroll view in iOS <18.

So yes, I often have to wrap the UIKit components myself, and deal with all the joys of UIKit I was hoping to finally avoid...

Apple did exactly the right thing with Swift itself: the Swift forums are excellent, and it's clear that Apple employees use these to prioritize the (very real) Swift bugs and limitations. Why does this not exist for SwiftUI?

[fingerlocks]

I agree with you, but I actually like UI/AppKit so I’m biased. The only “pure” SwiftUI components I trust are Button, Image, and Text. Everything else gets built out “old-school” and wrapped in a UIViewRep. It’s just so much easier that way. SwiftUI Lists are half baked. Sheets and popovers feel like they were implemented by a stoned intern that thought it would be funny to troll everyone.

[happytoexplain]

This is only true for the very simple cases you might see in an example snippet. If you need a UIView because you need access to some kind of imperative action (which is usually why you need a UIView), there is no channel for that. Declarative vs imperative are fundamentally incompatible when in the same abstraction layer. You have to use the kind of hacks you used to only see in "bad" codebases, like notification broadcast instead of delegated function calling.

[fingerlocks]

Not sure I follow. Have you seen UIViewRepresentable? You can turn a UIView into a SwiftUI view in 5 lines of code. If you need to move state there is a two way bridge you can choose to implement called a Coordinator. It is a blank protocol with zero obligations to fulfill and only exists as convenient a reference type simultaneously accessible by both the UIView and the SwiftUI parent.

I can’t imagine how it could be implemented more simply.

Even if you are rendering a complex chain of compute shaders with multistage heap fences onto a process shared IOSurfaceRef with several concurrent threads greedily realiasing your scratch buffer to queue up more work, it doesn’t matter. Eventually you’ll up with a UIView or CALayer and it’s still just one function call to bring it into SwiftUI.