Core Data + CKSyncEngine with Swift 6 — concurrency, Sendable, and best practices validation

Thanks for writing the post and being willing to share knowledge with the community. I probably don't have enough cycles to review the project. Also, providing best practices on the whole thing will be hard, because synchronization is complicate, and there are corner cases that need to be handled carefully.

I think I can start with some specific aspects though, with the hope that other folks can jump in.

In general, using viewContext for UI and background contexts for background synchronization is the right pattern. I don't have more to say before thoroughly reading your code or seeing an issue.

If you can elaborate a bit about the concrete cases where you need to use @unchecked Sendable and why, I may be able to comment.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Thanks, @DTS Engineer.

Opening the project in Xcode 26 already shows some warnings in SyncEngine.swift. We can start there. I don’t want to use @unchecked Sendable.

Could you please:

1. Explain how I can remove the warnings?
2. Show how to remove @unchecked Sendable from SyncEngine.swift? If I just delete it, multiple errors appear.

The first two errors I see are:

1. Stored property 'defaults' of 'Sendable'-conforming class 'SyncEngine' has non-Sendable type ‘UserDefaults’
2. Stored property '_engine' of 'Sendable'-conforming class 'SyncEngine' is mutable

The error messages clearly pointed out that it's because a Sendable class can’t have a member variable of a non-Sendable type, and can’t have a mutable state.

Fixing the first error is easy: You can remove the member variable defaults, and use UserDefaults. standard instead when needed.

One idea to fix the second error is that you can make _engine immutable and initialize it in SyncEngine.init, as shown below, but whether this is appropriate or not depends on how you'd use engine:

final class SyncEngine {
    ...
    //private let _engine: CKSyncEngine? // Remove this.
    private let engine: CKSyncEngine 

    init(context: NSManagedObjectContext, engine: CKSyncEngine? = nil) {
        self.context = context
        self.engine = engine
    }
}

The other option is to make SyncEngine an actor, which will protect the mutable state, but you will then need to handle the cross-actor access to the public member variables and methods.

To propose a solution, I’d need to digest your current architecture, and move the discussion to that level, which I’m afraid I don’t have enough bandwidth to do.

Given that, my suggestion will be that you start with the foundational concepts of Swift 6 concurrency, then review your architecture and decide what data will be accessed concurrently (and hence needs to be protected), and go ahead to make it isolated with an actor. If you see a specific pattern that prevents you from going ahead, bring it up here with details for folks to comment (without the need of reading through your whole project). I think that will probably be a more actionable way to move forward.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.