The 3 Levels of Swift Concurrency
Swift Concurrency is really bl**dy complicated, which is great for me, financially. Swift’s whole deal is making it really hard to write broken code: type-safe nullability, automatic memory management, and compiler guarantees around data races. This is the whole reason your codebase suddenly grew 14,000,001 compiler warnings around non-Sendable classes. The Swift team were not being jerks, they wanted you to think about data isolation. In a rare spurt of Apple humility, the team acknowledged this unintentional complexity in the Approachable Concurrency manifesto: Swift’s built-in support for concurrency has three goals:
Swift meets the first goal, but it comes at the cost of the second, and can be frustrating to adopt. Progressive disclosure is a core Apple design philosophy: make basic options easy to access, but reveal advanced use cases when needed. Think Dock → Finder → bash shell for working in your file system. The same approach applies to language design. Easy to get started. Straightforward to level up when needed. Thus the Swift 6.2 Approachable Concurrency story began. Your concurrency journey now has 3 levels: If you come to Jacob’s Tech Tavern for the 3-line summaries, my work here is done. But these 3 bullet points conceal a lot of complexity. Admittedly, it was all pretty unclear to me until I wrote this. Fundamentally, the new world revolves around 2 new settings in Xcode:
The 3 levels don’t strictly have anything to do with concurrency: they’re more about how tightly you’re coupled to the main actor. From Xcode 26, new projects are opted into approachable concurrency and default MainActor isolation. Clear as mud, right? It’ll make sense when you read the article. As always, I created a sample project that will allow you to play around with the threading debugger yourself. Level 1: Main Actor 4 LifeIn understanding Approachable Concurrency, you have to understand the incentives and motivations of Apple Inc., the business. The target audience for most Apple frameworks and features is the marginal developer. The one picking between SwiftUI and React Native, and most at risk of defecting to (grits teeth) Android or (shudder) the web if their needs aren’t met. 90% of budding indie devs don’t give a sh*t about performance, because a workout tracker, AI recipe planner, or fart app doesn’t need parallelism. It needs to work out of the box and find product-market fit. By default, Swift now puts these devs in baby mode to protect them from themselves.
The safest possible starting point is a single-threaded app. And most apps don’t actually need much more than that. Users are happy because random concurrency bugs don’t ruin their experience; and devs are happy because they get to keep 69%** of the cash spent on their app (after the 30% Apple tax and the 1% RevenueCat fee*).
Serial main actor execution is the first-class mode in Swift 6.2.
Really! Check out the sample project and try to run non-async code off-main in Level 1. It’s impossible. Erm, mostly. Concurrent mutation of shared state, and data races more broadly, are rendered impossible. This serialised code is also easy to reason about: everything runs on the main actor, so you can shut up and ship.
Level 2: Async and SerialLook, this is probably the trickiest part to get your head around. But, basically, in Level 2, your Swift code turns into JavaScript. I know. The horror. We introduce async operations, but all our code, and critically, our data models, remain single-threaded, isolated to the main actor. This is the really important bit: Yeah, I’d love to help you learn Approachable Concurrency. For money. Paid members also get Elite Hacks, advanced concurrency training, and my free articles one month early 🚀 Continue reading this post for free in the Substack app
|
