More content welcome to pay attention to the public number: Swift Garden
If you’ve ever worked on UIKit or AppKit (Apple’s native UI frameworks for iOS and macOS), you know that they use classes to represent views, not structs. SwiftUI doesn’t — and here’s why.
First, there is a performance principle involved: structures are simpler and lighter than classes. The reason I mention this first is that most people think it is the main reason for SwiftUI to adopt structures. In fact, overall, this is only one of the reasons.
In UIKit, all views inherit from a class called UIView, which has a ton of properties and methods — background colors, layout constraints, layers for rendering, and so on. There are more properties like that, and every UIView and every UIView subclass has them, because that’s how inheritance works.
Normally this isn’t a problem, but there is a special subclass called UIStackView, which is similar to VStack and HStack in SwiftUI. In UIKit, UIStackView is a view type that will not be rendered in order to make layout easier. But because of the inheritance mechanism, even though it doesn’t render, it has all sorts of properties that it doesn’t use, including background colors.
In SwiftUI, all views are fragmented structures and the overhead of creating them is negligible. Imagine this: you create a structure that holds an integer, and the size of the entire structure is only that integer, and nothing else. There is no “accidental property” inherited from a parent, a grandparent, or a grandparent’s grandparent. You can see everything it contains.
Thanks to the modern iPhone’s ability to create 1000 or even 100,000 integers in the blink of an eye. 1000 views or 100,000 views for SwiftUI. This time still holds. So fast, you don’t even have to think about them.
In addition to performance, however, structs represent views for another important reason: They force us to isolate state in a cleaner way. The class is free to change its value — this can lead to more messy code, so SwiftUI can’t update the UI automatically by changing a value.
By creating views that don’t change over time, SwiftUI encourages us to migrate to a design that works better: The view becomes simple, it becomes “dumb,” and it only does the work of turning data into UI, rather than spawn the more “intelligent” work of control logic.
When you look at what works as a View in SwiftUI, you’ll see that the above approach works. We used Color.red and LinearGradient as views — tiny types that store very simple data. In fact, you won’t find a better solution than treating color. red as a view. It doesn’t carry any extra information other than “fill my space with red.”
For comparison, you can take a look at Apple’s UIView documentation. It lists over 200 UIView properties and methods — whether subclasses need them or not.
Tip: If you try to use class in your view, the code will either compile or crash. Don’t hesitate: use struct.
My official account here Swift and computer programming related articles, as well as excellent translation of foreign articles, welcome to pay attention to ~
