TEAM LICENSES: Save money and learn new skills through a Hacking with Swift+ team license >>

Switching view states with enums

Paul Hudson    @twostraws   

You’ve seen how we can use regular Swift conditions to present one type of view or the other, like this:

if Bool.random() {
} else {

Tip: When returning different kinds of view, make sure you’re either inside the body property or using something like @ViewBuilder or Group.

Where conditional views are particularly useful is when we want to show one of several different states, and if we plan it correctly we can keep our view code small and also easy to maintain – it’s a great way to start training your brain to think about SwiftUI architecture.

There are two parts to this solution. The first is to define an enum for the various view states you want to represent. For example, you might define this as a nested enum:

enum LoadingState {
    case loading, success, failed

Next, create individual views for those states. I’m just going to use simple text views here, but they could hold anything:

struct LoadingView: View {
    var body: some View {

struct SuccessView: View {
    var body: some View {

struct FailedView: View {
    var body: some View {

Those views could be nested if you want, but they don’t have to be – it really depends on whether you plan to use them elsewhere and the size of your app.

With those two parts in place, we now effectively use ContentView as a simple wrapper that tracks the current app state and shows the relevant child view. That means giving it a property to store the current LoadingState value:

@State private var loadingState = LoadingState.loading

Then filling in its body property with code that shows the correct view based on the enum value, like this:

if loadingState == .loading {
} else if loadingState == .success {
} else if loadingState == .failed {

You can also use a switch block instead, like this:

switch loadingState {
case .loading:
case .success:
case .failed:

Tip: Switching over an enum has the advantage that Swift checks all our cases are covered correctly, which means if you add another case in the future you'll be told to handle it correctly.

Using this approach our ContentView doesn’t spiral out of control as more and more code gets added to the views, and in fact has no idea what loading, success, or failure even look like.

Hacking with Swift is sponsored by Superwall.

SPONSORED Superwall lets you build & test paywalls without shipping updates. Run experiments, offer sales, segment users, update locked features and more at the click of button. Best part? It's FREE for up to 250 conversions / mo and the Superwall team builds out 100% custom paywalls – free of charge.

Learn More

Sponsor Hacking with Swift and reach the world's largest Swift community!

Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

Average rating: 4.4/5

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.