Swift Optionals - Is Force Unwrapping THAT Bad?

In this clip from Swift News, I showcase a Twitter thread that discusses the idea of "never ever force unwrap optionals". In my opinion, there are situations where a force unwrap has benefits, but to be clear... those situations are the exception to the rule and will be rare. If you are just learning Swift and a beginner, it's probably best to default to always unwrapping.

But the reason I wanted to share this was to get experienced developers to think a bit and get out of the blind, absolutist mentality of "never ever force unwrap".

If you like my teaching or presentation style, I've started creating my own courses:

Twitter:

Link to my book - How I Became an iOS Developer:

Book and learning recommendations that help out the channel if you decide to purchase (Affiliate Links):

Paul Hudson's Hacking With Swift:

Donny Wals - Combine:

Mark Moeyken’s SwiftUI Books:

Ray Wenderlich Books:

Links to my iOS Dev Setup & iOS Dev Book Recommendations

#swift #softwaredeveloper #iosdeveloper

[travisc]

The timing of “subscribing” and your animation for subscribe to the channel 👌🏻

[kevyyt]

For vars that COULD be nil for a valid reason, I always guard them and write and test recovery code. For vars that should never be nil, I always force unwrap so I get a hard crash right away instead of a lingering “why doesn’t this work”. Right?

[wayknowblog]

Kindly post 1-2 minutes tips or tricks video about SWIFT FUNDAMENTAL or ESSENTIAL videos we would be happy to watch those. Thanks for your work.

[wmblemania]

The only places I use force unwrapping:
- when you have a resource or URL that must exist. i.e. it is a developer error if the resource does not exist.
e.g. the URL you supplied in code is badly formed, or an image is missing from an Asset Catalog (as opposed to an image missing online.)
As for Optionals in general, they're useful, but should be kept to a bare minimum.

[sharanraj]

If we are 100% sure that a optional variable will contain a value than 100% go with force unwrapping. But if u are not sure whether it will have a value go with conditional binding. In a project we would be dealing with lots of optional variables so it would be difficult to track them and remember whether they would definitely have the value or not hence most of the developers community in Swift recommend to go with conditional binding.

[ranjanmondal]

Hey Sean ! I have question ? If force unwrapping is bad . Why apple use required type for @IBOutlet ?

[deltaKilo-M]

Interest about app settings page in ios settings list

[AnhLe-vbei]

Hi Sean, is there any solution to use enum as IBInspectable property in IB? I can't find it

[sidharthjdev]

I guess this is gonna be an absolutist statement, but I don’t think there is any situation where Force Unwrapping is a better way than a guard-let or if-let unwrapping. I would agree that there could be times when it is fine to do so and it won’t crash the app. But the advantage is really about the readability of code and reducing clutter. Not a programatic advantage.

Feel free to correct me if I am wrong or interpreted your opinion wrongly.

[michaellatta]

When the code is first written, it may be safe. As a code base evolves, it may not be safe. Better, to always safely unwrap. If the force unwrap fails the app crashes.

[karlostj]

Like all "Thou Shalt Not" edicts in programming, there are always benefits and risks to doing just about anything. It's akin to wars about religion. Are there issues with using singletons? Absolutely. Yet frameworks like Apple's UIKit and Android's CookieManager (among others) use them. So (a) always research the pros/cons of doing something like force-unwrapping optional and (b) always comment why you're choosing to do that particular something.

[gjermundification]

00:37 Always force unwrap while drafting; for iOS force unwrapping is usually bad for produciton, for development I'd argue it's good. For linux / mac command line tools may be purposeful.

[lukajackson]

I still think force unwrapping is really bad.

because you never know what happens in the future. someone could change the code later and some API changes may arise making the forcefully unwrapped variable nil aand having your app crash.

force unwrap when you are developing and debugging but do not merge it to the master branch is my way to go

[leifashley]

I tried to listen and will check the twitter thread. As an early adopter of swift beta 1, my first comment from day 1 was never ever force unwrap, so you could almost blame this stance on me lol.

If it's hard to read, that straight up means you can't read swift well. Get better. Never should you trade a cornerstone feature of a framework like swift because it's slightly inconvenient to read. Our job relies on apps never ever crashing. Optionals fix 90% of those crashes because usually it's a null pointer.

I'll say this realizing some won't like it, but if you think force unwrapping is something that should be permissible, then you have a long way to grow in software architecture and shouldn't be leading teams. After 30 years in software, optionals fix the #1 issue on every platform / language I've worked in. Experience makes that clear, those that don't see the value in using it, just don't have the experience.

Ok - off my soapbox, and off to twitter. Still - I like that Sean brought the topic up. This is something all swift developers need to clearly understand.