Declarative and Imperative Programming using SwiftUI and UIKit
As I get ready to learn about React programming within the next upcoming weeks, I thought it would be great to be able to draw a comparison between React and SwiftUI.
In this article, we will look at comparing SwiftUI with some of the other ways to build applications for the Apple ecosystem. In a future article, we will look at the comparison between React and SwiftUI.
SwiftUI was introduced in WWDC19 and instantly took the swift community by storm. Within the first few weeks of its release, many articles were written and videos were made as many developers were excited by the huge release! SwiftUI allows us to declare the user interface and behavior of our application across all of Apple’s different platforms, which is something to be excited about that!
Imperative Programming
Prior to SwiftUI, developers had UIKit for iOS and tvOS applications, AppKit for macOS applications, and WatchKit for watchOS. These four event-driven UI frameworks use a programming paradigm that is known as imperative programming.
According to Wikipedia:
- “In computer science, imperative programming is a programming paradigm that uses statements that change a program’s state. In much the same way that the imperative mood in natural languages expresses commands, an imperative program consists of commands for the computer to perform. Imperative programming focuses on describing how a program operates.”
As an example, in imperative programming, let us say we might have a function or set of instructions to be called when a button is clicked. Another example would be that we have an event listener that performs actions once the event is triggered.
The problems that come when using imperative UI frameworks are normally associated with the state of values we store in our code. We normally want to keep track of these states in order to do some type of work that our dependant on the current state. For example, a simple light switch can have two states, on or off. What if we have two light switches and each of the combinations cause different actions depending on their state. That is four different combinations. What if we now have three, four, or five switches? It can get complex quickly as we see.
Nonetheless, these frameworks are great, let us face it! They brought us apps that have changed our lives, but they would require you to learn all the frameworks for each of the applications you wanted to build.
Declarative Programming — SwiftUI
SwiftUI uses the programming paradigm known as declarative programming. The following definition is given in Wikipedia:
- In computer science, declarative programming is a programming paradigm — a style of building the structure and elements of computer programs — that expresses the logic of a computation without describing its control flow.
In contrast to imperative programming, declarative programming, we can tell our applications what it should do and look like in different states and let itself handle moving in between those states.
Let us say we tell SwiftUI to show a welcome message when we are logged in and to show a login button when we are logged out. Therefore, since we already told SwiftUI what to show, when we change the authentication state it will show the appropriate view without any more work from us.
To explain further, we are not telling the components of a declarative UI when they should show or hide, we just tell them all the rules we want them to follow and it worries about following them. However, this can become a problem as we have less control, but not everything can perfect.
A major advantage of learning and using SwiftUI is allowing for cross-platform development for the different operating systems within the Apple ecosystem. No more having to learn four different frameworks if you want to build an app that has components on Apple Watch, Apple TV, MacBook Pro, and finally your iPhone.
It is important to know that SwiftUI does not replace UIKit. Instead, it is built on top of providing and an additional layer of abstractions for us.
Code
Here is a quick code to use for comparison between declarative and imperative examples using UIKit for iOS and SwiftUI. A screenshot of the application follows.
This is a simple application that just takes the name inputted by a user and adds this name to a label. Even though, it is a simple application it really allows us to see the benefits of both approaches. Let review the code in UIKit first. Our ViewController.swift file is the main file response for showing our view.
It inherits from a UITableViewController and calls the appropriate UITableViewDatasource methods needed to set up our view. We only have two cells in this example. The first cell contains the text field that the user will use in order to input their name. The second cell contains the label which will be updated every time the text field is updated.
Let us note that lines 18 and 22–27 are the most important for this post. These are the lines responsible for updating the text label every time the text field is updated. We have to first tell the text field at line 18, “hey, call the method ‘textFieldDidChange’ when the value of the text field has changed.” Secondly, in the ‘textFieldDidChange’ method we grab the state or value of the text field and update the text inside of our label. Fancy.
Let us now take a look at this same view written using SwiftUI.
In this example, we see the @State attribute at line 2. This tells swift that it needs to update the name property. Line 6 lets swift know you are updating this variable with this text field, but also you are displaying the data in this variable. Therefore, when the text field is updated so is our state variable. This is called a two-way binding. That is, we are using the state variable to display the data but swift is also updating the state of the variable when it needs too. Lastly, in line 7, we bind our state variable to the text label. Notice how there is no dollar sign because we are only reading the variable in this line. There is no way to update it!
Conclusion
SwiftUI is very powerful and abstracts a lot of the work is done for us. Behind the scenes, it is still using UIKit. So no, UIKit will not be going anywhere any time soon, yet, we can understand the push by the Swift community to use SwiftUI. It is convenient, quick to use, and allows for our apps to reach more devices with less effort.
With these abstractions comes a cost. We are not able to customize our data as easily as we may want. Yet again, where there is will there is away. Thanks for reading!
