Why SwiftUI will make UIKit obsolete
And why you should consider switching over
During the last couple of months, SwiftUI has been gaining a lot of traction and popularity amongst the iOS development community.
Swift has been my main programming language ever since I started coding. I have developed my fair share of iOS apps, mainly using UIKit. A few months back, I got hired as a Swift developer. Surprisingly, the company works exclusively with SwiftUI, which meant I had to learn this new framework. After a few months of development, I fell in love with SwiftUI after being loyal to UIKit for the last couple of years. Here are my key takeaways of why I and many believe SwiftUI will make UIKit obsolete and why you should consider switching over.
Lightning-fast development
It is fascinating how when developing with SwiftUI, you can go from having nothing to a useful app in just a few minutes — What makes SwiftUI development so fast?
SwiftUI uses the programming paradigm known as declarative programming, while UIKit uses imperative programming. This means that you, as a developer, only need to “tell” SwiftUI what to do, not how; SwiftUI will take care of the implementation for you, which results in a lot less code and plenty of saved hours.
To get a better idea of the differences these two styles of programming make in speed, I’ll show you an example. I made a simple habit tracker “app” (basically just a screen, but whatever) in both UIKit and SwiftUI.
UIKit (Imperative programming)
SwiftUI (Declarative programming)
You do not need to understand what the code does, just take the time to appreciate the line count in each file. The SwiftUI version has exactly 4 lines of code while the UIKit version contains a few dozen. This is what I mean when declarative is way faster than imperative.
In the UIKit file, we need to write the instructions on how to do exactly each thing we want to see on screen.
UIKit is like the new intern — more than willing to do everything, however, you need to be very specific with the instructions you give as it does not know how to do “stuff” by itself. We need to tell it how to do all the setup — first, you need to add the subviews, then you need to set the layout constraints, and finally assign the table view's delegate and data source.
SwiftUI is like the employee of the month. We simply tell it the results we want to see, and it will take care of the implementation for you without bothering much.
Reactive programming
Working with data in SwiftUI is such a joy thanks to bindings and reactive data sources brought with the Combine framework. Reactive programming is quickly becoming an industry standard, and we can finally reap the benefits from it in our iOS apps.
But what is reactive programming?
Reactive programming means that when data changes, the UI updates — you do not need to worry to update it yourself. So let’s say you have var coolHat: String on multiple screens of your app and let’s say that coolHat = “red”. If screen 3 sets coolHat = “blue” all the other screens that have that variable will update as well. (All these instances are bound, like those creepy twins that speak at the same time).
On the other side, we have event-driven programming, most commonly used in UIKit. This works by some component firing an event and another component listening to the event. This is a lot more manual work as you are in charge of orchestrating the flow of events and what happens after said events take place. Who listens to who? What should each component do if a certain event is triggered? It adds a lot of extra complexity and might make your code more error-prone.
Let’s take another practical example of how SwiftUI and UIKit may differ in this aspect. This “app” shows a TextField and a Label. When the user types in the TextField the Label updates with the entered text.
UIKit (Event-driven programming)
SwiftUI (Reactive programming)
Again, you don’t have to understand the code, yet from these two examples, we can see the extra complexity UIKit has over SwiftUI’s reactivity. This not only saves time but also makes your code cleaner and much less error-prone.
In the SwiftUI program, the text is bound to the TextField and the Label, which means that when the user types something, the Label will automatically update as both TextField and Label have the text variable as a binding.
On the other hand, in the UIKit program, we need to subscribe to the TextField events so we can get notified when the user types something. We then need to manually assign the TextField text to the label text after the event is triggered as these two variables are not bound.
Preview apps in realtime
You no longer have to build to see the view every time you make a change to your code. SwiftUI offers a time-saver feature called Previews that lets you see and interact with your views without building in the Simulator/Device.
It’s like you can finally paint without being blindfolded.
You will be working in a split view between your code and your Preview where you can see everything going on in your view. You update a button’s color and you’ll see the Preview updates it in real-time.
It is the future
SwiftUI is rapidly evolving and improving. With the most recent WWDC we can see Apple is pushing this new framework. Even though UIKit is not going anywhere soon, we need to acknowledge how Apple’s focus is shifting away from it, as most new features announced in the event were exclusive to SwiftUI. We have seen it before with Objective-C when UIKit was first introduced.
The not-so-good side
Even though I thoroughly believe that SwiftUI is worth learning and using over UIKit, it’s still not a perfect framework and it’s worth noting the points that are still holding it back.
- Most of the industry still uses UIKit
- Missing some native components
- It supports only iOS 13 and up
- Limited adoption
- Creating custom views can be tedious
UIKit is still the industry standard as it has had a long life span. So, if you are thinking of applying for an iOS Developer job, you’ll probably find that most companies still use UIKit extensively in their codebases (even if they are switching over to SwiftUI).
Conclusion
All in all, SwiftUI is a fantastic and promising framework. It is incredibly fast to develop in, has adopted better ways to manage data, it’s great not having to compile your code to see your views, and is quickly evolving.
If you are already in the UIKit boat, I encourage you to try SwiftUI. If you are starting with Swift, SwiftUI is incredibly accessible to beginners. Hacking with Swift has a great series on learning the basics of SwiftUI, I highly recommend checking it out.
Sign up for our Free Weekly Newsletter. Fresh content from developers all over the world, fresh and direct from the field! Don’t forget to follow our publication The Dev Project.
