Swift Defer Tutorial

The Swift defer keyword lets you schedule a block of code to run right before the current scope exits, no matter how it exits. Whether your function returns normally, returns early because of a guard statement, or throws an error, the code inside your defer block will always run.

Think of it like setting up a “cleanup crew” the moment you open something. You hire them right away, but they do their work on the way out. That way, you never have to remember to call them yourself.

In this article, you’ll learn exactly how defer works in Swift, walk through the most common ways to use it, see how it shows up in real iOS code, and understand the mistakes that trip up beginners. By the end, you’ll know when to reach for it and when to leave it alone.

The Basic Syntax

Here is the simplest possible use of defer in Swift. Read through it, then look at what gets printed and in what order:

func makeBreakfast() {
    defer {
        print("Washed the dishes")
    }

    print("Made coffee")
    print("Made toast")
}

makeBreakfast()

// Output:
// Made coffee
// Made toast
// Washed the dishes

Even though “Washed the dishes” is written first in the function, it prints last. That’s defer in action. Let’s break down each part:

Breaking It Down

What “scope” means here

A scope is just the area between a pair of curly braces. A function body is a scope. An if statement is a scope. A for loop is a scope. When Swift sees a defer block, it waits until that surrounding scope is finished, then runs the deferred code.

For most beginners, the scope you care about is the function. You write defer near the top of a function, and it runs right as the function is about to return.

defer runs on every exit, not just the normal one

This is the key insight. Your function might have three different guard statements that can return early. Without defer, you’d need to put your cleanup code in all three places. With defer, you write it once and it runs no matter which exit path is taken.

Does Swift defer execute on return?

Yes. The deferred code runs after the return value is prepared but before the function actually hands control back to the caller. This means a defer block cannot change the value a function returns, but it will always run before the return completes.

Multiple defers run in reverse order

If you write multiple defer blocks in the same scope, Swift runs them last-in, first-out. Think of it like a stack of plates: the last one you put on top is the first one you take off.

func stackExample() {
    defer { print("First defer") }   // runs third
    defer { print("Second defer") }  // runs second
    defer { print("Third defer") }   // runs first
    print("Regular code")             // runs first of all
}

// Output: Regular code, Third defer, Second defer, First defer

What is the difference between defer and deinit in Swift?

defer runs at the end of a scope (usually a function call). deinit runs when a class instance is destroyed and removed from memory. They are completely separate tools. Use defer for function-level cleanup; use deinit for object-level cleanup.

Variations and Syntax Patterns

Here are the most important ways you’ll see and use defer in Swift code. Each one builds on the same idea but applies it in a different context.

func processUser(id: String?) {
    defer {
        print("Processing finished") // runs no matter what
    }

    guard let userId = id else {
        print("No user ID provided")
        return // defer still runs here
    }

    guard !userId.isEmpty else {
        print("User ID is empty")
        return // and here
    }

    print("Processing user: \(userId)")
} // and at normal exit too

func saveData() throws {
    print("Opening connection")
    defer {
        print("Closing connection") // runs even if an error is thrown
    }

    let result = try fetchDataFromServer()
    print("Saving: \(result)")
}

for item in ["apple", "banana", "cherry"] {
    defer {
        print("Done with \(item)") // runs at end of each iteration
    }
    print("Processing \(item)")
}

// Processing apple / Done with apple
// Processing banana / Done with banana
// Processing cherry / Done with cherry

func processItems() {
    do {
        defer {
            print("Cleaned up the temporary buffer")
        }
        print("Working with temporary data...")
    } // defer runs here, at the end of the do block

    print("Back in the main function")
}

// Working with temporary data...
// Cleaned up the temporary buffer
// Back in the main function

func captureDemo() {
    var status = "starting"
    defer {
        print("Final status: \(status)") // sees the updated value
    }
    status = "completed"
    print("Did the work")
}

// Did the work
// Final status: completed

func loadUserProfile() {
    isLoading = true
    defer {
        isLoading = false // always hides the spinner
    }

    guard let userId = getCurrentUserId() else { return }
    guard let profile = fetchProfile(for: userId) else { return }
    displayProfile(profile)
}

How swift defer Appears in Real iOS Code

Let’s look at a realistic iOS example. This is a view model method that fetches a list of posts from an API. It uses defer to guarantee the loading state is always cleaned up, and wraps things in proper error handling.

