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

“What you can see here is that I was learning…”

I love this post from swiftjectivec.com.

πŸ‘‰ Things I Made That Sucked

Not only does he detail the interesting stories of some old apps he made, but also the valuable lessons learned from each app that he shipped.

Highlights

Aim first, then shoot. “Ask yourself why you’re doing what you’re doing and channel your excitement into less action and more thinking before you fire away.”

Pace yourself and don’t complicate. “Take time to learn about design and holy moses don’t toss in an open source project just because it’s shiny.”

There is no overnight success. “Always remember that character is carved out rather than instantly created. Each of these misses can eventually add up to a win.”

My own lessons

Applying the same thought process to my own old sucky apps, here is what I come up with…

Where in the World is Santa Claus?

Ignorance is bliss. I genuinely thought it would be easy to make an augmented reality Santa tracker as my very first iPhone app. Who cared that built-in AR support on the iPhone was years in the future?

I understood that I’d have to learn Objective-C and Xcode as I went. However, I did not appreciate how much there was to learn about location APIs, motion APIs, audio APIs, audio editing, 2D animations, CoreData, the State Pattern, linear algebra 🀯, the terrors (at the time) of shipping in the App Store, plus legal/privacy matters. Also why not translate the app into six languages, starting with Spanish?

And all just to see Santa blink on your screen when you pointed your iPhone north. πŸ˜†

My blissful ignorance allowed me to jump in fearlessly and forced me to conquer a mountain of challenges as I went (or quit).

This app only ever sold a few hundred copies but was a goldmine of experience and made me a mobile developer.

Bedtime Balloons

Simpler is better. App #2 was more useful and less technically challenging than the AR Santa app. Bedtime Balloons let me get into some fun art and more interesting animations. Plus this app actually made a difference in at least a few people’s lives.

Third-party frameworks can kill your app. At the time, there was no standard 2D animation engine for iOS. SpriteKit was not a thing yet. πŸ€·πŸ»β€β™‚οΈ So just like the Santa app, I built the animations around the very nice Cocos2d engine, which would eventually morph and evolve and… break my app. πŸ€¦πŸ»β€β™‚οΈ Yeah, I could have rewritten my app, but again only selling a few hundred copies, I chose to avoid all the sweat and tears and just move on.

Continuous Math Cards

Be practical. I never expected to sell many copies of my barebones but highly configurable math flashcards app for kids.

Written quickly in the new (at the time) Swift language, the app was alright. πŸ€·πŸ»β€β™‚οΈ But it worked for me professionally. My next step would be a full-time day job as an app developer, which had long been my dream.

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.” 🀩

Software Dev

Introducing Swift Collections

Swift Collections is out with some new collection-oriented extensions on the Swift language as a companion to Swift Algorithms and Swift Numerics.

πŸ‘‰ Introducing Swift Collections | github

Swift Collections gives you hybrid collection types like Deque, which is an array with “efficient insertions and removals at both ends”, OrderedSet, which is a “powerful hybrid of an Array and a Set”, and OrderedDictionary (like the actual dictionary).

And of course, they’re efficient. Now go forth and collect in new ways!

Software Dev

The Singleton Pattern – When There Can Only Be One β˜οΈ

Like so many smart and courageous people, the Singleton design pattern is often misunderstood.

Whether it is attacked as an anti-pattern, maligned as untestable, or misused as a global convenience, singletons take a lot of πŸ’© for just being what they are: a way to enforce that there is only ever one of something. I think they should call this pattern “The One”.

A real life example of a singleton is The President of the United States. We only ever have one president at a time. That’s a key part of the concept. It’s not just a convenience.

In software terms, singletons make sense in many cases such as the one and only instance of the current app running on the current iPhone.

With all this in mind, this quick post provides some nice context about singletons (aka the President) versus just a shared instance (hey, let’s all share this one bike) in Swift.

πŸ‘‰ What’s the difference between a singleton and a shared instance in Swift?

Thanks to iOS Dev Weekly for calling out the ongoing confusion on this topic. πŸ™

Software Dev

Motion πŸ’“

This ο£Ώ-centric open-source animation library looks promising.

πŸ‘‰ Motion on GitHub

Motion

Motion is an animation engine for gesturally-driven user interfaces, animations, and interactions on iOS, macOS, and tvOS.

I’ve been a little skeptical of open-source animation platforms since I had to toss out one app and then another as cocos2d morphed into cocosd2x and broke everything. Damn that x! But still, this looks cool. πŸ‘†

Via iOS Dev Weekly.

Software Dev

The Elm Architecture

I’ve been trying to understand the Elm Architecture for a new iOS project. I kept reading over this article and thinking, “Wait a minute…. What’s the catch here? This seems too simple.” 🧐

πŸ‘‰ The Elm Architecture: Simple, yet powerful – An overview by example

I like that this architecture can be explained in a very short post with examples.

The beauty of The Elm Architecture lies in its simplicity.

That article is simple but assumes a web UI and explicit mentions HTML πŸ™„. Here is a funnier and more useful article about Elm for iOS. πŸ˜‚

πŸ‘‰ Elm architecture in iOS: Why you don’t need shit like RxSwift or MVVM

Elm architecture can be described as follows

msg -> Model -> View -> msg

I even made my own diagram just to make sure I “got” it. The devil is in the details, but I think this is right. πŸ€·πŸ»β€β™‚οΈ It definitely seems simpler than VIPER.

Software Dev

The Swift Concurrency Roadmap

The Swift Concurrency Manifesto has now produced Swift Concurrency Roadmap (pull request). So that’s progress.

Our goal is to make concurrent programming in Swift convenient, efficient, and safe.

Once implemented, this roadmap will let you write this mess…

This way. πŸ‘

The roadmap contains “nurseries” for creating child tasks πŸ˜†, and something called “actor isolation”, starting with “basic actor isolation”. I can’t help but picture a bad actor sitting around his apartment in L.A. πŸ€·πŸ»β€β™‚οΈ

There’s also a solid glossary of what these terms really mean.

Via iOS Dev Weekly.

Software Dev

Syncing Made (Kind of) Easy in Swift

Here’s a pretty amazing series and GitHub repo on mastering sychronizing data across iOS devices.

πŸ‘‰ Replicating Types in Swift

This is a really tough thing to do well, so this series looks incredibly helpful. The central idea is Conflict-Free Replicated Data Types (CRDTs).

I like this teaser under the headline “Where is the server?”

There is no truth β€” decentral apps rely on trust rather than truth.

Via iOS Dev Weekly.