Concurrency's Past: Threads

Just a little over 9 months ago, Swift 5.5 was released and with it came an all new suite of tools for tackling concurrency. We very briefly touched upon some of these tools in past episodes, like when we explored the new .refreshable view modifier in SwiftUI for adding pull-to-refresh to any view.

That exploration was interesting, but also a little superficial. We are ready to dive much deeper into Swift concurrency, and the main reason we want to do this now is because we are also ready to start more deeply integrating Swift’s concurrency tools into the Composable Architecture. In order to do that in the best way possible we are going to need understand a number of concurrency topics, many of which are quite subtle and tricky.

In this series of episodes we want to provide an introduction to most of the new tools that Swift has given us for modeling concurrency. The way we are going to do this is through a lens focused on the past. Apple platforms have a rich history of concurrency tools, from threads to dispatch queues, and most recently, Combine publishers. In order to understand why Swift’s modern concurrency APIs were designed the way they are, and what problems they try to fix, we must know how we got to this point. What did the previous tools excel at, and what were their faults? This will make it easier for us to learn how to use Swift’s new tools, understand why they sometimes don’t work the way we expect, and overall we will be more proficient at using the new APIs.