What Is Not So Great About SwiftUI
What seems to still be missing from SwiftUI is the notion of the intrinsic content size: the natural size that a view really wants to be unless it is forced to be something else. This is the size that views should adopt by default. Working in-hand with this would be the ability to define compression resistance priorities and content hugging priorities, something that SwiftUI also lacks. These are important features to describe how views should behave relative to each others when they are forced to deviate from their natural size.
[…]
You heard that right: merely looking at the size proposed by the parent will change the layout in unwanted ways.
[…]
It is bothering that third-party developers are not able to write the same kind of views that Apple provides in SwiftUI.
[…]
But the SwiftUI code only builds a description of the wrapper view, there is no function that can directly be called to talk to the underlying AppKit view. The natural SwiftUI way of doing this would be to add a new state variable such as
@State var isAuthorized: Booland pass it along to the view representable but alas this really doesn’t work well as theSFAuthorizationViewowns the state already (the authorization reference). There is no obvious way that I know to address this sort of discrepancies.
I still don’t know what to think about SwiftUI. Much of it seems amazing, but two major releases in there’s this basic stuff that remains broken, and stuff that was easy with Auto Layout is needlessly difficult or impossible. How much is just bugs vs. limitations of the overall system’s design? For the latter, is the long-term plan that some UIs are just not possible? Or that AppKit/UIKit will live forever?
With Auto Layout, you could always opt out certain subtrees if what you were trying to do was too slow or couldn’t be expressed. But, as Clement describes, SwiftUI’s NSViewRepresentable isn’t the same kind of escape hatch.
SwiftUI on Mac is a constant struggle of wondering “am I doing this wrong or is this just broken on Mac”
Previously:
- The State of SwiftUI
- SwiftUI Alerts
- Emulating Equal-Size Constraints in SwiftUI
- SwiftUI for Mac on Big Sur
- Why TextView Is My SwiftUI Canary
4 Comments RSS · Twitter
My gut Feeling is that Swift and Swift UI had the wrong direction and design choices. But because they are Apple they ( most of the time ) seems to know what they are doing and long term solution. Swift UI started before Chris Lattner left Apple, 4 years in the making so the current state of things isn't very reassuring.
I've been using SwiftUI for a few years. I don't like it, but I have trouble explaining why. I think there is something wrong with declarative frameworks that are opaque and don't let you escape into imperative mode when needed. I guess I'm in the minority - wanting to deeply understand and control the tools I use to build things. I'm also confused about why they abandoned the Auto Layout constraint system. That seemed like a great idea. IMO, a general constraint solver matches well with what UI layout fundamentally _is_. I'd like to know what went into that decision to abandon that system for one that can't accomplish the same things.
seems Stuffs are the same still at Aug/23 ?
> SwiftUI on Mac is a constant struggle of wondering “am I doing this wrong or is this just broken on Mac”
Indeed.
While `withAnimation {}` and `.animation()` was working flawlessly on Catalina with Xcode 12, on Big Sur it started to trigger memory leak by just using them. The same happens with `.onHover` since Catalina.