00. SwiftUI vs UIKit

It will take about 3 minutes to finish reading this article.

Just as we struggled with whether or not to embrace Swift, are many people today struggling with whether or not to embrace SwiftUI. Then I can tell you very clearly that if you choose to embrace Swift, then SwiftUI is a hurdle you won’t be able to get past sooner or later! Take my advice, it’s not too late to embrace SwiftUI, you’ll find more and more hiring JD’s asking for SwiftUI. I’ve also been learning SwiftUI on my own lately, and I’m going to be writing a series of posts about SwiftUI, so let’s start with this one on SwiftUI vs UIKit and why we’re going to go with SwiftUI.

1. UIKit

UIKit was publicly released in 2008 and is built on the object-oriented Objective-C language. In UIKit, all views inherit from a class called UIView, which has a very large number of properties and methods-such as background, layout, layers for rendering, and so on-there are almost 200 properties, and every UIView and subclass of UIView, whether you want it or not, will have Every UIView and subclass of UIView will have these properties whether you want them or not.

For example, there is a special UIStackView in UIKit, which is a view type that will not be rendered for the design intent of making layouts simpler. But because of the inheritance mechanism, even though it doesn’t render, it has those various unused properties including background color.

So, in UIKit, when we draw a UI that contains a series of labels/buttons, etc., it’s a stack of “big” and “heavy” Views that contain more than 200 attributes.

2. SwiftUI

Born in 2019, SwiftUI is a modern framework for building user interfaces introduced by Apple. As new devices evolve in terms of processing power, graphics performance, and other technical features, SwiftUI takes full advantage of these new hardware and technical capabilities, optimizing and tuning the underlying implementation so that apps running on new devices can render interfaces, handle user interactions, and deliver smoother animations and effects more efficiently.

SwiftUI is based on responsive programming approach to UI development, all the views are fine-grained structure struct, compared struct and class can be known, Swift is very much advocate the use of struct, the specific why will not expand. In SwiftUI, each view is a lightweight struct structure, which abandons UIKit’s inheritance approach and uses protocols to contain the few properties and modifiers needed. All in all, SwiftUI is much more performant and faster than UIKit, with less overhead for creating the same view.

In addition, SwiftUI provides a number of keywords like State, which not only allows us to write less code, but also allows us to focus more on the UI changes caused by value changes in responsive programming thinking. Since class can freely modify the value of attributes, which may bring complicated logic, in contrast, struct under the SwiftUI development of UI code is more “independent” (many of the capabilities it has also provided you, do not need to build the wheel again)

3. Final Thoughts

Because SwiftUI will only come out in 2019, compatibility for previous iOS versions is expected to be a bit of a problem. Because UIKit has been developed for many years, SwiftUI has not been as powerful as UIKit third-party libraries, but it is only a matter of time. And Apple in order to be compatible with some of the methods used, such as UIHostingController. read a lot of foreign articles, many of them developers are very clear point: SwiftUI will eventually replace UIKit, and UIKit will eventually be abandoned.

  1. Apple Official:
    [1] https://developer.apple.com/tutorials/swiftui
    [2] https://developer.apple.com/documentation/SwiftUI/View-fundamentals
  2. Hackingwithswift Series:
    [1] https://www.hackingwithswift.com/books/ios-swiftui/
  3. SwiftfulThinking Series:
    [1] https://www.youtube.com/playlist?list=PLwvDm4VfkdphqETTBf-DdjCoAvhai1QpO
    [2] https://www.bilibili.com/video/BV1KY411f7in
    [3] https://github.com/SwiftfulThinking