Everything was working perfectly fine in your application for multiple years. Then one day a simple configuration change of a flag resulted in over 20,000 warnings for you to handle. Welcome to Swift 6, where your working code yesterday is a compiler error today. ## The change nobody asked to be default
WWDC 2024 introduced Swift 6, which was then reinforced and solidified in 2025 and 2026. The main highlight of Swift 6 was default data-race safety, achieved by strict concurrency checks during compilation (and strict concurrency checking is now on by default). The pitch is actually good. The compiler now mathematically proves your code has no data races before it even runs. This is important because data races were a serious issue. According to Apple's WWDC 2024 sessions, they caused almost 30% of crashes in production iOS apps. This means that an entire category of Heisenbugs disappears. Theoretically, this is a significant advantage. Sendable closures and actor isolation don't play nice with code written before they existed.
Writing for Level Up Coding in December 2025, iOS developer Alok Upadhyay flipped the Strict Concurrency Checking flag on his team's largest legacy module and got 20,000 warnings, describing his screen as "a sea of red and orange warnings." Another common issue is referred to as "whack-a-mole". For example, on the Swift.org forums in April 2025, a developer mentioned that they added @MainActor to all classes to fix the errors and 50 more appeared. That loop ate half a week before the thing finally built. Three and a half days were spent verifying that code which had already been sent for production was correct. Also, you don't have control over everything. For instance, a developer porting Ditto Edge Studio in June 2026 observed that a single dependency "can hold your entire module hostage" if it's not ready for Swift 6 (even if your code is perfect). This was not an unusual edge case in the early days. In the June 2024 beta, roughly 42% of packages were reported as ready (1,500 of 3,400), but that number included a lot of packages that weren't using any concurrency code. ## But the payoff is real, and that's the annoying part
I want to dislike this rationally. I am unable to. An iOS developer, nicknamed "BB", ported three production apps to the new library, roughly 180,000 source lines of code in total. As of September 2025, he experienced a 41% decrease in crash rates and determined that actors contribute to only a 5 to 8% performance overhead under high contention. That is not a minor adjustment. It means less 3am notifications and fewer negative reviews for you. Mrugesh Tank, co-founder of idiotswithios.com, decided to switch on Swift 6 for a two-year-old-project in August 2026. The second he did that, he got bombarded with 60+ errors. At least a dozen were real bugs. Actual data races and actor isolation violations hiding in shipped code. The compiler wasn't nitpicking. It was actually detecting issues. ## So where does that leave us
Here's the stress I continue to experience:
→ The safety guarantee is legit and the bug it kills is expensive. → The migration cost is also legit and lands entirely on teams who already shipped fine. → Making it the default forced that bill on everyone at once, ready or not. That final point is what it's all about. 🔥
It's not necessarily a bad thing to invest three sprints to implement a safety feature. It's more of a compromise, where the cost is being covered by the teams whose applications were not failing due to data races anyway. Strict concurrency should have remained optional for a while longer, and the ecosystem should have been further along before forcing it as a build cost. Because "mathematically correct" and "worth it this quarter" are different questions. Are you going to flip the flag on a working legacy app today, or are you going to wait until Apple forces your hand?
Top comments (0)