Since the introduction of Swift, our behavior towards nil values have greatly changed. Swift brings type safety, and also works hard to prevent sending messages to nil by introducing Optionals. Optionals force you to write guards around your optional code at compile time using “optional binding” which, while making your code more secure, also makes it look a bit messy.
Implicitly unwrapped optionals behave like optionals: they can be set to nil, you can use optional chaining on implicitly unwrapped optional variables, and can check them for nil equality. The only difference between them is that implicitly unwrapped optionals are a promise to the swift compiler that it’s value will NOT be nil when accessed at runtime.
Or as it is expressed in the Apple’s Swift Programming Book: “An implicitly unwrapped optional is a normal optional behind the scenes, but can also be used like a non optional value, without the need to unwrap the optional value each time it is accessed.”
However if you try to use an implicitly unwrapped optional that has a value of nil, you’ll get a runtime error.
Motivation behind
So why on earth did the Apple engineer’s introduce such a feature that makes the language unsafe? The short answer is because your Cocoa code would look awfully messy if they hadn’t!
When writing an iOS app, we have tools from Interface Builder like Storyboards. The problem we have when using Interface Builder is connecting our visual elements to our code through IBOutlets. Because this is done after object initialization all outlet variables would have to be defined as optionals. But then your code would be littered with if lets whenever you want to access these outlets.
However when we are using InterfaceBuilder we can rely on it that it will create our references correctly at runtime. If it doesn’t the app will crash anyway! So implicitly unwrapped Optionals are a workaround app developers don’t have to declare outlets as optionals and produce messy code.
When to use unwrapped optionals
Apple explains this very well in their Swift book:
“Implicitly unwrapped optionals are useful when an optional’s value is confirmed to exist immediately after the optional is first defined and can definitely be assumed to exist at every point thereafter. The primary use of implicitly unwrapped optionals in Swift is during class initialisation.”
In other words you should only ever mark a variable as an Implicitly Unwrapped Optional if you can guarantee that it will NOT be nil at the time it’s called. In my opinion there are only three cases that fulfil this precondition:
- When referencing an object from interface builder. Means all
IBOutletscan be defined as implicitly unwrapped optionals. - When you have a property that can’t be populated during initialisation. Many view based classes (i.e.
UIViewControllers) have their initialisation split up into phases. - When interacting with an external framework you have no control of.
