Swift 6 Strict Concurrency and 6.4 Evolution for Embedded Systems

Host: Hey everyone, welcome back to Allur. I’m your host, Alex Chan. Today, we are diving into something that—if you asked me five years ago—I might have said was a pipe dream. We’re talking about Swift. But not the Swift you use to build a fancy UI for an iPhone or a Mac. We’re going deep—like, "down to the metal" deep. Host: To help me make sense of all this, I’ve invited Marcus Thorne to the show. Marcus is a Lead Systems Architect at Orbit-Link, where they’ve been pioneering the use of Swift in industrial robotics. He’s been in the trenches moving legacy C++ systems over to Swift, so he’s seen the good, the bad, and the very, very buggy. Marcus, thanks so much for joining us on Allur! Guest: Thanks, Alex! It’s great to be here. It’s an exciting—and slightly chaotic—time to be a Swift developer, especially when you’re trying to make it run on a robot arm instead of an iPad. Host: I can only imagine! So, Marcus, let’s start with the big one. Swift 6. We’ve been hearing about "Strict Concurrency" for a while now, and for some developers, it’s been a bit of a "check engine" light they’ve been trying to ignore. Why is this such a fundamental shift? Guest: Oh, it’s definitely more than a light; it’s a full-on engine rebuild for some folks. The "aha moment" for me was realizing that we’ve just accepted data races as a way of life. You know, you have two threads trying to change the same variable at the same time, the system crashes, and you spend three days in a debugger trying to reproduce a bug that only happens on Tuesdays when the wind is blowing north. Swift 6 basically says, "No more." It moves that detection from the runtime—where it breaks in the user's hands—to the compiler. If your code isn’t thread-safe, it just won’t build. Host: Which sounds amazing in theory, but I’ve talked to devs who are... let’s say "frustrated" when they first turn it on. They get a wall of red errors. Is it really worth the friction? Guest: It is, especially in embedded systems. Think about a medical device or a car’s braking system. You *cannot* have a data race there. Swift 6 uses things like Actors and the Sendable protocol to enforce this. I remember one of our first projects at Orbit-Link—we had a sensor monitor. In C++, we used mutexes and locks everywhere, but someone eventually forgot a lock. Classic mistake. In Swift, we use an `actor`. Only one task can touch that sensor data at a time. The compiler literally won't let you "forget" to synchronize. It’s like having a senior engineer looking over your shoulder 24/7, but one who never gets tired. Host: Right! And you mentioned the `Sendable` protocol. I think that’s where a lot of the confusion lies. Can you break that down simply? Guest: Yeah, actually, `Sendable` is just a way for the compiler to say, "Is this piece of data safe to pass from one thread to another?" If it’s a simple value, like an integer or a struct, it’s usually Sendable because you’re passing a copy. But if it’s a class—a reference type where multiple people hold a pointer to the same memory—Swift 6 will stop you and ask, "Hey, how are you making sure two people don't change this at once?" It forces you to think about data ownership, which is exactly what we should have been doing all along. Host: That makes total sense. Now, let’s pivot to the "Embedded Swift" side of things, specifically the 6.4 evolution. This is really the "bare-metal" stuff. For the mobile devs listening, why should they care that Swift can now run on a tiny microcontroller? Guest: Well, first off, it means you don't have to learn a whole new, "dangerous" language to play with hardware. But the real magic in 6.4 is how they’ve stripped the language down. Historically, Swift had a "heavy" runtime. It needed a lot of memory and a full operating system like iOS or Linux. In 6.4, they’ve optimized it so you can compile it for targets that have *no* operating system. We call it bare-metal. Host: Wait, so you’re saying I could write Swift code that interacts directly with hardware registers? No OS, no "middleman"? Guest: Exactly. The binary sizes have plummeted. In 6.4, they’ve made it so the compiler can strip out everything you don't use. We’re talking about binaries small enough to fit on a chip with 64KB of RAM. It’s wild. I actually had a moment recently where we flashed a Swift binary onto a small industrial sensor, and it performed within 2% of the C version, but with all the safety of Swift. My team was just staring at the terminal like, "Is that it? It just... works?" Host: That’s the dream, right? No more segfaults at 2 AM. But what about the hardware itself? Embedded systems usually require very specific timing and direct access to things like pins and sensors. Does Swift 6.4 handle that well? Guest: It’s getting much better. The tooling in 6.4 has improved the "interop." You can call C functions directly from Swift without any overhead. So, if you have a legacy driver for a specific motor, you keep that in C, and you wrap it in a beautiful, safe Swift API. We’re seeing a lot of "high-performance system modules" being built this way. You get the speed of C with the safety of Swift’s type system. Host: I love that. It feels like we’re finally bridging that gap between the "high-level" app developers and the "low-level" systems engineers. But I have to ask—what was the biggest struggle you faced when moving to this Swift 6.4 embedded workflow? Guest: Honestly? It was the mindset shift. In the embedded world, we’re used to "manual everything." When you first see Swift’s structured concurrency—like `TaskGroups`—it feels too "easy." You keep waiting for the catch. The struggle was learning how to trust the compiler’s abstractions. Also, debugging on hardware is always a bit of a pain, but the 6.4 tooling for cross-compilation has made the "write-build-flash" loop much faster. It feels more like modern web or app dev and less like... well, the 1980s. Host: [Laughs] Hey, don't knock the 80s! But I get it. It sounds like the synergy between the safety of Swift 6 and the efficiency of 6.4 is creating this "perfect storm" for IoT and robotics. Where do you see this going in the next couple of years? Guest: I think we’re going to see a massive wave of "safe hardware." Think about medical devices, or the infotainment and control systems in your car. If those are built with Swift 6, the chance of a random system crash due to a memory leak or a data race goes down significantly. It’s going to raise the bar for what we consider "reliable" software. And for developers, it means your skills are more portable than ever. You can build the iPhone app, the server backend, and the firmware for the hardware, all using the same mental models. Host: That is such a powerful thought. A unified language for the whole stack—from the cloud all the way down to the silicon. Marcus, this has been fascinating. I think you’ve definitely convinced a few of our listeners to dust off their microcontrollers and give Swift 6.4 a spin. Guest: I hope so! Just be prepared—once you see the compiler catch a data race for you, you’ll never want to go back to C. Host: I think I’m already there! If you want to learn more about Marcus’s work or dive into the Swift.org announcements about 6.4, we’ll have all those links in the show notes. The takeaway here is clear: Swift isn't just "expanding"—it's maturing into a serious systems language that might just make our connected world a lot safer.