Should You Learn SwiftUI or UIKit?

Written by LearnAppMaking on April 28 2021 in App Development, Dev Careers, iOS

Should You Learn SwiftUI or UIKit?

Should you learn UIKit or SwiftUI? That’s the question we’re discussing today. UIKit is proven, extensive, the status quo. SwiftUI is the newcomer, innovative, flexible. You use both to build UIs on iOS. Which is the best tool for you?

In this tutorial, we’ll discuss:

  • Comparing UIKit vs. SwiftUI – what are the differences?
  • How you can learn SwiftUI and UIKit, and where to start
  • Common arguments and objections for learning one or the other
  • Should you learn SwiftUI now, or wait?
  • Great reasons for learning UIKit next to SwiftUI

Ready? Let’s go.

  1. SwiftUI vs. UIKit
  2. “I’ll only use UIKit in my job”
  3. “SwiftUI is incomplete and/or lacks documentation”
  4. Next Steps: Learn UIKit and SwiftUI
  5. Further Reading

TL;DR: Learn both SwiftUI and UIKit. If you’re new to iOS, start with SwiftUI. If you’re at an intermediate level, learn SwiftUI next to UIKit. Learn UIKit too if you goal is to get a job. Always learn more than what’s required for the job at hand. Don’t simply trust SwiftUI’s magic – find out how it works, and why.

SwiftUI vs. UIKit

SwiftUI

SwiftUI is a declarative UI framework. You use it to build User Interfaces (UIs) for Apple platforms, including iOS, macOS and iPadOS. SwiftUI’s approach to building UIs completely consists of writing Swift code, which is incredibly productive.

A central concept in SwiftUI is that “state drives the UI”. Your app’s UIs are a result of state. You can manipulate state, and connect it to your apps UIs, with tools like property wrappers and Combine.

Here’s a quick example of a view built with SwiftUI:

struct BookList: View
{
    @ObservedObject var viewModel: BooksViewModel

    var body: some View {
        NavigationView {
            List(viewModel.books) { book in
                NavigationLink(destination: BookEdit(book: ···)) {
                    BookRow(book: book)
                }
            }
            .navigationBarTitle("Books")
            .onAppear {
                viewModel.fetchBooks()
            }
        }
    }
}

SwiftUI was launched during WWDC in 2019, so it’s a relatively new technology. Since its inception, SwiftUI has received several improvements. Most notable, the “SwiftUI 2.0” iteration (2020) – and many developers have high hopes for WWDC 2021.

Take for example the MapKit framework, which is used to display interactive (geographic) maps in apps. SwiftUI didn’t have a Map view at its inception in 2019, but you could still use a native MKMapView by reusing it from UIKit. The fact that you can use UIKit-based views in SwiftUI has greatly helped its adoption.

In 2020, a native Map view has been added to SwiftUI and MapKit. You don’t need to use MKMapView anymore, and instead can use the new Map view right out-of-the-box. It’s worth noting that the new Map view has fewer features than its UIKit counterpart.

This story about MapKit and SwiftUI is a good illustration of what to expect of SwiftUI in the future. We’re going to see that SwiftUI gets extended more and more, until it’s (hopefully) comprehensive and mature enough to replace UIKit.

UIKit

UIKit has been part of iOS since before iOS. UIKit is an imperative framework. It’s based on AppKit – the SDK you use to build Mac apps – which means that some part of UIKit goes as far back as NeXTSTEP. Remember Objective-C?

UIKit is part of Cocoa Touch, the framework you use to build iPhone and iPad apps. For the sake of simplicitly, we can state that Cocoa Touch has been around since the inception of the App Store and 3rd-party apps in 2008.

UIKit is the gold standard.

Building apps with UIKit revolves around Storyboards (and XIBs), view controllers, views and Auto Layout. App development on iOS makes use of the Model-View-Controller architectural design pattern, which has been an approach to build software since the 1970s and 80s.

Here’s a quick example of a view controller:

class PlacesViewController: UIViewController, MKMapViewDelegate, UITableViewDelegate, UITableViewDataSource
{
    @IBOutlet var mapView:MKMapView?
    @IBOutlet var tableView:UITableView?

