Software Dev

A Case For Force-Unwraping! Optionals in Swift

This topic came up at work last week, with lots of different opinions on how to deal with optionals, so I was happy to see a clear opinion here.

๐Ÿ‘‰ The Danger of Playing it Safe

For any non-programmers reading this, a force-unwrap means that if your app comes across a value that just simply doesn’t exist at all โ˜, then let the app crash right then and there ๐Ÿ’ฅ.

This article distinguishes between development, where it’s okay (and in sometimes encouraged) to crash, and production, where it’s never okay. I like the case here for avoiding poisoned app states that can occur with nil values. Just die already, already! ๐Ÿคท๐Ÿปโ€โ™‚๏ธ This article basically says that some development crashes are good because they expose problems, and to take a more aggressive approach with force unwrapping.

So be assertive with forced unwrapping. If there is no case where the optional should ever be nil, force unwrap

I think I’ll start taking more chances with force unwrapping and point to this article next time it comes up in a code review. ๐Ÿ˜‰

Via iOS Dev Weekly.

Software Dev

Learn to Love Throwing in Swift

I really like the points made in this article about Swift error handling: using throw/try/catch is actually much better than returning optionals or the new Result type.

๐Ÿ‘‰Benefits of using throwing functions (try) – Swift’s most underrated feature?

Throwing errors, when used throughout your codebase, helps you reduce and simplify code. It makes your unit testing easier too.

As a former Java programmer, I have to admit some hesitance to throw anything. Java error handling can turn into a nightmare of its own.

But the author makes some compelling arguments why throwing might make sense in Swift. Error handling is never fun; let’s do it the easy way. ๐Ÿคท๐Ÿปโ€โ™‚๏ธ

In a related note, Re: Making Wrong Code Look Wrong also talks about the benefits of throwing in Swift, in particular with relation to local reasoning. ๐Ÿ‘

Via iOS Dev Weekly.

Software Dev

What Adding Dependencies Will Do To Your App in 2020

I like the title of this article because it recognizes that pulling third-party dependencies into your app has a cost.

๐Ÿ‘‰ What Adding Dependencies Will Do To Your App in 2020

And yet we all do it because it also has its benefits. ๐Ÿคฆ๐Ÿปโ€โ™‚๏ธ๐Ÿ˜‚

That article is a realistic and practical look how the dependencies affect your app in terms of app launch times, app size, and build times. It compares Swift Package Manager ๐Ÿค“, Carthage ๐Ÿคท๐Ÿปโ€โ™‚๏ธ, CocoaPods ๐Ÿ˜ฌ, manual dependency management ๐Ÿฅบ, and Git Submodules ๐Ÿคฎ.

I still have a dream of zero dependencies ๐Ÿคฉ, but I know it’s not realistic in a complex app. ๐Ÿ˜‘

Via iOS Dev Weekly.

Software Dev

We All Hate Error Handling. Here Are Some Tips.

Error handling makes everything more complicated. Ugh! What do you do if a network call times out (pretty common)? Or you’re trying to save an image and there is no disk space (less common but can happen)? Or that thing that’s never supposed to happen happens (occasionally happens)?

I mean, you have to do something, right? Ugh. ๐Ÿคฆ๐Ÿปโ€โ™‚๏ธ

Here are some tips. Thanks to Swift By Sundell for giving this topic some attention.

๐Ÿ‘‰ Propagating user-facing errors in Swift

Via iOS Dev Weekly.

Software Dev

Uber’s Piranha Eats Your Stale Code

Feature flags are a great way to selectively introduce new features. it allows you to experiment and commit incrementally.

The only down-side to feature flags all the extra code, and in particular going back later together rid of all the crusty flag code flagging you feature on or off. This kind of tech debt can really pile up over time.

Apparently Uber uses feature flags in the thousands and without remorse. So they came up with this automatic way to wipe out your stale, disabled code. Perfect name, too!

๐Ÿ‘‰ Introducing Piranha: An Open Source Tool to Automatically Delete Stale Code | on GitHub

Via iOS Dev Weekly. See also: The Mother of All Feature Flagging Systems for iOS