We’ve all seen them [Apple] do it: nonchalantly defining @IBOutlets as implicitly unwrapped optionals, by appending a ! to their type declarations. Isn’t this supposed to be a big no-no among True Swift Developers? You’d think so, since we’re told that stray exclamation points are often ominous precursors to pesky runtime crashes.

You could argue that declaring outlets as optional weak properties is preferable, as it sidesteps the runtime exception situation altogether. A reasonable rationale.

However, I’d like to challenge this nugget of common sense, and entertain the idea that using a ! here instead of ? is also acceptable.

A quick syntax refresher

In general, outlets form the glue that connect user interface elements – defined in Storyboards or XIBs – to their programmatic counterparts. If you’re the type to eschew Storyboards, here’s a quick syntax refresher:

@IBOutlet weak var profileButton: UIButton?

The @IBOutlet marker imposes no side-effects and can be omitted, if so desired. Personally, I like to have them there, as it makes them easier to call out afterward. The storyboard instantiates, manages and retains the actual button, so it suffices to hold a weak reference.

However, weak also makes the property optional, which is why we need the ? at the end.

The cost of using Optionals

?s are nice and safe, but their use comes at an undeniable cost. In order to be read, they need to be systematically unwrapped with if let or guard let. A minor inconvenience, for sure, but guard statements are prone to popping up all over the place, if not corralled consciously.

Catching mistakes in outlet wiring

Littering guard let statements up the wazoo makes you feel dirty too, I’m sure, but this can be overcome. What trips me up each time, however, is what happens if you hook up an outlet improperly (or simply forget to!).

  • Use an optional, and you’ll be scratching your head – like me – every time. The outlet will remain nil, your controller will initialize properly and you’ll be left clueless as to why something feels amiss.
  • Use an IUO!, and your app will crash 💥. This uncomfortable side-effect will provide an immediate cue, as the stack trace will reflect exactly which property is acting up. As a result, you’ll fix up your oversight swiftly, with no time wasted.

While I’m not quite sure if I should retroactively convert my existing outlet declarations, I started using ! a while ago and still feel good about it.

Favor crashes, over Optionals, in case of developer error

I agree we should strive toward a 100% crash-free rate, but for clear developer errors, I tend to favor a hard crash. I’ve found that selective use of IUO’s, and their resultant crashes, can actually provide a boost to developer productivity.

Truly, I’m not trying to be contrarian. A well placed ! just happens to be the fastest route to “success”, in this case.

P.S. You may get the impression that I use Storyboards, because I use outlets. I don’t 😎.

Previous ArticleNext Article

Leave a Reply

Your email address will not be published. Required fields are marked *


Android device debugging on Linux Mint: “error: insufficient permissions for device: udev requires plugdev group membership”

As I rejoiced in the achievement of finally finding a Linux distro which plays well with my Dell XPS 13 (2019 edition, model 9380), I plugged in my Moto test device, intending to continue working on an Android app. Pressing the Run button promptly made Android Studio (3.4) do its compilation magic, but got stopped in its tracks rather quickly. An angry-looking error message awaited me:

error: insufficient permissions for device: udev requires plugdev group membership

Oops, no device debugging for you.

Android Studio also left a note pointing me to their developer page on the subject. As I suspected, it seemed I had some configuration work left to get device debugging working on Linux. However, following Google’s instructions on setting up adb didn’t do much to resolve my problem. The part about adding yourself to the udev group is important, though, as it’s linked to the actual solution described in the next paragraph.

sudo usermod -aG plugdev $LOGNAME

Adds your user to the plugdev group.

Update: Someone mentioned recently that the below steps may not actually be required; just logging out and back in again at this point, should also do the trick. YMMV of course :-).

An ill-timed dog walk (let’s just say I hadn’t expected to be caught in the middle of a downpour), and a few mildly frustrated Google searches later, I ran across a blog post from 2013 (!) on the subject of “Adding udev rules for USB debugging Android devices“, by Janos Gyerik.

I will not pretend to know why this extra configuration is required, but it describes looking up the device’s identifier and adding it to the aforementioned plugdev access group, so Android Studio can properly access the USB device.

And there you go, a working USB debugging connection to my Android device, thanks to some great advice from 2013!