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.
Available from iOS 8.0
Did this solution work for you? Please pass it on!
Other people are reading…
About the Swift Knowledge Base
This is part of the Swift Knowledge Base, a free, searchable collection of solutions for common iOS questions.
Download for free!
Want a free 75-minute video teaching functional programming, protocol-oriented programming, and more? This is your lucky day!