import SwiftUI

class PostsViewModel: ObservableObject {
    @Published var posts: [Post] = []
    @Published var isLoading = false
    @Published var errorMessage: String?

    func fetchPosts() async {
        isLoading = true

        // This guarantee means we NEVER leave the spinner on by accident.
        // Every early return, every thrown error, every success path
        // will all hit this defer block before exiting.
        defer {
            isLoading = false
        }

        guard let url = URL(string: "https://api.example.com/posts") else {
            errorMessage = "Invalid URL"
            return // defer runs here
        }

        do {
            let (data, _) = try await URLSession.shared.data(from: url)
            let decoded = try JSONDecoder().decode([Post].self, from: data)
            posts = decoded
        } catch {
            errorMessage = error.localizedDescription
        }
        // defer runs here at the end of the function normally too
    }
}

Here’s why each decision was made:

Setting isLoading = true before the defer is intentional. The spinner turns on immediately. The defer turns it back off at the very end, no matter what path the function takes.

The guard statement for the URL can return early if the URL is invalid. Without defer, you’d need to add isLoading = false inside that guard’s else block. With defer, you don’t.

The do/catch block handles any errors from the network request or JSON decoding. Whether it throws or succeeds, the defer block still fires on the way out.

This is the kind of code you’ll write regularly in real iOS apps. Any time you have a boolean flag that needs to be reset, or a resource that needs to be released, and there are multiple ways the function might exit, defer is the clean solution.

When Should I Use defer in Swift?

Defer is not something you’ll need in every function. But it’s exactly right in several common situations. Here’s a quick map of when it earns its place:

• 🔒

  Locking and unlocking

  If you lock something at the start of a function (like a thread lock or a database write lock), defer ensures you unlock it before returning. Forgetting to unlock is a classic source of freezing apps and deadlocks.

• 📂

  Opening and closing files or connections

  Whenever you open something that needs to be closed — a file handle, a database connection, a network session — put the close call in a defer right after the open. That way they always stay paired together.

• ⏳

  Loading states and spinners

  Whenever you show a loading indicator at the start of a function, defer is the cleanest way to make sure it always gets hidden. No matter how the function exits, the spinner turns off.

• 🪵

  Logging and analytics

  Sometimes you want to log how a function ended regardless of the outcome. Putting the log call in a defer means it always fires, and because defer captures variables by reference, it can even log the final state of your data.

Common Mistakes to Avoid

Mistake 1: Expecting defer to change the return value

You might assume that if you modify a variable inside a defer block, that modification will change what the function returns. It won’t.

func getScore() -> Int {
    var score = 10
    defer {
        score = 99 // this does NOT change the return value
    }
    return score // returns 10, not 99
}

print(getScore()) // prints 10

The return value is captured when the return statement is reached. The defer runs after that, so any changes it makes to the variable are too late to affect what gets returned.

Mistake 2: Using return inside a defer block

You can’t use return, break, or continue inside a defer block. Swift won’t let you exit the current scope from inside the block that’s supposed to run during that exit. It would create a logical paradox. Xcode will give you a compile error if you try.

Mistake 3: Thinking defer runs at the point where you write it

New Swift developers sometimes read code with defer and think the deferred code runs right there, in order with everything else. It doesn’t. The deferred code is registered when that line is hit, but it doesn’t execute until the scope is exiting.

func confusingOrder() {
    defer { print("B") } // registered first, runs last
    print("A")            // runs immediately
}
// prints: A, then B

This is the concept that takes most beginners the longest to internalize. The way to think about it: defer is a promise, not an action. You’re promising Swift “do this before leaving.” The promise is made when you write it, but fulfilled when you exit.

Mistake 4: Writing complex logic inside defer

Defer blocks should be short and focused. If you find yourself writing ten lines of business logic inside a defer, that’s a sign something has gone wrong. A defer block that’s hard to read defeats the purpose of using it. Keep deferred code to a single action or a short cleanup sequence at most.

Quick Reference

Here’s a scannable summary of everything you’ve learned about defer in Swift:

Using AI to Go Deeper with swift defer

AI coding assistants like Claude, Copilot, and ChatGPT are part of how modern developers work. Knowing how to prompt them well is itself a skill. Here are three categories of prompts designed to help you actually understand defer, not just copy code that uses it.