One thing I see people struggle with when they first move into control flow is the belief that a switch statement is just a "cleaner" version of an if-else chain. They think, "I'll just use this when I have a lot of conditions to make the code look prettier."

Here is why that mindset will get you into trouble in Swift: in many other languages, if you miss a case in a switch, the program just skips it and moves on. In Swift, the compiler will scream at you. If you're switching over an enum, Swift demands that you handle every single possible case. You can't just "forget" the edge case where the user is offline or the data is corrupted; the language forces you to decide what happens there before the code even runs.

Stop Treating Switch as Optional and Start Embracing Exhaustiveness

I've spent way too many hours debugging "silent failures" in other languages because I forgot one else if. In Swift, the switch is a safety tool. Take a look at this example involving a game state:

enum GameState {
    case mainMenu
    case playing
    case paused
    case gameOver
}

let currentState = GameState.playing

switch currentState {
case .mainMenu:
    print("Show the start button")
case .playing:
    print("Update game physics")
case .paused:
    print("Show the pause menu")
// If I forget .gameOver here, the code won't even compile!
case .gameOver:
    print("Show the high score screen")
}

The magic here isn't the syntax; it's the fact that if I add a .loading state to my enum later, Swift will highlight every single switch statement in my entire project and tell me exactly where I need to add logic for that new state. That is a massive lifesaver in large projects.

Flattening the "Pyramid of Doom" with Guard

You'll see a lot of beginners writing nested if statements. You know the drill: you check if the user is logged in, then you check if they have a subscription, then you check if the file exists. Suddenly, your code is indented so far to the right that it's practically off the screen. I call this the "Pyramid of Doom."

The fix is the guard statement. Think of guard as a bouncer at a club. Instead of saying "If you're on the list, you can come in (and then I'll check your ID, and then I'll check your age...)", guard says "If you aren't on the list, get out now."

func processPayment(amount: Double?, userIsVerified: Bool) {
    guard let actualAmount = amount else {
        print("Invalid amount provided.")
        return 
    }
    
    guard userIsVerified else {
        print("User needs verification.")
        return
    }
    
    // Now we are in the "happy path." 
    // No more nesting!
    print("Processing payment of $\(actualAmount)")
}

I always prefer guard for validation. It keeps the "happy path" of your function aligned to the left margin, making the logic way easier to scan at a glance.

Looping Without Losing Your Mind

Swift's for-in loop is the workhorse here. You'll mostly use it to iterate over collections or ranges. But don't forget the while and repeat-while loops for when you don't actually know how many times you need to run the code.

One quick tip: use continue to skip the rest of the current loop iteration and break to kill the loop entirely. I use continue all the time when filtering data manually inside a loop to avoid wrapping the entire loop body in another if statement.

let scores = [85, 42, 91, 33, 78]

for score in scores {
    if score < 50 {
        continue // Skip the failing scores
    }
    print("Processing passing score: \(score)")
}

The repeat-while loop is the odd one out—it's basically a while loop that guarantees the code block runs at least once before checking the condition. It's less common, but useful for things like asking a user for input until they provide a valid response.

📋 Practical Task

Build a Smart Home Device Controller

Your task is to create a function that simulates a smart home device controller. You will need to handle different device states and validation checks using the control flow tools we just discussed.

Requirements:

• Create an enum called DeviceStatus with the following cases: on, off, standby, and error.
• Write a function called updateDevice(status: DeviceStatus?, batteryLevel: Int).
• Use a guard statement to ensure the status is not nil. If it is nil, print "No status provided" and exit the function.
• Use another guard statement to ensure the batteryLevel is above 5. If it is 5 or lower, print "Battery too low to operate" and exit.
• Use a switch statement on the status to print the following:
  • .on: "Device is fully operational."
  • .off: "Device is shut down."
  • .standby: "Device is in power-saving mode."
  • .error: "Device requires a technician."

Test your code with these scenarios:

updateDevice(status: nil, batteryLevel: 10)         // Should trigger first guard
updateDevice(status: .on, batteryLevel: 3)            // Should trigger second guard
updateDevice(status: .standby, batteryLevel: 50)      // Should print "Device is in power-saving mode."
updateDevice(status: .error, batteryLevel: 20)        // Should print "Device requires a technician."