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

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.

Software Dev

Swift Algorithms

Apple announced an open-source algorithms project with some very over-the-top, flashy language. πŸ˜‰

I’m excited to announce Swift Algorithms, a new open-source package of sequence and collection algorithms, along with their related types.

πŸ‘‰ Announcing Swift Algorithms

This library seems to be a sort of farm league for things that might make it to big leagues of the Swift Standard Library eventually.

Swift Algorithms lets you do just about anything you can think of with a collection (or two). It lets you do stuff like rotate [10, 20, 30, 40, 50, 60] to [30, 40, 50, 60, 10, 20], or find all possible permutations of [10, 20, 30], and lots of other things like chunking, random sampling, etc. Fun. πŸ€“

Via iOS Dev Weekly.

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.