Back in June, we shared our Apple WWDC19 highlights – one of which was the introduction of SwiftUI. After spending the last few months exploring this new Apple UI framework in-depth, I came up with the following insights into getting started with SwiftUI.

‍But wait, what is SwiftUI?

SwiftUI is an API that lets us write UI code in a declarative way. This means writing your code in such a way that it describes what you want to do and not how you want to do it. SwiftUI provides views, controls, and layout structures for declaring your app’s user interface.

Declarative programming is the contrary of imperative programming which is what the iOS community are used to.

In an imperative language, we use a sequence of statements to get an outcome. Let’s use a login screen as an example, where we want to show a username field, a password field and login button.

In this screen, for example,  we can have three states:

• State 1: The user isn’t logged. So we just show the username and password text fields and the login button.
• State 2: The user entered the authentication process by tapping the login button and it failed. In this case, we want to display an error message saying the information was wrong.
• State 3: The user entered their username and password, tapped the login button and it succeeded. In this case, we want to display text saying the login was successful.

So, we basically have to write code to handle all different scenarios.

In contrast, declarative code will handle the state all at once. SwiftUI can move between user interface layouts when the state changes. We already told it what to show based on whether the user was logged in or out so, when we change the authentication state, SwiftUI can update the UI on our behalf.

Let’s look at how we can handle the different states with Swift UI. For the purposes of this demonstration, let’s handle the second state.

We declare a State property of a boolean type and set its default value to false:

<p>CODE:"https://gist.github.com/WildStudio/3ebb7ed6e7d3ff2a7d3d572aea994146.js"</p>

When the State’s value becomes true that means that the authentication process failed. In this case, we want to show a Text object with an error message. We, therefore, write the following:

<p>CODE:"https://gist.github.com/WildStudio/252e87e7a1e806c68439f9adb20da36e.js"</p>

That’s what it means by declarative: we aren’t making SwiftUI components manually show and hide. We’re just informing it of all the rules we want it to follow and trust in SwiftUI to enforce them.

Is Apple killing UIKit?

No. Many parts of SwiftUI directly build on top of existing UIKit components. Apple keeps adding new functionalities to UIKit so there’s no need to worry just yet!

Furthermore, SwiftUI runs on iOS 13, macOS 10.15, tvOS 13, and watchOS 6, and any future later versions of those platforms. This means if you work on an app that must support the current version and one or two before that – it will be a year or two before you can even think of moving to SwiftUI.

Getting started with SwiftUI

You need macOS Catalina and Xcode 11 Beta in order to have SwiftUI render the canvas properly.

Create a new project including SwiftUI

In Xcode-Beta just go ahead as usual and create a new project and select ‘Single View App’:

Make sure SwiftUI is checked before you finally create your project:

The Single View App template includes the following files:

1. The well-known AppDelegate.swift.
2. SceneDelegate.swift. This is responsible for managing the way your app is shown, such as letting multiple instances run at the same time or taking action when one moves to the background.
3. ContentView.swift. This is our initial piece of user interface. If this were a UIKit project, this would be theViewController class that Xcode gave us.

SceneDelegate.swift is responsible for managing the way your app is shown. Go ahead and open SceneDelegate.swift and you’ll see code like this:

<p>CODE:"https://gist.github.com/WildStudio/547bffa9562b1e97eb93580a3b2bd3bb.js"</p>

That code above creates a new ContentView instance and places it inside a window so it’s visible onscreen.

Open ContentView.swift and let’s look at some actual SwiftUI code. You should see code like this:

<p>CODE:"https://gist.github.com/WildStudio/3c9eadc4c26d169d5d6aee14604379a9.js"</p>

Notice ContentView is a struct. Yay! Bye-bye mutability! With SwiftUI, we get to benefit from all of the immutability and simplicity of value types for our user interface!

ContentView conforms to the View protocol. Everything you want to show in SwiftUI needs to conform to View and you need to have a property called body that returns a view. That’s it!

Inside the body property, there’s Text(“Hello world”). This creates a label of the text, ‘Hello World’.

Finally, there’s the ContentView_Previews.

This is specifically there to show view previews inside Xcode. This is why you’ll see it inside #if DEBUG and #endif lines – this code is only built into the finished product when our app runs in a debug environment.

And those are the very basics when it comes to getting started with SwiftUI. In a future post, I’ll be exploring the components that we introduced in this very post.

---

Have you experimented with SwiftUI yet? If so, what are your thoughts? Tweet us and we’ll be sure to retweet the responses!

We Are Mobile First is a digital product agency based in Barcelona helping to transform businesses in a mobile-first world. Follow us on Twitter, LinkedIn and Medium to be notified of our future posts and stay up-to-date with our company news.

We share weekly content on everything from time management for developers to how to create a container framework.

‍

(image credit: Apple Developer)