Announced at WWDC 2019, SwiftUI (associated to Combine) will be unavoidable starting from September 2020 (iOS 14).

1. The power of SwiftUI

1.1 Concise and declarative syntax

Developing with SwiftUI requires less time thanks to a declarative construction and bidirectional bindings (interactions). This modern syntax is greatly appreciated when coming from (verbose) UIKit, which reminds us of Objective-C style (despite the fact that I loved coding with Obj-C!).

Here is how to create a simple login form:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

import SwiftUI

struct ContentView: View {
    
    // MARK: Properties
    
    @State var email: String = ""
    @State var password: String = ""
    
    // MARK: Body
    
    var body: some View {
        // NavigationView is similar UINavigationController.
        NavigationView {
            // Specify we want a "form" user interface.
            Form {
                // Make one section for the text fields.
                Section {
                    TextField("Email", text: self.$email)
                    SecureField("Password", text: self.$password)
                }
                // Make a second section for submit button.
                Section {
                    Button(action: { /* handle action */ }) {
                        Text("Submit")
                    }
                    .frame(maxWidth: .infinity)
                }
            }
            .navigationBarTitle("Login")
        }
    }
    
}

Notes:

  • The @State (a property wrapper) indicates to Apple that the interface should be updated whenever the value has been changed.
  • The $ from self.$property allows a bidirectional binding.
  • It may be easier for non-technical persons to learn some basics ; but prototype tools will (as usual) handle most of the work.
  • This example code misses a lot logic (like all the user-experience), but you got the idea.

1.2 Cross (Apple) platforms

iPhone, iPad, Apple Watch, Mac and Apple TV… you name it!

With one set of code you can target most of Apple platforms. You still need to have proper knowledge on how each platform works in order to construct the proper user experience. However the hassle to support all of them is reduced ; which is good news for everyone (Apple, developers, and users).

1.3 Reconciliation

It should reconcile the worshipers of storyboards and “from scratch”, and you don’t have to bother with auto/manual layout anymore (as long as you stick to SwiftUI grounds).

Directly in SwiftUI view class, you can code and drag & drop. Use the library pop-up to easily find components and modifiers.

Example image

1.4 Blazing fast

While I couldn’t measure it myself yet, it seems that SwiftUI was designed to be as fast as possible and it easily outpaces UIKit for primary graphics. You’ll stop drawing within drawRect and embrace the declarative way.

2. The limitations of SwiftUI

2.1 Is it the right time to use SwiftUI?

SwiftUI is new, and it’ll require at least iOS 14 or iOS 15 to resolve most bugs and limitations (like it did for Swift). That’s why you probably didn’t see any “major app” going full SwiftUI yet. Note that it’s not a full replacement for UIKit or the end of it, SwiftUI still wrapps lots of UIKit components (like UITableView), and it’ll likely stay this way for a long time.

However, creating small apps and POCs is totally “safe” despite some uncontrollable bugs. And if you support the two latest iOS versions (as recommended by Apple), then you should be “good to go” in a few months.

2.2 More to learn (for new developers)

For experienced developers, it’s quite an interesting (and exciting) framework to learn! However for new developers, it may be a bit frustrating. On the one hand, it brings a modern way to code and architect apps, and, on the other hand, it isn’t a short path to Apple development: they’ll still have to learn Cocoa frameworks (UIKit & co). You won’t be able to only use SwiftUI for your apps as you’ll need to bridge with UIKit from time to time. So you may be able to achieve 90% with SwiftUI, but the last 10% will call back the ancient beast.

It may even be worse than that, and incite developers to use even more third-party libraries for specific needs (to bridge with UIKit), as you could see in cross-platform tools. While using external source code may be unavoidable, it should be done with caution.

2.3 Another fracture for companies

The shortage of developers is always an issue for companies. As a result, developers often dictate some technical directions, and thus some product and business logic. While SwiftUI may bring more people (and even non-technical people) to Apple development, it’s certainly a tool that developers will prefer. They even may choose a job based on this technology, forcing companies to upgrade. As we saw for the migration between Objective-C and Swift, we may see one between Cocoa and SwiftUI (and probably more similar frameworks).