Why TextView Is My SwiftUI Canary
One of the big questions on my mind is how well the fully declarative approach scales to complex apps. You can already build quite reasonable portal apps for your favorite web service with SwiftUI, which is 90% of the iOS app market, but I am much more interested in the other 10%. Can you build an advanced iOS app or serious macOS app with SwiftUI? Could you develop an app like Keynote or Xcode using SwiftUI?
[…]
This process is fast for a few standard views, but there are bigger challenges looming. For example, take a large array of values that you want to present in a
List. We encountered some serious performance issues when updating data in such aList, as SwiftUI would attempt to diff thousands ofViewnodes. You could restructure your UI in order to avoid such large lists, but that is a bit of a cop out, because the technologies SwiftUI is designed to supplant can handle such large lists.The problem is perhaps even more apparent in a text view. We briefly saw a
TextViewtype appear during the SwiftUI beta in 2019, but it didn’t make the final release.
There’s also no outline view or Mac-style table view.
Previously:
Update (2020-08-27): Sebastián Benítez:
I heard many other people are having problems with other advanced AppKit controls, such as NSTextView, NSTableView, NSOutlineView. Any non-trivial Mac application is bound to use one of these, so if you were to use them, you either wrap them in a representable + coordinator or go the traditional way and build with SwiftUI around it.
Despite all of this, I have no plans to abandon SwiftUI.
As much as I enjoy SwiftUI, it becomes quickly frustrating by its limitations and having to resort to UI/NSViewRepresentable for trivial things such as making a text field first responder.
SwiftUI is still a few years from being a real alternative to UIKit/AppKit.
SwiftUI List performance on AppKit is very bad. We did a version of our Timeline (the middle view) that used LazyVStack and it was fast. We need List for animations and other things, so hopefully the SwiftUI team gets things tuned on AppKit.
The part of the SwiftUI story I’m waiting for is how to build SwiftUI.
One of the problems of SwiftUI is you’re not building views. The View name is misleading. You’re building a description of something that somehow is turned into views. Completely out of your control.
So you’re completely limited to what the DSL allows you to express. Unlike AppKit/UIKit, you can’t actually BUILD something. You can only pick from a catalog the parts you want and assemble them according to the instructions.
3 Comments RSS · Twitter
One of the big questions on my mind is how well the fully declarative approach scales to complex apps. You can already build quite reasonable portal apps for your favorite web service with SwiftUI, which is 90% of the iOS app market, but I am much more interested in the other 10%. Can you build an advanced iOS app or serious macOS app with SwiftUI? Could you develop an app like Keynote or Xcode using SwiftUI?
I’m not sure this is a problem that needs solving. As long as Apple remains committed to AppKit or UIKit for more complex use cases, and enables simple mix-and-matching, SwiftUI can take care of the many simpler use cases.
@Sören That would mean that if your SwiftUI layout gets too complex you would need to throw it out and start over with auto-layout and Cocoa controls. Or if you outgrow a particular SwiftUI control you would need to recode it and everything it interacts with. And Apple would have to maintain 3 parallel systems forever. I think that may well be what ends up happening, but it’s not great.
That would mean that if your SwiftUI layout gets too complex you would need to throw it out and start over with auto-layout and Cocoa controls.
I guess my response was really more to what you wrote: “There’s also no outline view or Mac-style table view.”
As in, what I’m thinking is: do (and leave) your layout and basic controls in SwiftUI, then add AppKit controls inside for complex use cases.
(If, of course, the layout capabilities are quite limited as well, then that’s a bummer.)
And Apple would have to maintain 3 parallel systems forever. I think that may well be what ends up happening, but it’s not great.
Depends. If (and that’s a big if) they maintain them better than they are right now, this could be a net win. Make writing simple UIs more straightforward while keeping complex controls an option.
Keep in mind that there’s a constant threat of cross-platform frameworks. The growing one being “web UI”, whatever that means today, such as using React on top of an Electron app wrapper. AppKit in particular, in contrast, seems to be growing out of favor. Part of it is arguably neglect on Apple’s part, but I think part of it is also just an uphill battle. “We also offer SwiftUI, and we’re keeping AppKit around for advanced use cases” is, I think, a more compelling argument than “we’re staying the course and will keep iterating on AppKit”.
But, again, that depends a lot on how well they’ll maintain those systems.
