[lachenmayer]

What's incredibly annoying is that a lot of the SwiftUI components are just wrappers around the equivalent UIKit components (eg. ScrollView/UIScrollView), but are missing a lot of the functionality of the underlying components.

These should really be open source: it's such a waste of time to have to experimentally poke around to see how the SwiftUI components interact with their UIKit counterparts, when these should really just be straightforward wrappers.

In many cases, the declarative APIs are just poorly thought out and/or clearly not "battle tested", and there is a lot of API churn in really crucial components which are also often not backported to older OS versions.

[myko]

> These should really be open source:

It's funny, when SwiftUI and Compose were coming out we waited a bit but jumped in as soon as we could. With Compose, our early versions required us to make builds of Android Studio on our own machines that supported it. But even then Compose felt more polished in a lot of ways - and if we ran into issues we could _see the code_ and make our own components with the changes we needed if necessary.

SwiftUI is great, really, but has so many rough edges, gotchas, and bugs. They do get fixed, but you're still supporting 4 year old versions of iOS without those fixes, so you're screwed.

Just completely boneheaded not to open source SwiftUI from the start, especially with how great the open source Swift community is.

[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?

[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.