What are implicitly unwrapped optionals?

Swift version: 5.6

Paul Hudson @twostraws May 28th 2019

Regular Swift optionals, e.g. String?, may contain a value, but may also contain nil – they might have no value at all – so before we can use them we must check to see what they contain. These are a useful way of expressing uncertainty, because a full String (not optional) must always contain a string.

An implicitly unwrapped optional – written as String! – may also contain a value or be nil, but they don’t need to be checked before they are used. Checking an optionals value is called “unwrapping”, because we’re looking inside the optional box to see what it contains. Implicitly unwrapping that optional means that it’s still optional and might be nil, but Swift eliminates the need for unwrapping.

Now, you might read that and think “great! I hate unwrapping optionals with if let”, but there’s a problem: if you try to use a value that contains nil your code will crash. You can’t catch the error and you can’t stop it from happening: your code will crash. Implicitly unwrapped optionals require you to be absolutely sure there’s a value there before you use them.

And now you might be thinking “why would I want to take that risk?” The usual reason is that there are some things we all know will start life as being nil, but will be non-nil by the time we need them and won’t be nil again. For example, when you create outlets using Interface Builder it creates them all as implicitly unwrapped optionals because when your view controller is being created those outlets will all be nil, but shortly after they get set to real views and those won’t be destroyed until the whole view controller is destroyed.

Broadly speaking, you should avoid implicitly unwrapped optionals unless you’re certain they are safe – and even then you should think twice.

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

Available from iOS 8.0