SwiftUI Is Convenient, but Slow
SwiftUI might be slower than UIKit at the moment, but it has significantly more potential for performance improvements in the frameworks.<p>With UIKit, developers mostly express the &quot;how&quot; – put this control at these coordinates etc. This makes it quite hard for the framework to a) understand if anything has actually changed, and b) optimise how the UI gets rendered.<p>With SwiftUI, developers much more express the &quot;what&quot; – show the user this information, with these constraints, etc. This allows the framework much more scope to optimise how the layout is accomplished. For example a List of 3 items could skip a bunch of complexity around the handling of swapping views in and out of the hierarchy as it&#x27;s unlikely to scroll far enough.<p>Additionally, by making the data model a first class concept more than it was with UIKit, SwiftUI has much more understanding about data flow and when the UI needs to be re-rendered, or which parts need to be re-rendered.<p>It&#x27;s still early days, compared with the maturity of UIKit (which stems from AppKit, which is 20+ years old at this point), but the scope is much deeper and I&#x27;m confident the performance will improve as Apple iterate, and as they understand how it&#x27;s used by developers and improve those code paths.