Apple released Swift language and SwiftUI framework in 2014, 2019 respectively. For iOS developers, the trend of technology update is inescapable, and they should actively learn the application.

Swift is the language of choice

I started working with Swift around Swift version 3.0, and I have refactored or developed some new projects through Swift one after another. I still remember clearly that because the ABI of Swift was not yet stable and many syntax features were still changing frequently, I had to spend some time dealing with the business code changes brought about by the syntax changes after each upgrade of Xcode, along with the upgrade of the Swift compiler version. Although most of this work was done automatically by Xcode, there were still a few errors that needed to be handled manually, which was very unpleasant. If that time in the project to use Swift to consider compatibility, stability and other issues can be justified, then now, 2023, Swift language has been finalized, stability has been fully verified, as iOS developers should be determined to choose Swift. still on the Objective-C to hold the residual, it is a little uninspired.

Now, the Swift compiler is smart enough and intelligent enough to write business in Swift in a new app, a new SDK, or even a single module with confidence. And don’t worry about mixing Swift and Objective-C, modulemap handles this elegantly, and you can even find Objective-C objects in SwiftUI that require little additional processing by the developer and can be used directly.

From UIKit to SwiftUI

SwiftUI must be developed using the Swift language. Getting started with SwiftUI starts with mastering the Swift syntax.

Moving from UIKit to SwiftUI is not simply a change of UI framework, but a change in development thinking. This may be a bit uncomfortable for developers at first, but a few more tries will reveal the benefits of declarative UI frameworks. If you have experience with other declarative frameworks like Vue.js, Flutter, WeChat applets, etc., then you will be more comfortable with SwiftUI. I unilaterally believe that experience with UIKit doesn’t seem to give you an advantage in moving to SwiftUI, but rather people who have done Vue.js and other development may have an easier time with SwiftUI, which should be more of a latecomer in concept and design when various front-end frameworks have declarative layout as standard.

In the UIKit era, we often discuss the MVC, MVP and MVVM design frameworks, in SwiftUI can finally end here. To be honest, I personally have a strong dislike for these kinds of ideas. On the one hand, it’s hard for everyone to have the same understanding, and on the other hand, even if a solution is perfectly implemented, it’s likely that subsequent business changes will cause distortions to the original implementation as different developers take over. If a solution is not universal, and is replaceable, then it can not be the golden rule.

SwiftUI solves this problem perfectly, in a decisive and violent way: now developers have one option and one option only. swiftUI natively supports two-way data binding, so developers no longer need to use various third-party frameworks to write all sorts of strange, obscure but high-sounding syntax code in order to implement the so-called MVVM.

Using SwiftUI ensures that all developers on the team are relatively unified in their code thinking, at least reducing the probability of weird code styles and no more MVC, MVP, MVVM arguments.

It’s time to learn SwiftUI

Combined with the author’s feeling of using SwiftUI for this period of time to talk about.

  • iOS 13 system penetration

    SwiftUI supports iOS 13 as a minimum. As of January 2023, about 1% of iPhone devices are using iOS 13 and previous iOS systems. Combined with API upgrades or changes, users in this segment may not be able to use the app developed by SwiftUI properly or cannot use certain feature functions. Commercial apps need to take this part of users into consideration.

  • Coexistence with UIKit

    SwiftUI is not yet completely free from UIKit. SwiftUI provides UIViewRepresentable and UIViewControllerRepresentable to solve some dependencies on UIKit during the transition to SwiftUI, some UI effects may have to rely on UIKit at this stage. implementation. The duration of this dependency should be very long, in the foreseeable future, UIKit and SwiftUI will always coexist and be used.

  • Impact on Flutter and others

    SwiftUI should have some impact on Flutter etc. This is not a technical reason, but a matter of discourse. In the Apple ecosystem, Swift and SwiftUI are currently the main technical solutions. For iOS developers, SwiftUI is definitely the first choice, and I privately believe that cross-end development is gradually declining, and the efficiency and advantages of native development frameworks will become more and more obvious.

  • How should developers choose?

    What is certain is that migration to SwiftUI is an inevitable trend, and it is time to learn SwiftUI and reserve related technical knowledge. Later, I will also write more SwiftUI related articles with the problems I encountered during the development process.