Swift 6: The Industry-Wide Migration to Data-Race Safety

Guest

Hey Alex! Thanks for having me. It’s... well, it’s an "interesting" time to be a Swift developer, that’s for sure. I feel like my life has been one giant quest to satisfy the compiler lately.

Host

(Laughs) I bet! I’ve seen the memes of people opening their projects in Swift 6 mode and seeing two thousand errors pop up. Before we get into the "how-to" of the migration, let’s go back to basics for a second. Why is Apple making us do this? What is a data race, actually, and why is it so insidious?

Guest

Right, so, at its simplest, a data race is when two different parts of your code—two different threads—try to touch the same piece of memory at the same time. And at least one of them is trying to change it.

Host

And that’s the "ghost" I was talking about. It’s non-deterministic.

Guest

Exactly! It depends on the CPU timing, the heat of the phone, what else is running... it’s a nightmare. Swift 6 is basically saying: "We aren't going to guess anymore. We’re going to prove, at compile time, that this can't happen."

Host

Which sounds amazing in theory, but when you actually flip that switch to Swift 6 mode in Xcode... what happens? Walk me through that "aha" moment—or maybe that "oh no" moment—you had at OrbitScale.

Guest

(Chuckles) Oh, it was definitely an "oh no" moment first. We have a codebase that’s about six years old. We thought we were pretty good at concurrency. We used Combine, we used locks where necessary. But when we opted into "Strict Concurrency Checking," the compiler basically screamed at us.

Host

Interesting! So for those who haven't hit this yet, what does `Sendable` actually mean? Why is the compiler suddenly so grumpy about our objects?

Guest

It’s basically a marker. It tells the compiler, "This type is safe to be passed across different threads." If it’s a `struct` with only value types, it’s usually Sendable by default because a copy is made. But if it’s a `class`—a reference type—you’re passing a pointer. If two threads have a pointer to the same object, you’re back to square one with data races.

Host

Let’s talk about Actors. That’s the big solution Swift 6 pushes, right? Moving legacy patterns into the Actor model. How has that refactoring process been for your team?

Guest

It’s a total shift in mindset. Actors are great because they ensure that only one task can access their internal state at a time. It’s like having a bouncer at the door of your object.

Host

That sounds like it could lead to a lot of "callback hell" or just a massive amount of `Task { @MainActor in ... }` blocks being sprinkled everywhere. Is that a trap people are falling into?

Guest

Oh, absolutely. That’s the "Band-Aid" phase. You just want the errors to go away, so you wrap everything in a `Task` or use `@MainActor` on every single class. But if you put `@MainActor` on everything, you’re basically making your app single-threaded again, which defeats the purpose of having powerful multi-core processors.

Host

I love that you mentioned deleting code. Sometimes the best refactor is just simplification. Was there a specific part of the app that was particularly stubborn during this migration?

Guest

Our networking layer was the boss fight. We had these complex completion handlers that were capturing self, doing some logic, then calling another completion handler. Making all of that "Sendable" was a nightmare because the compiler couldn't guarantee that the closure wouldn't be called on a different thread while modifying the caller's state.

Host

That sounds like a huge win. But for a smaller team or a solo dev listening to this, who might be overwhelmed by the sheer volume of changes... where do they start? You can’t just rewrite your whole app in a weekend.

Guest

Definitely don’t do it all at once! Swift 6 allows for a staged migration. You can keep your project in Swift 5 mode but turn on "targeted" concurrency warnings.

Host

That’s a great tip. The `@preconcurrency` thing is definitely a lifesaver when you're stuck with an SDK that hasn't been touched in two years.

Guest

(Pauses) That’s a tough one. In the short term? Yes. The learning curve is steeper. You can't just throw a `class` together and call it a day anymore. But in the long term? I think it makes it easier.

Host

"The compiler is the mentor." I love that. It’s frustrating when it’s yelling at you, but it’s doing it because it cares about your users! (Laughs)

Guest

Exactly! It’s a very protective mentor.

Host

So, looking forward—once the industry-wide migration is mostly "done," let’s say two years from now—what does the Swift ecosystem look like?

Guest

I think we’ll see a new standard of stability. We’re going to stop seeing those "unexplained" crashes. We’ll see more performant apps because we’ll actually be using concurrency correctly instead of being afraid of it. Honestly, I think we’ll look back at the Swift 5 era and think, "How did we ever ship code without these checks?" It’ll feel as primitive as manual memory management feels to us now.

Host

Marcus, this has been so enlightening. It’s clear that while the migration is a mountain to climb, the view from the top is going to be worth it. Thank you so much for sharing your "war stories" from OrbitScale.

Guest

My pleasure, Alex. Good luck to everyone out there battling those Sendable errors! You can do it!