How to make SwiftUI modifiers safer to use with @warn_unqualified_access

Paul Hudson @twostraws December 1st 2022

Updated for Xcode 14.2

Every SwiftUI makes the same mistake at some point, and sadly it’s something you’ll do more than once: rather than writing .someModifier() you write someModifier(), and it causes your app to completely freeze or crash with EXC_BAD_ACCESS.

First I’ll show you the how to solve the problem, then I’ll explain what the underlying problem is. The solution is to use Swift’s @warn_unqualified_access attribute, which means you can’t access properties or methods without using a variable name or similar.

For example, if we had a titleStyle() method that added a bunch of modifiers to a view to make it matching a custom theme, we’d use @warn_unqualified_access before the method signature, like this:

extension View {
    @warn_unqualified_access
    func titleStyle() -> some View {
        self
            .font(.largeTitle)
            .fontWeight(.black)
            .padding()
            .background(.blue)
            .foregroundColor(.white)
            .cornerRadius(10)
    }
}

When we use that, we’d write the same SwiftUI code we always did:

struct ContentView: View {
    var body: some View {
        Text("Welcome")
            .titleStyle()
    }
}

That works exactly as expected – the extra attribute hasn’t made the method behave differently at all in normal circumstances.

However, take a look at this code:

struct ContentView: View {
    var body: some View {
        Text("Welcome")
            titleStyle()
    }
}

That’s subtly different: I removed the dot before titleStyle(), which is an unqualified access – I haven’t said where I’m calling titleStyle(), so SwiftUI assumes I’m actually calling it on ContentView. This means it’s actually calling self.padding(), so we have an infinitely recursive view and ultimately a crash.

Sadly, SwiftUI doesn’t use @warn_unqualified_access with its own modifiers, but you can at least add it for the custom ones you build.