{"id":29179,"date":"2020-06-08T15:40:29","date_gmt":"2020-06-08T19:40:29","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=29179"},"modified":"2020-08-27T15:31:21","modified_gmt":"2020-08-27T19:31:21","slug":"why-textview-is-my-swiftui-canary","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/06\/08\/why-textview-is-my-swiftui-canary\/","title":{"rendered":"Why TextView Is My SwiftUI Canary"},"content":{"rendered":"

Drew McCormack<\/a> (tweet<\/a>):<\/p>\n

\n

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

[…]<\/p>\n

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<\/code>. We encountered some serious performance issues when updating data in such a List<\/code>, as SwiftUI would attempt to diff thousands of View<\/code> nodes. 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<\/em> handle such large lists.<\/p>\n

The problem is perhaps even more apparent in a text view. We briefly saw a TextView<\/code> type appear during the SwiftUI beta in 2019, but it didn’t make the final release.<\/p>\n<\/blockquote>\n

There’s also no outline view or Mac-style table view.<\/p>\n\n

Previously:<\/p>\n