    override func viewDidLoad()
    {
        super.viewDidLoad()

        mapView?.delegate = self
        ···

What you see in the above code isn’t all of it. In UIKit, a Storyboard or XIB is used to scaffold or outline a UI. You use Interface Builder to drag-and-drop UI components into a view or view controller. You use Auto Layout and constraints to make it adaptive to different screen sizes. Outlets connect UI elements with code.

It’s only natural that most apps today are built with UIKit. With 4+ million apps in the App Store, only a tiny fraction of apps will be built with SwiftUI. This is dynamic is aggravated by the fact that SwiftUI isn’t backwards compatible. SwiftUI “2.0” only runs on iOS 14, and the initial version of SwiftUI doesn’t go further back than iOS 13.

It’s worth noting that the Cocoa Touch framework consists of many more frameworks than UIKit and SwiftUI. We’ve already discussed MapKit, but there’s also Foundation, ARKit, Core Data, URLSession, Core Graphics, and much more. UIKit and SwiftUI only concern themselves with the visual layer of apps.

Now that we’ve got an idea about what UIKit and SwiftUI are, let’s discuss if you should learn one instead of the other. How do they stack up in real-world apps?

“I’ll only use UIKit in my job”

It makes sense, right? Why learn SwiftUI if you’re only going to use UIKit in your day-to-day work. After all, most apps today are using UIKit. Chances are your (next) employer uses UIKit, too!

If you want to become a professional app developer – or if you are – chances are that your skill level with UIKit matters more than SwiftUI. Let’s deconstruct that argument, for a bit.

Declarative UI

SwiftUI is a declarative UI framework, which is different from an imperative framework. In short, declarative UI means you merely declare what you want for a User Interface and you’ll let the SwiftUI framework figure out how to synthesize it on screen. Imperative programming, conversely, means explicitly coding it yourself: do this, do that, and here’s how.

Web apps, including cross-platform tools like React Native and Flutter, already use declarative UI extensively. SwiftUI is kinda late to the party, actually. It’s not unthinkable that your career, in the future, involves more declarative UI than it does now.

Even if you aren’t going to use SwiftUI specifically, it pays dividends to learn more about declarative UIs. The same goes for reactive frameworks like Combine, as opposed to the event-driven approach UIKit uses.

Up to Spec or Beyond?

As a general rule, never just do what a job requires you to do. Why? Because if you can build an app up to spec, the company you work for can find someone else who can do the same, except cheaper, faster and with fewer mistakes.

App development and design is more creative work than it is industrial assembly line work. If you merely do the work that’s required, you’re losing out on the opportunity to do better work. That could affect your opportunities for career growth.

This is of course an argument of a grander scale, and it doesn’t only affect learning SwiftUI. We can make it smaller: learn new things at work, and find out if you can use them to make existing products and processes better.

Author’s Note: The arguments you read in this tutorial come from real app developers. Over the past few months I’ve discussed SwiftUI vs. UIKit with many people, from both sides of the table. What I’m recommending in this tutorial is the same as what I’ve recommended to them.

“SwiftUI is incomplete and/or lacks documentation”

Why jump in now, if you can jump in later? It’s scary to code apps with bleeding-edge technology. Things might not work. You might get uncomfortable. Should you embrace the status quo or innovate?

Embrace the Status Quo

SwiftUI is new – no doubt about it. It’s not exactly beta software, but it’s not completely bug-free either. In fact, a quick look around the iOS development community on Twitter tells you that building a production quality app with SwiftUI means you’ll deal with plenty of bugs and strange edge-cases.

On top of that, a commonly heard argument against SwiftUI is that it lacks documentation. The documentation isn’t easily disseminated by a beginner developer. Because SwiftUI apps have many working parts, even with the documentation in hand, it’s hard to see how it all fits together.

OK, so the documentation sucks. This shouldn’t reflect on SwiftUI itself, which still has a lot of potential. As a pragmatic developer, this merely means that learning and mastering SwiftUI is going to take more effort than you initially hoped.

Looking at the popularity of tools like React and Flutter, it would be a surprise if SwiftUI won’t slowly catch on. We can look back at Swift vs. Objective-C, too. Swift was met with a lot of skepticism at first, and look at it now: It’s out of the question that you’d begin learning iOS development with Objective-C now!

Embrace Process and Innovation

Here’s a personal story: A long time ago, I attended a conference talk about a new JavaScript framework called Famo.us. This new framework was going to disrupt web technology, because it could deliver the smooth UI experience that other web app frameworks could not – smoothness on par with native apps.

Even then, I had seen it all before. I used to code web apps with jQuery. Then came jQuery Mobile. Then Ionic, Xamarin, Cordova. Web 2.0 happened somewhere. HTML 5 even got a logo. Semantic web, anyone? Facebook ditched their web app for native. Heck, I was genuinely excited about ActionScript 3 and got pretty good at it.

Years later, Famo.us is now a web page builder. Flash is a good story on my CV, but not a skill anymore. There are more JavaScript frameworks than you could ever master, and an equal number that are lost and forgotten. Flutter and React Native have had a great run, but… What will replace them?

When you look at new technology from this perspective, you’d be inclined to not learn SwiftUI. But the opposite is true. Learning new technology weaves as a red thread through the career of any professional developer.

When you embrace learning new things, you become good at learning. It’s all you need to learn the newest technology, and benefit from it, until it becomes obsolete, and you learn the next.

This is not Hype-Driven Development, because you can take insights from any of these technologies and apply them to your next project. Some experiences will stick, and that is exactly what increases and solidifies your skillset as a software developer!

Next Steps: Learn UIKit and SwiftUI

Should you learn SwiftUI and/or UIKit? Yes!

  • Learn SwiftUI first if you’re new to iOS development. Make sure you don’t miss out on fundamentals that are good to have, like Object-Oriented Programming, Model-View-Controller, MVVM, and delegation.
  • Learn SwiftUI next if you’re an intermediate-level developer. It’s fun, it’s good practice, and SwiftUI is here to stay. You might pick up some juicy insights along the way!
  • Learn UIKit if your (next) job requires you to, but don’t stop there. Learn SwiftUI next, and look for ways you can use SwiftUI to make your current work better. Keep doing that; it’s the fast-track to career growth.

A few tutorials that’ll help you learn SwiftUI:

And some tutorials about UIKit:

Further Reading

Looking for more ways to grow your career as a professional iOS developer? Check out these resources:

LearnAppMaking

LearnAppMaking

At LearnAppMaking.com, app developers learn how to build and launch awesome iOS apps.