NSPersistentCloudKitContainer.share()死锁及权限持久化问题

开发背景 #

基于Swift 6严格并发的iOS 16 SwiftUI应用，使用带私有/共享存储的NSPersistentCloudKitContainer实现CloudKit区域共享，目标是生成无需邮件邀请、支持公开读写的Core Data对象图共享链接。

问题1：非prepareShare闭包内调用container.share()触发UI死锁 #

现象 #

无论使用后台上下文、全局队列还是异步方法，只要不在CKShareTransferRepresentation.prepareShare闭包内调用container.share()，就会出现UI死锁：完成回调或await永远不返回，仅在prepareShare闭包内调用无此问题。

死锁复现代码 #

DispatchQueue.global(qos: .userInitiated).async {
    let bgContext = container.newBackgroundContext()
    var obj: NSManagedObject?
    bgContext.performAndWait {
        obj = try? bgContext.existingObject(with: objectID)
    }
    container.share([obj!], to: nil) { _, share, _, error in
        // 永远无法进入此回调
    }
}

原因与解决方案 #

NSPersistentCloudKitContainer.share()方法在严格并发模式下，内部依赖特定的线程/Actor隔离逻辑，外部调用容易触发Core Data上下文同步与主线程的锁竞争。而prepareShare闭包是系统专为共享流程设计的安全入口，内部已处理好并发隔离与线程安全。

强制要求：所有共享创建逻辑必须放在prepareShare闭包内执行，避免在外部手动调用share()方法。同时替换同步阻塞的performAndWait为异步的perform方法，符合Swift并发规范。

问题2：share.publicPermission设置无法持久化，调用persistUpdatedShare死锁 #

现象 #

在prepareShare闭包内设置share.publicPermission = .readWrite后，权限无法同步到CloudKit服务器，始终为.none，导致接收方点击共享链接时提示“Object not available”；尝试调用persistUpdatedShare保存更改时，即使作为“即发即弃”操作也会触发死锁。

无死锁但权限失效的代码 #

return .prepareShare(container: ckContainer) {
    let bgContext = persistentContainer.newBackgroundContext()
    let obj = try await bgContext.perform {
        try bgContext.existingObject(with: objectID)
    }
    let (_, share, _) = try await persistentContainer.share([obj], to: nil)
    share.publicPermission = .readWrite
    return share
}

原因与解决方案 #

仅修改share对象后返回，系统不会自动将权限变更同步到CloudKit；直接调用persistUpdatedShare会与prepareShare闭包的内部流程产生线程冲突，引发死锁。

正确实现：在prepareShare闭包内，使用创建共享对象的后台上下文异步执行persistUpdatedShare，避免阻塞主线程或系统共享流程：

return .prepareShare(container: ckContainer) {
    let bgContext = persistentContainer.newBackgroundContext()
    bgContext.automaticallyMergesChangesFromParent = true
    
    let obj = try await bgContext.perform {
        try bgContext.existingObject(with: objectID)
    }
    
    let (_, share, _) = try await persistentContainer.share([obj], to: nil)
    share.publicPermission = .readWrite
    
    // 在后台上下文异步持久化共享权限变更，避免死锁
    try await bgContext.perform {
        try persistentContainer.persistUpdatedShare(share, in: bgContext)
    }
    
    return share
}

同时确认CloudKit Schema已正确部署，共享实体的权限配置支持公开读写。

问题3：孤立区域元数据是否会导致死锁 #

现象 #

控制台出现遗留的共享尝试生成的孤立区域元数据：zone的needsShareUpdate = 1但encodedShareAsset = nil。

结论与解决方案 #

这类孤立元数据会干扰CloudKit的同步流程，可能导致后台同步任务阻塞，进而引发死锁。建议清理：

• 通过Core Data上下文查询对应的CloudKit元数据实体，删除needsShareUpdate = 1且encodedShareAsset为空的条目，保存上下文；
• 开发环境下可调用container.resetPersistentStores()重置本地缓存（注意备份数据），生产环境需谨慎操作。

内容的提问来源于stack exchange，提问作者LevelOne2k