Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接沟通的机会。本文对本次活动中与 Core Data 有关的一些问答进行了收拾，并增加了一点个人见解。
原文发表在我的博客wwww.fatbobman.com
欢迎订阅我的公共号：【肘子的Swift记事本】
Q&A
是否可以在 Core Data 中存储相片
Q：你好，我看到一些网站主张 Core Data 不该该用于保存相片，也许他们没注意到可以运用 “运用外部存储选项（ use external storage ）”？我正在开发一个运用程序，用户或许一周左右拍一次相片。保存到 Core Data 中或保存到目录哪种更合适？我不想保存到相片库中，由于用户或许不想让别人简单看到这些相片。
A：在 Core Data 中运用外部存储是可以的。你也可以在 Core Data 中存储一个 URL ，然后自己办理的文件。假设你计划将 URL 传递给其他结构，比方媒体播放器，那么你就应该选用后一种办法。
在 Core Data 中敞开 Allows External Storage 后，二进制的读取功率是有保障的。Core Data 会将大于必定尺度（ 100KB ）的文件保存在文件系统中，而且仅在 BLOB 字段中保存该文件的文件名。文件被保存在与 SQLite 数据库同级创立的一个隐藏目录（ _EXTERNAL_DATA ）下。很惋惜， Core Data 并没有供给直接回来这些文件 URL 的 API（ 或将 BLOB 转化成以某种 URL 拜访的办法 ），因而，当需求将数据以 URL 的办法进行传递时，就需求先将数据写到暂时目录后才能进行。因而，是否保存在 Core Data 中，取决于你的详细运用场景。关于需求同步的运用来说，假设选用在 Core Data 中保存 URL 并将数据保存到目录的办法，需求自己完成外置数据的同步。
切换 iCloud 后是否会清空本地数据
Q：在运用 Core Data with CloudKit 的状况下，当用户刊出设备上的 iCloud 账户时，NSPersistentCloudKitContainer 将收到删去本地数据的指示。这是有意为之的吗？
A：是的。 NSPersistentCloudKitContainer 在 iCloud 帐户和存储中的数据之间强制履行严厉绑定。
在 实时切换 Core Data 的云同步状况 一文，我介绍过一种实验办法，在某些状况下可以测验保存这些数据。但最好仍是让运用保持 Core Data 原有的规划办法。考虑到两者间的强绑定战略，一起为了进一步节省用户的备份空间，可以考虑将 Core Data 数据的 SQLite 文件的 isExcludedFromBackup（ 取消文件级的云同步 ） 特点设置为 false ，防止屡次备份。
怎么禁用/启用网络同步
Q：关于想要禁用/启用 CloudKit 存储的用户，是否有引荐的办法让运用程序可以完成此操作。
A：不可以。用户可以从运用程序的设置/系统设置中修正运用的 iCloud 同步选项。你可以创立一个没有 NSPersistentCloudKitContainerOptions 描绘的 NSPersistentCloudKitContainer，如此一来它将不会进行同步。可是由于 NSPersistentCloudKitContainer 强制将 iCloud 中的数据绑定到耐久存储文件。没有办法告知 NSPersistentCloudKitContainer 在帐户消失后保存本地数据（当用户在禁用该 App 的 iCloud 同步时会发生这种状况 ）。
在运用单 Container 的状况下，开发者可以经过 UserDefaults 的办法，操控运用程序在下次冷发动时，是否启用网络同步功用（ 经过设置 cloudKitContainerOptions 与否 ）。如想完成可实时切换的同步状况，可参阅 实时切换 Core Data 的云同步状况 一文。
怎么处理 Container 创立失利
Q：优雅地处理 container.loadPersistentStores 闭包中的过错的办法是什么？ Apple 模板（ Xcode 供给的 Core Data 模版 ）中有一个 fatalError，并提示它不该该在生产中运用，但假设我的 Core Data Stack 没有正的确例化，我的用户无法对我的运用程序做任何事情。
A：一般这些过错是由于未测试的架构搬迁、过错的文件维护等级、磁盘空间缺乏等原因导致。在这些状况下，应进入恢复步骤以使运用程序再次处于可用状况。另一种办法是向用户显示 UI 存在问题而且需求进行重置。咱们的运用程序模板无法为您的运用程序制作杰出的 UI，而这简直便是在此闭包中需求做的事情。
在 SwiftUI 中，咱们一般会运用 environment 为视图树注入视图上下文，一旦 loadPersistentStores 呈现过错导致 container 无法正常创立，那么调用上下文的注入将会失利，导致无法进入 UI 界面。如需求处理这种状况，就需求在主视图（ 或运用 Core Data 功用的根视图 ）对 Container 的状况进行判别（ 一般是在 loadPersistentStores 闭包中修正状况 ），转入失利提示逻辑。
同享数据呈现过错
Q：我的问题是关于 Core Data with CloudKit 的。我现已成功运用 NSPersistentCloudKitContainer 完成了用户跨设备同步数据，但在同享数据方面的命运要差得多。我现已查看了两个相关的示例项目，现在可以进行到创立新同享的地步，可是任何办理现有同享的测验（ 即增加人员等 ）好像总是失利。我在操控台中看到了一些神秘的消息，例如“创立与 PPT 通讯所需的 CFMessagePort 时犯错”。假设我说测验进行数据同享，假设 CKShare 不存在，它可以作业 – 万岁！可是，假设我第二次同享而且 CKShare 现已存在，它只会呈现永久旋转的风火轮。这既呈现于 UICloudSharingController，也呈现于较新的 ShareLink/CKShareTransferRepresentation 版别。在示例代码中也看到了类似的问题。我的问题是 – 此种运用办法是否存在已知问题？有什么特别要记住的吗？
A：请运用 sysdiagnose 提交反应陈述以及受影响设备的存储文件。
不止你一个人。咱们在 CKShare 和 NSPersistentCloudKitContainer 上也遇到了许多麻烦。例如，从符合 Transferable 的结构中同享 URL 实例底子不起作用。 ShareLink 只是显示一个空的弹出窗口（ 另一个开发者的吐槽 ）。
十分惋惜，苹果在为 Core Data with Cloud 增加了数据同享功用后，并没有进一步改善它的表现。现在同享数据的运用体验并不能令人满意。想了解怎么同享数据以及了解当时它的约束请阅览 创立与多个 iCloud 用户同享数据的运用 一文。
保存音视频数据的主张办法
Q：在运用 Core Data with CloudKit 时，关于处理音频文件或图画文件存储，是否有任何引荐的办法。我知道关于较大的数据，最好将其存储在 CoreData 自身之外。
A：这取决于它们的巨细。假设尺度超过 100MB，尽量考虑自己办理文件数据。开发者可以考虑将十分大的文件创立为 CKAsset ，在他们的 NSPersistentCloudKitContainer 同步目标中保存一个外键，以便他们可以查找。这种办法可以削减同步的下载数据量（ 节省设备存储容量 ）并答应按需下载。
这是 Core Data with CloudKit 与纯 CloudKit API 相结合的一种办法。以图画举例，开发者可以考虑只在 Core Data 中保存一个小尺度的缩率图，将大尺度图片经过 CloudKit API 以 CKAsset 的办法保存在云端（ 在对应的 Core Data 数据中保存一个外链 ），用户在点击图片时，才会从云端将数据下载到本地，并保存在一个缓存目录中。
是否有最大同步尺度或数量约束
Q：Core Data with CloudKit 是否最大同步尺度约束？我在一个运用程序中测验它，该运用程序有 30,000 多条记载，但它们无法从 Mac （ 开发状况 ）同步到 iPhone（ 开发状况 ）。
A：假设没有更多细节，很难确认。 NSPersistentCloudKitContainer 和 CloudKit 可以支撑比某些约束（如设备存储）多两个数量级的数据。
理论上，可以同步的数量和尺度只上取决于用户的 iCloud 可用容量。在某些状况下，开发者需求在 macOS 上手动敞开运用的 iCloud 同步选项（ 尤其是在开发阶段 ），不然无法与其他的设备进行同步。
怎么重置本地数据
Q：幻想一下，Core Data 正运用 NSPersistentCloudKitContainer 在一切设备上同步我的运用程序数据。假若其间一台设备呈现某种毛病，需求从云中的数据重置该设备的数据（ 而且有该设备的数据 ）。我的运用程序中是否有任何办法可以重置数据的本地缓存副本以伪装它是新设备并让 CoreData 再次从云中获取一切数据？
A：运用 NSPersistentStoreCoordinator 的 destroyPersistentStore(at:type:options:) 办法，完全销毁本地数据库。
销毁数据库后，还需求从头在本地创立新的数据库。相较于开发者运用文件办理的办法删去 SQLite 数据，这种办法愈加地安全。别的，数据库搬迁也可以经过 NSPersistentStoreCoordinator 的 migratePersistentStore(_:to:options:type:) 办法来实施。
怎么保存枚举类型
Q：在 Core Data 中存储 Swift 枚举（ 有或没有相关值 ）的引荐办法是什么？
A：一种或许的处理计划是将枚举存储为 Transformable 以处理相关值的状况。 在没有枚举值的状况下，经过 rawValue 可以将其转化为 Core Data 支撑的恣意特点类型之一。
运用 Transformable 处理包括相关值的枚举有必定的局限性，1、有必定的功能丢失；2、无法在 Core Data 中经过谓词对其进行查询。假设你对查询有特别的需求的话，可以将枚举类型中相关数据打散，在实体中，将一切的相关值都界说成特点，并增加一个与枚举对应的类型特点，在保管目标中界说一个枚举类型的计算特点，经过它对数据进行转化。虽然这种办法会糟蹋必定的存储空间，但具备转化功率高和可查询的优势。
是否可以显示同步进展并手动触发同步
Q：运用 NSPersistentCloudKitContainer 时，是否可以确认当时同步状况或手动触发同步？我期望可以在 UI 中显示进展视图，以便首次发动运用程序的用户可以看到他们的数据正在从云中下载。
A：NSPersistentCloudKitContainerEvent 填补了这个人物。您可以根据需求将告诉侦听器绑定到事件以更新和显示状况。无法主动触发同步。
NSPersistentCloudKitContainer 供给了一个 eventChangedNotification 告诉，该告诉将在 import、export、setup 三种状况切换时会提醒咱们。严厉意义上，咱们很难仅经过切换告诉来判别当时同步的实践状况。更多内容请参阅 Core Data with CloudKit（四）—— 调试、测试、搬迁及其他 。
是否有必要增加新版别的 Model
Q：咱们什么时候需求增加新的 CoreData model 版别？我看到关于轻量级搬迁的相互对立的主张，为每个版别增加一个新版别是否更安全？
A：在每个版别中增加一个新的保管目标模型会更安全，可是假设您从一个版别到另一个版别的更改经过充沛测试以表明适用于轻量级搬迁揣度，那么单个保管目标模型就足够了。
关于现已上线的运用，最好仍是选用手动增加一个新的版别的办法。除了愈加安全外，也便利盯梢旧版别模型的改变。
SwiftUI 下怎么运用 FetchedResultsController
Q：是否有在 SwiftUI 运用程序中运用 Core Data 的任何实践或主张？假设广泛运用 Core Data，是否仍应该坚持运用 UIKit。例如，FetchedResultsController 是否有对应的 SwiftUI 版别？
A：在 SwiftUI 中运用 CoreData 没有问题。您可以经过 @FetchRequest 从存储中获取检索成果。
@FetchRequest 是个让人又爱又恨的东西。它很好用，简直是在视图中获取数据的首选。但关于 Redux-like 结构的运用者来说，它更像一个破坏者，让大量的数据游离于运用的单一状况之外。让单一状况结构与 @FetchRequest 更好地结合现在仍是一个课题。
运转 initializeCloudKitSchema 办法的机遇
Q：在运用 Core Data with CloudKit 时，假设我在 Core Data Stack 中修正耐久化存储（ 例如，为同享目标增加新的耐久化存储 ），而不触及实体及其特点，我应该运转 initializeCloudKitSchema 吗？
A：只要对保管目标模型进行更改时才需求 initializeCloudKitSchema。 一旦它针对 CKContainer 运转，该容器中的一切数据库都将具有相同的 Schema（ 公共/私有/同享 ）。
initializeCloudKitSchema 一般是在开发阶段运用的一种办法，而且只需求在数据模型创立或改变后运用一次。当 CKContainer 现已创立了对应的 Schema 后，应该在你的代码中删去或注释掉该行代码。别的，initializeCloudKitSchema 还供给了一个 dryRun 选项，用于在单元测试中查看数据模型是否满足 CloudKit 的要求（ 只比对不上传 ）。
多线程的调试手法
Q：调试 Core Data 在多线程办法下的拜访过错/溃散的最佳办法是什么？我一直在运用 -com.apple.CoreData.Logging.stderr 1 和 -com.apple.CoreData.ConcurrencyDebug 1 参数来供给帮助。还有其他主张吗？
A：ASAN 也将有助于捕获并发问题导致的内存过错。
参阅 关于 Core Data 并发编程的几点提示 了解更多细节。
在 App Group 中怎么当即反应改变
Q：当经过运用程序扩展（例如，SiriKit/AppIntents ）向存储提交更改时，保证更改当即反映在或许现已运转的主运用程序中的最佳办法是什么（ 反之亦然 ）？在运用程序和扩展程序中一起运用 NSPersistentContainer 的 viewContext 是否安全/引荐，或许应运用后台上下文的作业？在我的设置中，存储被保存到一个运用程序组目录中，以答应从运用程序和扩展程序拜访，所以我认为每个进程都将运用各自的容器来拜访它。
A：这可以运用 本文 中说到办法，经过设置你的 NSPersistentStoreDescription 长途更改选项来完成。
耐久化前史盯梢正是为类似需求预备的处理计划。参阅 在 CoreData 中运用耐久化前史盯梢 一文，了解更多完成细节。
防止在小组件中履行复杂使命
Q：咱们遇到了一系列溃散，由于咱们在一个 Widget 进程和一个运用程序进程中发动了相同的 CoreData 仓库。一般这可以正常作业，可是一旦存储需求搬迁（ 咱们进行轻量级搬迁 ），就会呈现某种竞争状况，导致运用程序或小组件进程发生溃散。在一次溃散之后，搬迁好像可以正常作业，而且没有发生再次溃散。是否有一个很好的处理计划怎么处理这些溃散？咱们不确认 CoreData 是否正确处理了这件事，或许咱们是否需求检测搬迁并处理这些溃散问题。
A：不该赋予 Widget 履行轻量级/揣度搬迁的才能。只要运用程序应该这样做。假设 Widget 遇到需求搬迁的 CoreData Store，则 Widget 应重定向以发动运用程序。实践上，小部件永久不会从操作系统取得足够的资源来完成搬迁。
小组件的运转资源有限，譬如耐久化前史业务铲除的操作也不该该在小组件中进行处理。
耐久化前史业务的删去机遇
Q：在 Consuming Relevant Store Changes 的“铲除前史记载”中说到：“由于耐久前史盯梢业务会占用磁盘空间，所以确认一个整理战略以在不再需求它们时将其删去”。可是，没有给出清晰的提示关于怎么在不影响 CloudKit 正确性的状况下以安全的办法铲除前史。给出的示例是删去一切超过 7 天的业务。可是，为什么是 7 天？为什么不是 14 天？十分期望一个可靠而详细的示例，阐明怎么安全地铲除前史数据以防止磁盘空间糟蹋。
A：铲除前史记载是由客户决定的。一般，运用每年或每半年铲除一次前史记载。你的特定运用程序的写入速率或许需求不同的时刻窗口，可是当运用 NSPersistentCloudKitContainer 铲除前史记载时，或许会强制将存储文件数据全面同步到 CloudKit，因而不主张常常这样做。
不管进行铲除的时刻间隔为多少，我都不主张开发者铲除 CloudKit 为主动同步创立的前史业务（ 绝大多数状况下，NSPersistentCloudKitContainer 会在保证同步完成后主动进行删去 ）。在进行删去操作时，应在 NSPersistentHistoryChangeRequest 中，忽略掉由系统发生的业务，只删去运用程序或程序组发生的业务。详细内容请参阅 在 CoreData 中运用耐久化前史盯梢 一文。
怎么为 NSDictionary 创立模型
Q：我有一个 NSDictionary 值，需求存储在 Core Data 中。运用 Transformable 特点或 Binary Data 特点来存储它，哪个计划更好？ Binary Data 可以选择外部存储，而且我不相信 Transformable。当从存储获取数据时，这两个选项是否都会被加载到内存中？或许支撑懒加载（ fault ）？不确认哪个更好用。
A：两者会有相同的内存状况。理想状况下的答案是“两者都不是好的选择” 。假设或许的话，你应该为字典建模（ 运用 Core Data 的办法，创立两个实体，经过联系来映射这个字典 ）。
许多状况下，不该将传统的数据组织办法照搬到 Core Data 的 Model 中。尽量用适于 Core Data 架构的办法来规划数据结构。虽然或许会有必定的功能丢失和容量糟蹋，但对总体收益会愈加有利。例如上面的状况，运用联系的办法来处理有如下优势：1、支撑查询；2: 在敞开同步的状况下，每次修正仅需同步修正部分；3: 无需忧虑转化功能。
是否有必要设置逆联系
Q：在数据模型中设置联系的逆联系（ 一般在创立联系时都会设置对应的逆联系 ）有多重要？是否有可以不设置逆联系的相关例子？
A：界说逆向联系使得办理你的图表更简单（ 比方，设置一个“父级”会主动为目标增加为一个“子级” ），而且还答应你委托给 Core Data 进行图表整理（ 比方，你想删去一个 “发票” 一起也删去其一切 “项目” ）。假设您不需求这些语义，则不需求逆向，但大多数状况下，双向遍历都很有用。值得注意的是，假设您想运用 CloudKit 同步，则需求清晰逆向联系。我强烈主张为一切联系设置逆向联系，直到它对功能发生重大影响时再考虑删去它。
Core Data with CloudKit 为了打破 CloudKit API 中关于联系数量（ CKRecord.Reference 不能超过 750 个 ）的约束，选用了双向相关的办法。因而，只要清晰逆联系，Core Data with CloudKit 才能在云端创立正确的 Schema。
NSPersistentStore 的元数据
Q：NSPersistentStore 的元数据是否保存在磁盘上？可以用其了解设备是否履行了某种云搬迁或其他活动吗？
A：Core Data 将元数据存储在存储文件自身中。此元数据归 Core Data 一切，不主张你更改它。假设你愿意，可以将自己的元数据存储在存储文件中，但请注意你的密钥不要与现有的 Core Data 拥有的密钥堆叠。元数据受到与存储文件的其余内容相同的数据维护。
在有一段时刻（ 主要针对文档运用 ），开发者喜欢经过自界说元数据来保存一些选项以便利跨设备运用。阅览 Core Data 是怎么在 SQLite 中保存数据的 一文，了解更多有关 Core Data 元数据的内容。
是否有必要同步中心数据
Q：当我运用 Core Data with CloudKit 时，快速保存数千个 GPS 方位的最佳办法是什么？当数据许多时，它会到达服务器极限。
冗长的评论。提问者开发的是一款锻炼用处的运用，他需求在运用者锻炼期间存储一切的方位（坐标、速度、道路、时刻戳），以便可以制作一条折线。但并不需求在一切的设备上保存这些 GPS 信息（ 仅需求保存对这些数据的汇总信息 ）。苹果的工程师主张他经过创立另一个 Configuration 的办法，将这些数据保存在本地存储中（ 不进行同步 ），只将汇总后的信息保存在同步存储中。阅览 同步本地数据库到 iCloud 私有数据库 一文，了解怎么经过创立多个 Configuration 完成有选择性地同步数据。
怎么加密数据库
Q：假设我运用 NSPersistentStoreFileProtectionKey: FileProtectionType.complete 来加密我的数据库，当用户将手机数据备份到 iCloud 后，它会以加密格局存储吗？仍是仅在设备上加密？
A：NSFileProtection 仅影响设备上数据的加密状况。
从 iOS 15 开始，可以在 Model Editor 中将特点启用加密选项（ 不支撑老版别的 Model 升级）。在运用 Core Data with CloudKit 时，该特点的值将在 iCloud 中以加密的办法进行保存。Core Data 现在并不支撑对 SQLite 进行加密。
NSExpression 的 Bug
Q：我应该怎么看待 NSExpression 中的 CAST 函数？这是我应该积极运用的功用吗？例如，假设我写 CAST(now(), 'NSNumber') 意图在当时时刻做数学运算，我会收到 “Don’t know how to cast to NSNumber” 的过错。
A：这是一个很好的问题。 咱们主张您将其发布在开发者论坛中，Apple 工程师将在此进行整周的监控，并可以为您供给进一步的帮助。这好像值得一个过错陈述
运用 NSExpressionDescription ，可以在 SQLite 中对记载进行必定的计算，并将计算成果经过 NSFetchRequestResult 进行回来。阅览 [在 Core Data 中查询和运用 count 的若干办法](在 Core Data 中查询和运用 count 的若干办法) 一文，查看运用事例。
兼并战略 or 选择性更新
Q：当时咱们的 Core Data Stack 选用了 NSMergeByPropertyStoreTrumpMergePolicy 兼并战略，它本质上是替换一个现已存储在咱们存储中并在从 API 中拉下时由仅有约束标识的目标。另一种办法是经过获取恳求（ fetch request ）确认目标是否现已存在，假设存在，则更新现有记载，假设不存在则创立新记载。在 Apple 看来，哪种办法是处理记载创立和更新的首选办法？
A：每种办法都有长处和缺点。一般来说，首要获取记载（ 经过 Core Data 在存储中查看数据是否存在 ）往往十分昂贵。假设您有必要这样做，则有必要批量获取。在此流程中一次获取一条记载将十分缓慢。
假设 Core Data 内置的兼并战略无法满足你的需求时，创立自界说兼并战略或许是不错的选择。
在多对多联系中创立谓词
Q：我的视频实体与标签具有多对多联系，而且我有一个带有一些标签 ID 的数组。我想获取在这组标签 ID 中至少有一个标签的一切视频。怎么创立一个 NSPredicate 来表明这个？
A：或许可以测验一下 ANY tag.name IN %@。
%@ 对应的是标签数组。应该用 Core Data 的逻辑来组织数据并创立谓词，Core Data 会将谓词转化成对应的 SQL 语句。
动态修正 @FetchRequest 的装备
Q：在 SwiftUI 运用程序中，怎么根据 @AppStorage 值创立 @FetchRequest？用例是：当我打开 Focus 过滤器时，我将 @AppStorage 值更改为用户期望在我的运用程序中看到的标签列表。假设我可以创立一个带有与此 @AppStorage 的值相相关的谓词的 @FetchRequest，则谓词将主动更新，并更新我的视图。现在我无法做到这一点，哪种处理办法能取得类似的成果？
A：@FetchRequest 的谓词特点是一个 Binding，它会在更改时重绘视图。
从 Swift 3.0 开始，FetchRequest 支撑在视图中动态修正它的谓词和排序描绘。例如上面的问题，可以经过在 task(id:) 中更改 request 的装备。
uriRepresentation
Q：我现在正在为我的运用程序完成一个 URL 计划，我想供给一个打开特定 Core Data 目标的 URL。 有没有比在我的 URL 计划中运用 NSManagedObject.objectID.uriRepresentation().absoluteString 作为标识符更好的办法。
A：我想这也是我会做的。
运用 NSPersistentStoreCoordinator 的 managedObjectID(forURIRepresentation: ) 办法，可以将 URL 转化回对应的 NSManageObjectID。阅览 在 Spotlight 中展示运用中的 Core Data 数据 ，了解更多细节。
在同步状况下，怎么进行大版别搬迁
Q：嗨，在运用 Core Data 和 CloudKit 仓库时遇到了一个关于搬迁的问题。假设咱们不再关心本地数据，是否可以从与 CloudKit 同步的数据模型中删去未运用的实体？在咱们的例子中，咱们首要从实体中删去一切数据（ 也便是将该数据搬迁到新实体 ），然后从项目中删去该实体，由于咱们可以确认一切用户都已升级。
A：是的，可是，旧版别的运用程序会做什么？从用户角度，旧版别将写入新版别从未见过的数据，而新版别将写入旧版别从未见过的数据。您将怎么向您的用户解说这种差异？
在运用 Core Data with CloudKit 时，对数据模型最好选用只增不改不减的调整准则。假设的确需求对数据模型有破坏性的修正，最好创立两个 Container（ 别离运用不同的 Model ），在运用者保证原始数据都同步到本地后，再将旧数据转化至新的 Container 之上。
是否可以为同享数据创立单独的 CKRecordZone
Q：我有一个根据文档的运用程序。每个文档都是一个包括仅有 Core Data 存储的包。我想运用 Core Data 的内置 CloudKit 同步 API 别离同步每个文档。怎么为每个文档创立仅有的 CKRecordZone ？
A：当时的 NSPersistentCloudKitContainer 不支撑这样的用法。
或许可以考虑运用朴实的 CloudKit API 来完成他的需求。
是否可以运用 @unchecked Sendable 标示 NSManagedObjectID
Q：在可以保证 NSManagedObjectID 不是暂时状况的状况下，是否可以运用 @unchecked Sendable 对其进行标示。
A：它应该是。 请提交过错陈述。
在 Core Data 中，NSManagedObjectID 是线程安全的。经过向其他的上下文传递 ID，并经过该 ID 在不同线程的上下文中获取保管目标，这样可以保证运用不会呈现溃散。
总结
Ask Apple 中有关 Core Data 的问题应该不是太多，我提的几个问题都取得了解答。期望苹果往后可以常常性地举办类似的活动，大家也应该更踊跃地进行参与。
期望本文可以对你有所帮助。一起也欢迎你经过 Twitter、 Discord 频道 或博客的留言板与我进行沟通。
我正以聊天室、Twitter、博客留言等评论为灵感，从中选取有代表性的问题和技巧制作成 Tips ，发布在 Twitter 上。每周也会对当周博客上的新文章以及在 Twitter 上发布的 Tips 进行汇总，并经过邮件列表的办法发送给订阅者。
订阅下方的 邮件列表，可以及时取得每周的 Tips 汇总。
原文发表在我的博客wwww.fatbobman.com
欢迎订阅我的公共号：【肘子的Swift记事本】
