{"id":30893,"date":"2020-11-30T16:36:15","date_gmt":"2020-11-30T21:36:15","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30893"},"modified":"2020-11-30T16:36:15","modified_gmt":"2020-11-30T21:36:15","slug":"what-is-not-so-great-about-swiftui","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/11\/30\/what-is-not-so-great-about-swiftui\/","title":{"rendered":"What Is Not So Great About SwiftUI"},"content":{"rendered":"

Thomas Clement<\/a> (tweet<\/a>):<\/p>\n

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.<\/p>\n

[…]<\/p>\n

You heard that right: merely looking at the size proposed by the parent will change the layout in unwanted ways.<\/p>\n

[…]<\/p>\n

It is bothering that third-party developers are not able to write the same kind of views that Apple provides in SwiftUI.<\/p>\n

[…]<\/p>\n

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: Bool<\/code> and pass it along to the view representable but alas this really doesn’t work well as the SFAuthorizationView<\/code> owns the state already (the authorization reference). There is no obvious way that I know to address this sort of discrepancies.<\/p><\/blockquote>\n\n

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?<\/p>\n

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<\/code> isn’t the same kind of escape hatch.<\/p>\n\n

Steve Streza<\/a>:<\/p>\n

SwiftUI on Mac is a constant struggle of wondering “am I doing this wrong or is this just broken on Mac”<\/p><\/blockquote>\n\n

Previously:<\/p>\n