Migrating to Swift 6

How we learned Swift and realized we needed to migrate to Swift 6. Sharing our experience with the migration and how tools like Cursor made it easier.

March 8, 2025

The Journey to Swift

My journey in Software Engineering has been an interesting one. If you asked me five years ago, I never would have guessed I would be writing Swift, let alone writing a blog post about migrating to Swift 6. At this point, I have worked across the stack, from managing infrastructure on AWS, Azure, and GCP, to scaling backend services, frontend development, and now desktop apps.

Swift was easy to get started with—the syntax is clean and overall not too difficult with SwiftUI and SwiftData—but concurrency was a significant challenge in Swift 5 as I was learning and vibe-coding for the first version. I had written the initial version of my app in Swift 5, and it was a bit of a mess. I constantly ran into race conditions and other concurrency issues, and debugging was painful. Users couldn't run the app consistently.

Why Swift 6?

I'm only four months into Swift, so I'm not an expert by any means, but after struggling with concurrency issues, I decided to take the plunge and migrate to Swift 6. The migration took about three full days of grinding, but in the end, it was absolutely worth it. Since then, I've rarely received reports of concurrency issues; if anything, problems have mostly come from underlying libraries that haven't been migrated yet.

Improved Concurrency Safety

The most compelling reason to migrate to Swift 6 is its enhanced concurrency model. Swift 6 introduces an opt-in language mode that extends Swift's safety guarantees to prevent data races in concurrent code. The compiler can now diagnose potential data races as errors rather than just warnings.This is particularly valuable for applications that rely heavily on concurrent operations.

In my case, this was a game-changer. Our application processes real-time audio streams, performs on-device transcription, and runs machine learning inference simultaneously. With Swift 6, these concurrent workflows now operate reliably without the mysterious crashes and data corruption issues we previously encountered. The compiler now catches potential race conditions at build time rather than letting them manifest as runtime bugs, saving countless hours of debugging and significantly improving the user experience.

Better Sendable Inference

In Swift's concurrency model, Sendable is a protocol that marks types as safe to share across concurrent boundaries (like between different actors or tasks). Think of it as a stamp of approval that says "this data is safe to send between different parts of your concurrent code." Types that conform to Sendable are guaranteed to be either immutable or have their mutations properly synchronized. Some types like actors are inherently Sendable and don't need to be annotated. Read more about actors here.

There's also @unchecked Sendable, which is essentially an escape hatch—a way to tell the compiler "trust me, I know what I'm doing" when marking a type as safe for concurrent access. However, it's considered a dangerous practice because it bypasses Swift's safety checks. Using @unchecked Sendable means you're taking full responsibility for ensuring thread safety, which can lead to subtle bugs if not handled correctly. It's generally recommended to avoid @unchecked Sendable unless absolutely necessary and you fully understand the implications.

Sendable was introduced in Swift 5.5 but users complained about false positives. Swift 6 improves Sendable inference with fewer false positives compared to Swift 5.10. This means the compiler is better at determining when data can safely cross actor boundaries, reducing the need for manual annotations and making concurrent code more reliable.

Other Notable Improvements

Ownership Improvements: Better support for non-copyable types with the generics system
C++ Interoperability: Expanded support for C++ move-only types, virtual methods, and default arguments. This is great for me as some LLM libraries like whisper.cpp and llama.cpp are written in C++.

For me, the concurrency improvements alone justified the migration effort. The three days spent refactoring my codebase have paid off many times over in reduced bugs and improved stability.

Read the full Swift 6 announcement for more details on all the new features and improvements.

Our Migration Strategy

1. Preparation and Setup

Before diving into the migration process, I recommend starting with the official Swift 6 migration guide. This comprehensive resource provides essential context for the changes you'll need to make.

To streamline the process, I found using an AI coding assistant like Cursor invaluable. I loaded relevant Swift 6 documentation into Cursor Docs, which allowed me to quickly reference official guidelines while coding. You can simply paste documentation links directly into Cursor, and it will parse the content automatically.

When using AI assistants, explicitly instruct them to avoid suggesting @unchecked Sendable — these models often default to this escape hatch when encountering complex concurrency challenges, which defeats the purpose of migrating to Swift 6's safer concurrency model.

2. Stop the Bleeding

This is going to depend on the size of your project and team, but the first thing I did was add build flags to throw warnings for any errors that may arise in Swift 6. Any new code should not introduce any more warnings.

In my case, I added the following to my Main.xconfig file:

-enable-upcoming-feature DisableOutwardActorInference -enable-upcoming-feature GlobalConcurrency -enable-upcoming-feature InferSendableFromCaptures -strict-concurrency=complete

For more information on how to use the upcoming feature flags, check out the Swift Blog.

3. Tackling the Migration

Unfortunately, I used a ton of Singletons and global state, so I had to do a lot of work upfront to migrate these. Swift 6 patterns almost forced me to move away from Singletons entirely. While Singletons were a convenient way for me to handle shared state, abandoning the pattern made my code easier to reason about. Some singletons became actors and others became Global MainActors.

For the business logic, I took a dependency-first approach:

Started with files that had the fewest external dependencies (leaf nodes in my dependency graph)
Gradually moved towards the core files that many other components depended on
Experimented with different combinations of Actors, MainActors, and Sendable Classes—there's no one-size-fits-all solution. I threw out a lot of code and started over multiple times.

Working from dependencies inward also helped me avoid issues with complex classes having too many dependencies that aren't "Sendable".

When I got stuck or needed ideas, I would reference documentation and additional guides (see links below) and give them to Cursor/Claude to help me out. LLMs generally do a good job with migration suggestions, but again, remember to check that they're not using @unchecked Sendable—LLMs tend to overuse that escape hatch when they encounter difficult concurrency problems. It's also important to understand and learn why they're making the suggestions they are.

Key Takeaways

Swift 6's concurrency model is a significant improvement over Swift 5
The migration process is challenging but worthwhile
A systematic approach focusing on dependencies helps manage the complexity
Moving away from singletons and global state improved my code quality
The right tools (like Cursor) can significantly speed up the migration process