Why does Swift make us unwrap optionals?

Paul Hudson    @twostraws    May 28th 2020

Updated for Xcode 14.1

Swift’s optionals can either store a value, such as 5 or “Hello”, or they might be nothing at all. As you might imagine, trying to add two numbers together is only possible if the numbers are actually there, which is why Swift won’t let us try to use the values of optionals unless we unwrap them – unless we look inside the optional, check there’s actually a value there, then take the value out for us.

There are several ways of doing this in Swift, but one of the most common is if let, like this:

func getUsername() -> String? {
    "Taylor"
}

if let username = getUsername() {
    print("Username is \(username)")
} else {
    print("No username")
}

The getUsername() function returns an optional string, which means it could be a string or it could be nil. I’ve made it always return a value here to make it easier to understand, but that doesn’t change what Swift thinks – it’s still an optional string.

That single if let line combines lots of functionality:

1. It calls the getUsername() function.
2. It receives the optional string back from there.
3. It looks inside the optional string to see whether it has a value.
4. As it does have a value (it’s “Taylor”), that value will be taken out of the optional and placed into a new username constant.
5. The condition is then considered true, and it will print “Username is Taylor”.

So, if let is a fantastically concise way of working with optionals, taking care of checking and extracting values all at once.

The single most important feature of optionals is that Swift won’t let us use them without unwrapping them first. This provides a huge amount of protection for all our apps, because it puts a stop to uncertainty: when you’re handing a string you know it’s a valid string, when you call a function that returns an integer, you know it’s immediately safe to use. And when you do have optionals in your code, Swift will always make sure you handle them correctly – that you check and unwrap them, rather than just mixing unsafe values with known safe data.

SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.

Learn more

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