1. About SwiftUI
At the recent WWDC 2019 event, Apple introduced a framework to handle interface design according to new style. This article introduces the SwiftUI framework.
SwiftUI is a user interface toolkit that allows designing applications in a declarative way. SwiftUI allows us to implement how and how the interface looks, and it shows how to make that happen when the user interacts with it.
The declarative UI design is best understood compared to the imperative UI, which is what iOS developers have done before with the iOS 13 version. In an imperative style, we can call a When you click on a button and inside a function we will read a value and display a label – we often modify the interface based on what’s happening.
The imperative interface causes all sorts of problems, most of which revolve around state , meaning that values are stored in code. We need to monitor the state of the code and make sure the interface accurately reflects that state .
If we have a screen with a Boolean attribute that affects the UI, we have two states : boolean can be ON or OFF. If we have two booleans, A and B, we now have four states .
- A is OFF and B is OFF
- A is ON and B is OFF
- A is OFF and B is ON
- A is ON and B is ON
So if we have three Booleans? Hay year? Either integer, string, or date data and more? The result is more and more complicated.
If you’ve ever used an app that says you have an unread message even if you try to point out that you’ve read it, that’s a state problem – it’s a imperative UI issue.
In contrast, declarative UI allows us to tell iOS about all possible application states at the same time. We can say if we log in, we will display a welcome message, but if we log out, we will display the login button. We don’t need to write code to move between those two states by hand – that’s a bad way of doing things, it’s an imperative way!
Instead, we let SwiftUI move between UIs when the state changes. We display it based on whether the user is logged in or out, so when we change the authentication state , SwiftUI will update the UI.
This means that by declarative : we don’t make the SwiftUI components display and hide by hand, we set the rules so that it obeys and exits SwiftUI, ensuring that the rules are enforced.
But SwiftUI doesn’t stop there: it also acts as a cross-platform UI layer that works on iOS, macOS, tvOS and even watchOS. This means that you can now learn a language and a framework framework, then deploy your code anywhere.
2. The difference between SwiftUI and Interface Builder, Storyboard
Most experienced iOS developers are too familiar with IB (Interface Builder) and Storyboard . So what is the difference between SwiftUI and IB , Storyboard ? XIB and Storyboard files contain a large amount of XML format code, have you ever had to edit this file? As the application grows, the number of files, the file itself becomes bigger and bigger when you add different UI controls, when you have any changes that lead to a significant increase in resource costs. Or when someone changes XIB, causing a relatively severe conflict. Also, if the XIB or Storyboard file has a close relationship with sourcode, any changes in this file that have not been updated in the source code will cause significant errors.
These problems exist because IB and Swift are very separate things. This is not a big surprise – not only has the tool created UI started before Mac OS X was originally, but it was also designed around Objective-C’s way of doing things.
SwiftUI was created to solve this problem. Simply, it is a framework for Swift, in addition to Appl slowly dying Objective-C , it allows SwiftUI to leverage the entire range of Swift’s functions, – value types, return types, extensions protocol, etc.
Anyway, we’ll get exactly how SwiftUI works soon. Currently, the minimum thing you need to know is that SwiftUI fixes many of the problems people face with the old Swift + Interface Builder approach:
- We no longer have to argue about programming based on programming or storyboard design, because SwiftUI allows us to do both at the same time.
- We no longer have to worry about creating source control issues when committed to UI design, because the code is much easier to read and manage than XML when changing UI control.
- We no longer need to worry too much about APIs that must be strictly reported – there are still some, but significantly less.
- We no longer have to worry about calling functions that no longer exist, because our UI is checked by the Swift compiler.
3. Frequently asked questions about SwiftUI
What to learn: SwiftUI or UIKit
Currently, most iOS apps are written in UIKit. Others are not because they use React Native or something else, but generally UIKit and iOS apps always go together.
So if you skip SwiftUI for a year, two years or even more, you may lose your job. No one – including Apple, I think so! – Hope the iOS community will switch to SwiftUI as soon as possible.
On the other hand, if you are new to iOS development and ignore UIKit so you can focus on SwiftUI, you will probably find it very difficult to find a job because no one uses it for commercial purposes. This is quite risky for those who want to search for work right away with iOS.
Where to use SwiftUI?
SwiftUI runs on iOS 13, macOS 10.15, tvOS 13 and watchOS 6 or any later version of those platforms. This means that if you work on an application that must support iOS N-1 or even N-2 – ie the current version and the previous one or two – it will be a year or two before you Can think of switching to SwiftUI.
However, it’s important not to think that SwiftUI is a cross-platform framework similar to Java Swing or React Native. SwiftUI is not a cross-platform framework, but instead is a framework for creating applications on multiple platforms.
This may sound the same, but there is an important difference: Apple does not say that you can use identical SwiftUI code on every platform, because some things are impossible – there is no way to use Use Apple Watch on a Mac, and likewise have a tab bar on the watchOS application that will not work.
SwiftUI will replace UIKit
Not really, many parts of SwiftUI are built directly above UIKit components, such as UITableView. Of course, many other components, they are rendered by SwiftUI, not UIKit.
SwiftUI uses Auto Layout?
Although Auto Layout is definitely being used for some things behind, it can’t be displayed as a SwiftUI designer. Instead, it uses a flexible layout system that is relatively familiar to web developers
UIKit will be killed?
Not really, Apple has many new UIKit functions, introduced at WWDC. If Apple still talks about UIKit, it means that we can still work with UIKit normally
This article introduces a few brief ideas about SwiftUI. So I hope you agree that there are many benefits to switching to SwiftUI. Welcome to the new world, Apple’s new UI programming style.