Why SwiftUI views use structs

[[414187]]

This article is reprinted from the WeChat public account "Swift Community", the author is Wei Xian Zhy. Please contact the Swift Community public account to reprint this article.

If you’ve ever programmed for UIKit or AppKit (Apple’s native user interface frameworks for iOS and macOS), you’ll know that they use classes rather than structs to construct views. This is not the case with SwiftUI: we prefer to use structs for overall views for two reasons.

First, there’s the performance factor: structs are simpler and faster than classes. I say performance factor because many people think this is the main reason why SwiftUI uses structs, but it’s actually just part of a bigger picture.

In UIKit, every view derives from a class called UIView, which has a number of properties and methods: a background color, constraints that determine how it is placed, a layer to render its content into, etc. There are a lot of them, and every UIView and UIView subclass must have them because that’s how inheritance works.

struct or class

Normally this wouldn’t be a problem, but there’s a specific subclass called UIStackView that’s similar to VStack and HStack in SwiftUI. In UIKit, UIStackView is a non-rendering view type that’s designed to simplify layout, but that means that even though it has a background color because of inheritance, it’s never actually used.

In SwiftUI, all of our views are simple structs that are pretty much free to create. Think about it: if you make a struct that contains just one integer, the entire size of the struct is just that: one integer. Nothing else. No extraneous values ​​inherited from a parent, grandparent, or great-grandparent, etc. — they contain exactly what you can see, and nothing more.

Thanks to the power of modern iPhones, I don’t think twice about creating 1000s of integers or even 100,000s of integers — it happens in the blink of an eye. The same goes for 1000s of SwiftUI views or even 100,000s of SwiftUI views. They’re so fast that they’re no longer worth thinking about.

But while performance is important, there’s something more important about views as structures: it forces us to think about isolating state in a clean way. You see, classes are able to change their values ​​freely, which can lead to messy code — how does SwiftUI know what changed the value and needs to update the UI?

By generating views that don’t change over time, SwiftUI encourages us to move toward a more functional design approach: our views become simple, inert things rather than intelligent things that spin out of control when transforming data into UI.

You can see this when you look at the things that can be views. We've used Color.red and LinearGradient as views—simple types that contain very little data. In fact, you couldn't find a better idea than using Color.red as a view: it doesn't contain any information other than "fill my space with red."

In contrast, Apple’s UIView documentation [1] lists about 200 properties and methods that UIView has, all of which are passed to its subclasses whether they are needed or not.

**Tip:** If you use classes in your views, you may find that your code does not compile or crashes at runtime.

References

[1] UIView documentation: https://developer.apple.com/documentation/uikit/uiview