Software Dev

Everything you need to know about [weak self]

This is a post about the idea of “weak self” in the Swift programming language. It is not a post about self-doubt. You are strong. You are capable. You matter. 😉

But your Swift object might be weak, or at least @escaping and weakly held. 🤷🏻‍♂️ If this makes no sense, maybe it’s time to check out some pictures or quotes.

If you’re a Swift programmer, you probably know that if you need a reference to back to the calling self in a closure, and that closure might last longer than self, then you should send that closure yourself as [weak self] so you don’t end up with a retain cycle and a memory leak.

Still, it can get a bit confusing. What do you do if the weak self is actually gone when you execute the closure? Can the weak self disappear in the middle of the closure?

Fortunately, the Swift blogger Christian Tietze has all the answers. Or at least he has found some answers and summarized them nicely.

In the end, it all points to Chris Downie’s rules of thumb.

Only use a strong self for non-@escaping closures (ideally, omit it & trust the compiler)

Use weak self if you’re not sure

Upgrade self to a strongly-retained self at the top of your closure.

Via iOS Dev Weekly.

Software Dev

Why asynchronous programming is (was) hard

One of the most difficult things about mobile development is asynchronous programming, which means doing different things at the same time. This is not the normal flowchart-style sequence of traditional programming.

Weirdly enough, with Swift completion handlers, an asynchronous function exits before it finishes. Or if you’r not careful, it might never finish at all. 🤯

Oh no! This is entering annoying quantum mechanics territory. 😭

If none of this makes any sense to you, then you’re not alone.

All of this is why I love the following video from WWDC 2021. Nate spends the first eight minutes showing how downloading an image and generating a thumbnail quickly becomes “verbose, complex, and even incorrect” in traditional Swift programming. (Side note: I like how Nate apparently worked hard on his hand gestures as well.)

The payoff: Nate then explains how async/await will let you write asynchronous code basically like “regular code.” 🤩