iCloud & Data

RSS for tag

Learn how to integrate your app with iCloud and data frameworks for effective data storage

CloudKit Documentation

Posts under iCloud & Data subtopic

Post

Replies

Boosts

Views

Activity

CKSyncEngine save existing CKRecord
I have transitioned to CKSyncEngine for syncing data to iCloud, and it is working quite well. I have a question regarding best practices for modifying and saving a CKRecord which already exists in the private or shared database. In my current app, most CKRecords will never be modified after saving to the database, so I do not persist a received record locally after updating my local data model. In the rare event that the local data for that record is modified, I manually fetch the associated server record from the database, modify it, and then use CKSyncEngine to save the modified record. As an alternative method, I can create a new CKRecord locally with the corresponding recordID and the modified data, and then use CKSyncEngine to attempt to save that record to the database. Doing so generates an error in the delegate method handleSentRecordZoneChanges, where I receive the local record I tried to save back inevent.failedRecordSaves with a .serverRecordChanged error, along with the corresponding server CKRecord. I can then update that server record with the local data and re-save using CKSyncEngine. I have not yet seen any issues when doing it this way. The advantage of the latter method is that CKSyncEngine handles the entire database operation, eliminating the manual fetch step. My question is: is this an acceptable practice, or could this result in other unforeseen issues?
2
0
118
Apr ’25
CoreData CloudKit Sync not working between iOs and MacOS
Hi All, I work on a cross platform app, iOS/macOS. All devises on iOS could synchronize data from Coredata : I create a client, I see him an all iOS devices. But when I test on macOs (with TestFlight) the Mac app could not get any information from iOs devices. On Mac, cloud drive is working because I could download and upload documents and share it between all devices, so the account is working but with my App on MacOS, there is no synchronisation. idea????
2
0
1.2k
Sep ’25
Error accessing backing data on deleted item in detached task
I have been working on an app for the past few months, and one issue that I have encountered a few times is an error where quick subsequent deletions cause issues with detached tasks that are triggered from some user actions. Inside a Task.detached, I am building an isolated model context, querying for LineItems, then iterating over those items. The crash happens when accessing a Transaction property through a relationship. var byTransactionId: [UUID: [LineItem]] { return Dictionary(grouping: self) { item in item.transaction?.id ?? UUID() } } In this case, the transaction has been deleted, but the relationship existed when the fetch occurred, so the transaction value is non-nil. The crash occurs when accessing the id. This is the error. SwiftData/BackingData.swift:1035: Fatal error: This model instance was invalidated because its backing data could no longer be found the store. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0xb43fea2c4bc3b3f5 <x-coredata://A9EFB8E3-CB47-48B2-A7C4-6EEA25D27E2E/Transaction/p1756>))) I see other posts about this error and am exploring some suggestions, but if anyone has any thoughts, they would be appreciated.
2
0
384
Nov ’25
joblinkapp's registerview problem
我正在使用 Core Data 开发一个 SwiftUI 项目。我的数据模型中有一个名为 AppleUser 的实体,具有以下属性:id (UUID)、name (String)、email (String)、password (String) 和 createdAt (Date)。所有属性都是非可选的。 我使用 Xcode 的自动生成创建了相应的 Core Data 类文件(AppleUser+CoreDataClass.swift 和 AppleUser+CoreDataProperties.swift)。我还有一个 PersistenceController,它使用模型名称 JobLinkModel 初始化 NSPersistentContainer。 当我尝试使用以下方法保存新的 AppleUser 对象时: 让用户 = AppleUser(上下文:viewContext) user.id = UUID() user.name = “用户 1” user.email = “...” user.password = “密码 1” user.createdAt = Date()【电子邮件格式正确,但已替换为“...”出于隐私原因】 尝试?viewContext.save() 我在控制台中收到以下错误:核心数据保存失败:Foundation._GenericObjCError.nilError, [:] 用户快照: [“id”: ..., “name”: “User1”, “email”: “...”, “password”: “...”, “createdAt”: ...] 所有字段都有有效值,核心数据模型似乎正确。我还尝试过: • 检查 NSPersistentContainer(name:) 中的模型名称是否与 .xcdatamodeld 文件 (JobLinkModel) 匹配 • 确保正确设置 AppleUser 实体类、模块和 Codegen(类定义、当前产品模块) • 删除重复或旧的 AppleUser 类文件 • 清理 Xcode 构建文件夹并从模拟器中删除应用程序 • 对上下文使用 @Environment(.managedObjectContext) 尽管如此,在保存新的 AppleUser 对象时,我仍然会收到 _GenericObjCError.nilError。 我想了解: 为什么即使所有字段都不是零且正确分配,核心数据也无法保存? 这可能是由于一些残留的旧类文件引起的,还是我缺少设置中的其他内容? 我应该采取哪些步骤来确保 Core Data 正确识别 AppleUser 实体并允许保存? 任何帮助或指导将不胜感激。
2
0
154
Sep ’25
How is Record Zone Sharing done?
My use case is the following: Every user of my app can create as an owner a set of items.  These items are private until the owner invites other users to share all of them as participant. The participants can modify the shared items and/or add other items. So, sharing is not done related to individual items, but to all items of an owner. I want to use CoreData & CloudKit to have local copies of private and shared items. To my understanding, CoreData & CloudKit puts all mirrored items in a special zone „com.apple.coredata.cloudkit.zone“. So, this zone should be shared, i.e. all items in it. In the video it is said that NSPersistentCloudKitContainer uses Record Zone Sharing optionally in contrast to hierarchically record sharing using a root record. But how is this done? Maybe I can declare zone „com.apple.coredata.cloudkit.zone“ as a shared zone?
2
0
1.1k
Apr ’25
Best Practices for Using CKAssets in Public CloudKit Database for Social Features
Hello Apple Team, We are looking at developing an iOS feature on our current development that stores user-generated images as CKAssets in the public CloudKit database, with access control enforced by our app’s own logic (not CloudKit Sharing as that has a limit of 100 shares per device). Each story or post is a public record, and users only see content based on buddy relationships handled within the app. We’d like to confirm that this pattern is consistent with Apple’s best practices for social features. Specifically: Is it acceptable to store user-uploaded CKAssets in the public CloudKit database, as long as access visibility is enforced by the app? Are there any performance or quota limitations (e.g., storage, bandwidth, or user sync limits) that apply to CKAssets in the public database when used at scale? Would CloudKit Sharing be recommended instead, even if we don’t require user-to-user sharing invitations? For App Review, is this model (public CKAssets + app-enforced access control) compliant with Apple’s data and security expectations? Are there any caching or bandwidth optimization guidelines for handling image-heavy public CKAsset data in CloudKit? Thanks again for your time
2
0
215
Oct ’25
Key-value storage will not sync data past a certain size
I have an app which uses key-value storage and will not sync data past a certain size -- meaning that device "A" will send the data to the cloud but device "B" will never receive the updated data. Device "B" will receive the NSUbiquitousKeyValueStoreDidChangeExternallyNotification that the KVS changed but the data is empty. The data in in the KVS is comprised of 4 keys, each containing a value of NSData generated by NSKeyedArchiver. The NSData is comprised of property-list data types (e.g. numbers, strings, dates, etc.) I've verified that the KVS meets the limits of: A total of 1 MB per app, with a per-key limit of 1 MB A per-key value size limit of 1 MB, and a maximum of 1024 keys A maximum length for key strings is 64 bytes using UTF8 encoding Also, the app has never received an NSUbiquitousKeyValueStoreQuotaViolationChange notification. Of the 4 keys, 3 of them contain no more than 30 KB of data each. However, one of the keys can contain as much as 160 KB of data which will not sync to another device. Strangely, if I constrain the data to 100 KB it will work, however, that is not ideal as it is a fraction of the necessary data. I don't see any errors in the debug log either. Any suggestions on what to try next to get this working?
2
0
190
May ’25
Best Practices for Binary Data (“Allows External Storage”) in Core Data with CloudKit Sync
Hello Apple Team, We’re building a CloudKit-enabled Core Data app and would like clarification on the behavior and performance characteristics of Binary Data attributes with “Allows External Storage” enabled when used with NSPersistentCloudKitContainer. Initially, we tried storing image files manually on disk and only saving the metadata (file URLs, dimensions, etc.) in Core Data. While this approach reduced the size of the Core Data store, it introduced instability after app updates and broke sync between devices. We would prefer to use the official Apple-recommended method and have Core Data manage image storage and CloudKit syncing natively. Specifically, we’d appreciate guidance on the following: When a Binary Data attribute is marked as “Allows External Storage”, large image files are stored as separate files on device rather than inline in the SQLite store. How effective is this mechanism in keeping the Core Data store size small on device? Are there any recommended size thresholds or known limits for how many externally stored blobs can safely be managed this way? How are these externally stored files handled during CloudKit sync? Does each externally stored Binary Data attribute get mirrored to CloudKit as a CKAsset? Does external storage reduce the sync payload size or network usage, or is the full binary data still uploaded/downloaded as part of the CKAsset? Are there any bandwidth implications for users syncing via their private CloudKit database, versus developer costs in the public CloudKit database? Is there any difference in CloudKit or Core Data behavior when a Binary Data attribute is managed this way versus manually storing image URLs and handling the file separately on disk? Our goal is to store user-generated images efficiently and safely sync them via CloudKit, without incurring excessive local database bloat or CloudKit network overhead. Any detailed guidance or internal performance considerations would be greatly appreciated. Thank you, Paul Barry Founder & Lead Developer — Boat Buddy / Vessel Buddy iOS App Archipelago Environmental Solutions Inc.
2
0
318
Oct ’25
Core Data: Main actor-isolated property can not be mutated from a Sendable closure
I'm running a project with these settings: Default Actor Isolation: MainActor Approachable Concurrency: Yes Strict Concurrency Checking: Complete (this issue does not appear on the other two modes) I receive a warning for this very simple use case. Can I actually fix anything about this or is this a case of Core Data not being entirely ready for this? In reference to this, there was a workaround listed in the release notes of iOS 26 beta 5 (https://forums.swift.org/t/defaultisolation-mainactor-and-core-data-background-tasks/80569/22). Does this still apply as the only fix for this? This is a simplified sample meant to run on a background context. The issue obviously goes away if this function would just run on the MainActor, then I can remove the perform block entirely. class DataHandler { func createItem() async { let context = ... await context.perform { let newGame = Item(context: context) /// Main actor-isolated property 'timestamp' can not be mutated from a Sendable closure newGame.timestamp = Date.now // ... } } } The complete use case would be more like this: nonisolated struct DataHandler { @concurrent func saveItem() async throws { let context = await PersistenceController.shared.container.newBackgroundContext() try await context.perform { let newGame = Item(context: context) newGame.timestamp = Date.now try context.save() } } }
2
1
542
Oct ’25
SwiftData document-based app crashes on undo/redo with autosaveEnabled
Overview I'm developing a document-based app for macOS using SwiftData. When I undo/redo changes using Command-Z/ Command-Shift-Z, the app randomly crashes with the following error: SwiftData/BackingData.swift:425: Fatal error: Failed to retrieve the identifier for \ChildItem.parentItem from KnownKeysDictionary:KnownKeysMap: ["parentItem": 2, "isModified": 1, "index": 0] values: [Optional(0), Optional(false), Optional(DocumentTest.ParentItem)] SwiftData._KKMDBackingData<DocumentTest.ChildItem> And sometimes, instead of the app crashing, my created @Model objects simply disappear. They do not reappear in the @Query on undo/redo. Both of these issues go away when I set modelContext.autosaveEnabled = false The issues are occurring with Xcode 26.4 (17E192) and macOS Tahoe 26.4 (25E246). I have modified the macOS Document App project template to showcase the issue. The project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/1aDO34QleTm_rB9BuvVGjzzAP6jDXOc-o?usp=share_link Has anyone else experienced this? I'd like to know if this is a bug in the autosave feature of SwiftData and if I should file a bug report via Feedback Assistant. Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file linked above. Open the extracted "DocumentTest" project in Xcode. Build and run the "DocumentTest" app. In the document selection window, click "New Document" at the bottom-left. In the app, click the "+" button at the top-right to add a ParentItem with ChildItems. Click on the added ParentItem's button to modify one of its ChildItems. Repeat steps 5–6 until you have 5 ParentItems with a modified ChildItem. Press Command-Z 10 times to undo all the changes. Press Command-Shift-Z 10 times to redo all the changes. Repeat steps 8–9 until either the app crashes or some of the 5 ParentItems go missing in the list (you may have to repeat them 10–20 times before the issue occurs). If you change line 43 of ContentView.swift to modelContext.autosaveEnabled = false and repeat the same steps above, the app will not crash and no ParentItems will go missing. Code ParentItem Model @Model final class ParentItem { var timestamp: Date @Relationship( deleteRule: .cascade, inverse: \ChildItem.parentItem ) var childItems: [ChildItem] = [] init(timestamp: Date) { self.timestamp = timestamp } } ChildItem Model @Model final class ChildItem { var index: Int var isModified = false var parentItem: ParentItem? init(index: Int) { self.index = index } } Creating, Inserting, and Linking ParentItem and ChildItem // Create and insert ParentItem let newParentItem = ParentItem( timestamp: Date() ) modelContext.insert(newParentItem) // Create and insert ChildItems var newChildItems: [ChildItem] = [] for index in 0..<Int.random(in: 2...8) { let newChildItem = ChildItem(index: index) newChildItems.append(newChildItem) modelContext.insert(newChildItem) } /* Establish relationship between ParentItem and ChildItems */ newParentItem.childItems = newChildItems Modifying ChildItem let firstChildItem = parentItem.childItems .sorted(by: { $0.index < $1.index }).first if let firstChildItem, !firstChildItem.isModified { firstChildItem.isModified = true }
2
0
88
1h
Using relationships in SortDescriptor crashing on release
If use a SortDescriptor for a model and sort by some attribute from a relationship, in DEBUG mode it all works fine and sorts. However, in release mode, it is an instant crash. SortDescriptor(.name, order: .reverse) ---- works SortDescriptor(.assignedUser?.name, order: .reverse) ---- works in debug but crash in release. What is the issue here, is it that SwiftData just incompetent to do this?
2
0
125
Aug ’25
No persistent stores error in SwiftData
I am following Apple's instruction to sync SwiftData with CloudKit. While initiating the ModelContainer, right after removing the store from Core Data, the error occurs: FAULT: NSInternalInconsistencyException: This NSPersistentStoreCoordinator has no persistent stores (unknown). It cannot perform a save operation.; (user info absent) I've tried removing default.store and its related files/folders before creating the ModelContainer with FileManager but it does not resolve the issue. Isn't it supposed to create a new store when the ModelContainer is initialized? I don't understand why this error occurs. Error disappears when I comment out the #if DEBUG block. Code: import CoreData import SwiftData import SwiftUI struct InitView: View { @Binding var modelContainer: ModelContainer? @Binding var isReady: Bool @State private var loadingDots = "" @State private var timer: Timer? var body: some View { VStack(spacing: 16) { Text("Loading\(loadingDots)") .font(.title2) .foregroundColor(.gray) } .padding() .onAppear { startAnimation() registerTransformers() let config = ModelConfiguration() let newContainer: ModelContainer do { #if DEBUG // Use an autorelease pool to make sure Swift deallocates the persistent // container before setting up the SwiftData stack. try autoreleasepool { let desc = NSPersistentStoreDescription(url: config.url) let opts = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.my-container-identifier") desc.cloudKitContainerOptions = opts // Load the store synchronously so it completes before initializing the // CloudKit schema. desc.shouldAddStoreAsynchronously = false if let mom = NSManagedObjectModel.makeManagedObjectModel(for: [Page.self]) { let container = NSPersistentCloudKitContainer(name: "Pages", managedObjectModel: mom) container.persistentStoreDescriptions = [desc] container.loadPersistentStores { _, err in if let err { fatalError(err.localizedDescription) } } // Initialize the CloudKit schema after the store finishes loading. try container.initializeCloudKitSchema() // Remove and unload the store from the persistent container. if let store = container.persistentStoreCoordinator.persistentStores.first { try container.persistentStoreCoordinator.remove(store) } } // let fileManager = FileManager.default // let sqliteURL = config.url // let urls: [URL] = [ // sqliteURL, // sqliteURL.deletingLastPathComponent().appendingPathComponent("default.store-shm"), // sqliteURL.deletingLastPathComponent().appendingPathComponent("default.store-wal"), // sqliteURL.deletingLastPathComponent().appendingPathComponent(".default_SUPPORT"), // sqliteURL.deletingLastPathComponent().appendingPathComponent("default_ckAssets") // ] // for url in urls { // try? fileManager.removeItem(at: url) // } } #endif newContainer = try ModelContainer(for: Page.self, configurations: config) // ERROR!!! } catch { fatalError(error.localizedDescription) } modelContainer = newContainer isReady = true } .onDisappear { stopAnimation() } } private func startAnimation() { timer = Timer.scheduledTimer( withTimeInterval: 0.5, repeats: true ) { _ in updateLoadingDots() } } private func stopAnimation() { timer?.invalidate() timer = nil } private func updateLoadingDots() { if loadingDots.count > 2 { loadingDots = "" } else { loadingDots += "." } } } import CoreData import SwiftData import SwiftUI @main struct MyApp: App { @State private var modelContainer: ModelContainer? @State private var isReady: Bool = false var body: some Scene { WindowGroup { if isReady, let modelContainer = modelContainer { ContentView() .modelContainer(modelContainer) } else { InitView(modelContainer: $modelContainer, isReady: $isReady) } } } }
2
0
197
May ’25
Swift Data Recovery
Hi Writing an app in Swift on Xcode for my iPhone, all software is the latest version. If after making a minor change and re-building all the application data has disappeared, is there a way to see if it is still in the .modelContainer and just not showing up?
2
0
651
3w
Fatal error on rollback after delete
I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<ChildModel> I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test environment, so the model that's being deleted (or any other) is not being accessed by any other part of the application. However, problem looks the same in the real app. I also changed the target version of iOS from 18.0 to 26.0, but to no avail. My models look kind of like this: @Model final class ParentModel { var name: String @Relationship(deleteRule: .cascade, inverse: \ChildModel.parent) var children: [ChildModel]? init(name: String) { self.name = name } } @Model final class ChildModel { var name: String @Relationship(deleteRule: .nullify) var parent: ParentModel? init(name: String) { self.name = name } } I tried many approaches that didn't help: Fetching all children (via fetch) just to "populate" the context Accessing all children on parent model (via let _ = parentModel.children?.count) Deleting all children reading models from parent: for child in parentModel.children ?? [] { modelContext.delete(child) } Deleting all children like this: let parentPersistentModelID = parentModel.persistentModelID modelContext.delete(model: ChildModel.self, where: #Predicate { $0.parent.persistentModelID == parentPersistentModelID }, includeSubclasses: true) Removing @Relationship(deleteRule: .nullify) from ChildModel relationship definition I found 2 solution for the problem: To manually fetch and delete all children prior to deleting parent: let parentPersistentModelID = parentModel.persistentModelID for child in try modelContext.fetch(FetchDescriptor<ChildModel>(predicate: #Predicate { $0.parent.persistentModelID == parentPersistentModelID })) { modelContext.delete(child) } modelContext.delete(parentModel) Trying to run my code in child context (let childContext = ModelContext(modelContext.container)) All that sounds to me like a problem deep inside Swift Data itself. The first solution I found, fetching potentially hundreds of child models just to delete them in case I might need to rollback changes on some error, sounds like awful waste of resources to me. The second one however seems to work fine has that drawback that I can't fully test my code. Right now I can wrap the context (literally creating class that holds ModelContext and calls its methods) and in tests for throwing methods force them to throw. By creating scratch ModelContext I loose that possibility. What might be the real issue here? Am I missing something?
2
0
114
1w
Cannot create new CloudKit container after deleting all containers - need help
I accidentally deleted all CloudKit containers from the CloudKit Database console, and now I'm unable to create new containers. Both the CloudKit Console website and Xcode are not allowing me to create any new containers. Is there a way to restore the deleted containers? How can I create a new CloudKit container if the console website is not responding? Thank you.
2
0
120
3w
TestFlight build crashes from fetch descriptor
I have a FetchDescriptor that uses starts(with:) which works fine in debug builds but crashes in TestFlight and archive. For background information I'm using iCloud and model inheritance where the property being used in fetch descriptor is defined on the superclass, the fetch descriptor is for the subclass. Implementation: static func fetchDescriptor(nameStartingWith prefix: String) -> FetchDescriptor<ColorAsset> { let predicate = #Predicate<ColorAsset> { asset in asset.name.starts(with: prefix) } return FetchDescriptor<ColorAsset>(predicate: predicate) } @Model public class Asset: Identifiable { // MARK: - Properties var name: String = "" .... } @available(macOS 26.0, *) @Model public class ColorAsset: Asset { ... }
2
0
72
4d
Help Rescuing SwiftData Schema with Non-Optional Transformables
I currently have a schema in production (cloudKit and local files) containing non-optional transformable values, e.g. @Attribute(.transformable(by: TestTransformer.self)) var number: TestTransformable = TestTransformable.init(value: 100) Unfortunately, this is preventing any migration from succeeding (documented at length in FB22151570). Briefly summarized, any migration from a Schema containing non-optional transformable values fails between willMigrate and didMigrate with the error "Can't find model for source store". This occurs for all migrations, including lightweight with a migration plan, lightweight without a plan, and custom migrations. Worst of all, this also prevents migration to optional transformable values, or the elimination of the transformable value entirely, leaving us completely stuck. (note: optional transformable values only work when they have a default value set to nil, otherwise even these have issues migrating) We already have features being blocked by this issue, and would like to preserve user-data while restoring our ability to move forwards with database. Are there any known workarounds for using SwiftData (+CloudKit) when schema migration is non-operational?
2
0
154
4w
iCloud Account Signing Out
I have several macOS applications that use CloudKit. I need to test and finds out what happens when the user signs out of their iCloud account. That's because the application may lose data after signing out and then signing in again. Every time I do that, it'll take 15, 20 minutes... I don't time it, but it takes quite a gigantic time to sign out as the spinner keeps rolling. Why does it take so long to just sign out? This sign out effect is untestable because it takes a long time to sign out of an iCloud account and then make changes to the code and then test again. In case you need to know, my system version is Sequoia 15.7.
2
0
149
Feb ’26
Old CloudKit Data Repopulating after a Local Reset
We are trying to solve for the following condition with SwiftData + CloudKit: Lots of data in CloudKit Perform "app-reset" to clear data & App settings and start fresh. Reset data models with try modelContext.delete(model:_) myModel.count() confirms local deletion (0 records); but iCloud Console shows expectedly slow process to delete. Old CloudKit data is returning during the On Boarding process. Questions: • Would making a new iCloud Zone for each reset work around this, as the new zone would be empty? We're having trouble finding details about how to do this with SwiftData. • Would CKSyncEngine have a benefit over the default SwiftData methods? Open to hearing if anyone has experienced a similar challenge and how you worked around it!
2
0
233
Jun ’25
SwiftData + CloudKit: BGSystemTaskScheduler Code=8
Hi everyone, On macOS 26.4 beta (with Xcode 26.4 beta), I’m seeing the following console messages in a brand new SwiftData + CloudKit template project (no custom logic added, fresh CloudKit container): updateTaskRequest called for a pre-running task com.apple.coredata.cloudkit.activity.export.F9EE783D-7521-4EC2-B42C-9FD1F29BA5C4 updateTaskRequest called for an already running/updated task com.apple.coredata.cloudkit.activity.export.F9EE783D-7521-4EC2-B42C-9FD1F29BA5C4 Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=8 "(null)" These messages appear: When CloudKit is enabled Occasionally on app launch Often when bringing the app back to the foreground (Cmd-Tab away and back) Even with zero additional SwiftData logic They do not appear when CloudKit is disabled. This behavior is reproducible on a completely new project with a fresh CloudKit container. Questions: What exactly do these messages indicate? Is BGSystemTaskScheduler Code=8 expected in this context? Are these safe to ignore? Is this a known change in logging behavior in macOS 26.4 beta? Additionally, in a larger project I’ve observed SwiftData crashes and initially suspected these logs might be related. However, since the issue reproduces in a fresh template project, I’m unsure whether this is simply verbose beta logging or something more serious. Any clarification would be appreciated. Filed as FB21993521.
2
0
201
Feb ’26
CKSyncEngine save existing CKRecord
I have transitioned to CKSyncEngine for syncing data to iCloud, and it is working quite well. I have a question regarding best practices for modifying and saving a CKRecord which already exists in the private or shared database. In my current app, most CKRecords will never be modified after saving to the database, so I do not persist a received record locally after updating my local data model. In the rare event that the local data for that record is modified, I manually fetch the associated server record from the database, modify it, and then use CKSyncEngine to save the modified record. As an alternative method, I can create a new CKRecord locally with the corresponding recordID and the modified data, and then use CKSyncEngine to attempt to save that record to the database. Doing so generates an error in the delegate method handleSentRecordZoneChanges, where I receive the local record I tried to save back inevent.failedRecordSaves with a .serverRecordChanged error, along with the corresponding server CKRecord. I can then update that server record with the local data and re-save using CKSyncEngine. I have not yet seen any issues when doing it this way. The advantage of the latter method is that CKSyncEngine handles the entire database operation, eliminating the manual fetch step. My question is: is this an acceptable practice, or could this result in other unforeseen issues?
Replies
2
Boosts
0
Views
118
Activity
Apr ’25
CoreData CloudKit Sync not working between iOs and MacOS
Hi All, I work on a cross platform app, iOS/macOS. All devises on iOS could synchronize data from Coredata : I create a client, I see him an all iOS devices. But when I test on macOs (with TestFlight) the Mac app could not get any information from iOs devices. On Mac, cloud drive is working because I could download and upload documents and share it between all devices, so the account is working but with my App on MacOS, there is no synchronisation. idea????
Replies
2
Boosts
0
Views
1.2k
Activity
Sep ’25
Error accessing backing data on deleted item in detached task
I have been working on an app for the past few months, and one issue that I have encountered a few times is an error where quick subsequent deletions cause issues with detached tasks that are triggered from some user actions. Inside a Task.detached, I am building an isolated model context, querying for LineItems, then iterating over those items. The crash happens when accessing a Transaction property through a relationship. var byTransactionId: [UUID: [LineItem]] { return Dictionary(grouping: self) { item in item.transaction?.id ?? UUID() } } In this case, the transaction has been deleted, but the relationship existed when the fetch occurred, so the transaction value is non-nil. The crash occurs when accessing the id. This is the error. SwiftData/BackingData.swift:1035: Fatal error: This model instance was invalidated because its backing data could no longer be found the store. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0xb43fea2c4bc3b3f5 &lt;x-coredata://A9EFB8E3-CB47-48B2-A7C4-6EEA25D27E2E/Transaction/p1756&gt;))) I see other posts about this error and am exploring some suggestions, but if anyone has any thoughts, they would be appreciated.
Replies
2
Boosts
0
Views
384
Activity
Nov ’25
joblinkapp's registerview problem
我正在使用 Core Data 开发一个 SwiftUI 项目。我的数据模型中有一个名为 AppleUser 的实体,具有以下属性:id (UUID)、name (String)、email (String)、password (String) 和 createdAt (Date)。所有属性都是非可选的。 我使用 Xcode 的自动生成创建了相应的 Core Data 类文件(AppleUser+CoreDataClass.swift 和 AppleUser+CoreDataProperties.swift)。我还有一个 PersistenceController,它使用模型名称 JobLinkModel 初始化 NSPersistentContainer。 当我尝试使用以下方法保存新的 AppleUser 对象时: 让用户 = AppleUser(上下文:viewContext) user.id = UUID() user.name = “用户 1” user.email = “...” user.password = “密码 1” user.createdAt = Date()【电子邮件格式正确,但已替换为“...”出于隐私原因】 尝试?viewContext.save() 我在控制台中收到以下错误:核心数据保存失败:Foundation._GenericObjCError.nilError, [:] 用户快照: [“id”: ..., “name”: “User1”, “email”: “...”, “password”: “...”, “createdAt”: ...] 所有字段都有有效值,核心数据模型似乎正确。我还尝试过: • 检查 NSPersistentContainer(name:) 中的模型名称是否与 .xcdatamodeld 文件 (JobLinkModel) 匹配 • 确保正确设置 AppleUser 实体类、模块和 Codegen(类定义、当前产品模块) • 删除重复或旧的 AppleUser 类文件 • 清理 Xcode 构建文件夹并从模拟器中删除应用程序 • 对上下文使用 @Environment(.managedObjectContext) 尽管如此,在保存新的 AppleUser 对象时,我仍然会收到 _GenericObjCError.nilError。 我想了解: 为什么即使所有字段都不是零且正确分配,核心数据也无法保存? 这可能是由于一些残留的旧类文件引起的,还是我缺少设置中的其他内容? 我应该采取哪些步骤来确保 Core Data 正确识别 AppleUser 实体并允许保存? 任何帮助或指导将不胜感激。
Replies
2
Boosts
0
Views
154
Activity
Sep ’25
How is Record Zone Sharing done?
My use case is the following: Every user of my app can create as an owner a set of items.  These items are private until the owner invites other users to share all of them as participant. The participants can modify the shared items and/or add other items. So, sharing is not done related to individual items, but to all items of an owner. I want to use CoreData & CloudKit to have local copies of private and shared items. To my understanding, CoreData & CloudKit puts all mirrored items in a special zone „com.apple.coredata.cloudkit.zone“. So, this zone should be shared, i.e. all items in it. In the video it is said that NSPersistentCloudKitContainer uses Record Zone Sharing optionally in contrast to hierarchically record sharing using a root record. But how is this done? Maybe I can declare zone „com.apple.coredata.cloudkit.zone“ as a shared zone?
Replies
2
Boosts
0
Views
1.1k
Activity
Apr ’25
Best Practices for Using CKAssets in Public CloudKit Database for Social Features
Hello Apple Team, We are looking at developing an iOS feature on our current development that stores user-generated images as CKAssets in the public CloudKit database, with access control enforced by our app’s own logic (not CloudKit Sharing as that has a limit of 100 shares per device). Each story or post is a public record, and users only see content based on buddy relationships handled within the app. We’d like to confirm that this pattern is consistent with Apple’s best practices for social features. Specifically: Is it acceptable to store user-uploaded CKAssets in the public CloudKit database, as long as access visibility is enforced by the app? Are there any performance or quota limitations (e.g., storage, bandwidth, or user sync limits) that apply to CKAssets in the public database when used at scale? Would CloudKit Sharing be recommended instead, even if we don’t require user-to-user sharing invitations? For App Review, is this model (public CKAssets + app-enforced access control) compliant with Apple’s data and security expectations? Are there any caching or bandwidth optimization guidelines for handling image-heavy public CKAsset data in CloudKit? Thanks again for your time
Replies
2
Boosts
0
Views
215
Activity
Oct ’25
Key-value storage will not sync data past a certain size
I have an app which uses key-value storage and will not sync data past a certain size -- meaning that device "A" will send the data to the cloud but device "B" will never receive the updated data. Device "B" will receive the NSUbiquitousKeyValueStoreDidChangeExternallyNotification that the KVS changed but the data is empty. The data in in the KVS is comprised of 4 keys, each containing a value of NSData generated by NSKeyedArchiver. The NSData is comprised of property-list data types (e.g. numbers, strings, dates, etc.) I've verified that the KVS meets the limits of: A total of 1 MB per app, with a per-key limit of 1 MB A per-key value size limit of 1 MB, and a maximum of 1024 keys A maximum length for key strings is 64 bytes using UTF8 encoding Also, the app has never received an NSUbiquitousKeyValueStoreQuotaViolationChange notification. Of the 4 keys, 3 of them contain no more than 30 KB of data each. However, one of the keys can contain as much as 160 KB of data which will not sync to another device. Strangely, if I constrain the data to 100 KB it will work, however, that is not ideal as it is a fraction of the necessary data. I don't see any errors in the debug log either. Any suggestions on what to try next to get this working?
Replies
2
Boosts
0
Views
190
Activity
May ’25
Best Practices for Binary Data (“Allows External Storage”) in Core Data with CloudKit Sync
Hello Apple Team, We’re building a CloudKit-enabled Core Data app and would like clarification on the behavior and performance characteristics of Binary Data attributes with “Allows External Storage” enabled when used with NSPersistentCloudKitContainer. Initially, we tried storing image files manually on disk and only saving the metadata (file URLs, dimensions, etc.) in Core Data. While this approach reduced the size of the Core Data store, it introduced instability after app updates and broke sync between devices. We would prefer to use the official Apple-recommended method and have Core Data manage image storage and CloudKit syncing natively. Specifically, we’d appreciate guidance on the following: When a Binary Data attribute is marked as “Allows External Storage”, large image files are stored as separate files on device rather than inline in the SQLite store. How effective is this mechanism in keeping the Core Data store size small on device? Are there any recommended size thresholds or known limits for how many externally stored blobs can safely be managed this way? How are these externally stored files handled during CloudKit sync? Does each externally stored Binary Data attribute get mirrored to CloudKit as a CKAsset? Does external storage reduce the sync payload size or network usage, or is the full binary data still uploaded/downloaded as part of the CKAsset? Are there any bandwidth implications for users syncing via their private CloudKit database, versus developer costs in the public CloudKit database? Is there any difference in CloudKit or Core Data behavior when a Binary Data attribute is managed this way versus manually storing image URLs and handling the file separately on disk? Our goal is to store user-generated images efficiently and safely sync them via CloudKit, without incurring excessive local database bloat or CloudKit network overhead. Any detailed guidance or internal performance considerations would be greatly appreciated. Thank you, Paul Barry Founder & Lead Developer — Boat Buddy / Vessel Buddy iOS App Archipelago Environmental Solutions Inc.
Replies
2
Boosts
0
Views
318
Activity
Oct ’25
Core Data: Main actor-isolated property can not be mutated from a Sendable closure
I'm running a project with these settings: Default Actor Isolation: MainActor Approachable Concurrency: Yes Strict Concurrency Checking: Complete (this issue does not appear on the other two modes) I receive a warning for this very simple use case. Can I actually fix anything about this or is this a case of Core Data not being entirely ready for this? In reference to this, there was a workaround listed in the release notes of iOS 26 beta 5 (https://forums.swift.org/t/defaultisolation-mainactor-and-core-data-background-tasks/80569/22). Does this still apply as the only fix for this? This is a simplified sample meant to run on a background context. The issue obviously goes away if this function would just run on the MainActor, then I can remove the perform block entirely. class DataHandler { func createItem() async { let context = ... await context.perform { let newGame = Item(context: context) /// Main actor-isolated property 'timestamp' can not be mutated from a Sendable closure newGame.timestamp = Date.now // ... } } } The complete use case would be more like this: nonisolated struct DataHandler { @concurrent func saveItem() async throws { let context = await PersistenceController.shared.container.newBackgroundContext() try await context.perform { let newGame = Item(context: context) newGame.timestamp = Date.now try context.save() } } }
Replies
2
Boosts
1
Views
542
Activity
Oct ’25
SwiftData document-based app crashes on undo/redo with autosaveEnabled
Overview I'm developing a document-based app for macOS using SwiftData. When I undo/redo changes using Command-Z/ Command-Shift-Z, the app randomly crashes with the following error: SwiftData/BackingData.swift:425: Fatal error: Failed to retrieve the identifier for \ChildItem.parentItem from KnownKeysDictionary:KnownKeysMap: ["parentItem": 2, "isModified": 1, "index": 0] values: [Optional(0), Optional(false), Optional(DocumentTest.ParentItem)] SwiftData._KKMDBackingData<DocumentTest.ChildItem> And sometimes, instead of the app crashing, my created @Model objects simply disappear. They do not reappear in the @Query on undo/redo. Both of these issues go away when I set modelContext.autosaveEnabled = false The issues are occurring with Xcode 26.4 (17E192) and macOS Tahoe 26.4 (25E246). I have modified the macOS Document App project template to showcase the issue. The project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/1aDO34QleTm_rB9BuvVGjzzAP6jDXOc-o?usp=share_link Has anyone else experienced this? I'd like to know if this is a bug in the autosave feature of SwiftData and if I should file a bug report via Feedback Assistant. Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file linked above. Open the extracted "DocumentTest" project in Xcode. Build and run the "DocumentTest" app. In the document selection window, click "New Document" at the bottom-left. In the app, click the "+" button at the top-right to add a ParentItem with ChildItems. Click on the added ParentItem's button to modify one of its ChildItems. Repeat steps 5–6 until you have 5 ParentItems with a modified ChildItem. Press Command-Z 10 times to undo all the changes. Press Command-Shift-Z 10 times to redo all the changes. Repeat steps 8–9 until either the app crashes or some of the 5 ParentItems go missing in the list (you may have to repeat them 10–20 times before the issue occurs). If you change line 43 of ContentView.swift to modelContext.autosaveEnabled = false and repeat the same steps above, the app will not crash and no ParentItems will go missing. Code ParentItem Model @Model final class ParentItem { var timestamp: Date @Relationship( deleteRule: .cascade, inverse: \ChildItem.parentItem ) var childItems: [ChildItem] = [] init(timestamp: Date) { self.timestamp = timestamp } } ChildItem Model @Model final class ChildItem { var index: Int var isModified = false var parentItem: ParentItem? init(index: Int) { self.index = index } } Creating, Inserting, and Linking ParentItem and ChildItem // Create and insert ParentItem let newParentItem = ParentItem( timestamp: Date() ) modelContext.insert(newParentItem) // Create and insert ChildItems var newChildItems: [ChildItem] = [] for index in 0..<Int.random(in: 2...8) { let newChildItem = ChildItem(index: index) newChildItems.append(newChildItem) modelContext.insert(newChildItem) } /* Establish relationship between ParentItem and ChildItems */ newParentItem.childItems = newChildItems Modifying ChildItem let firstChildItem = parentItem.childItems .sorted(by: { $0.index < $1.index }).first if let firstChildItem, !firstChildItem.isModified { firstChildItem.isModified = true }
Replies
2
Boosts
0
Views
88
Activity
1h
Using relationships in SortDescriptor crashing on release
If use a SortDescriptor for a model and sort by some attribute from a relationship, in DEBUG mode it all works fine and sorts. However, in release mode, it is an instant crash. SortDescriptor(.name, order: .reverse) ---- works SortDescriptor(.assignedUser?.name, order: .reverse) ---- works in debug but crash in release. What is the issue here, is it that SwiftData just incompetent to do this?
Replies
2
Boosts
0
Views
125
Activity
Aug ’25
No persistent stores error in SwiftData
I am following Apple's instruction to sync SwiftData with CloudKit. While initiating the ModelContainer, right after removing the store from Core Data, the error occurs: FAULT: NSInternalInconsistencyException: This NSPersistentStoreCoordinator has no persistent stores (unknown). It cannot perform a save operation.; (user info absent) I've tried removing default.store and its related files/folders before creating the ModelContainer with FileManager but it does not resolve the issue. Isn't it supposed to create a new store when the ModelContainer is initialized? I don't understand why this error occurs. Error disappears when I comment out the #if DEBUG block. Code: import CoreData import SwiftData import SwiftUI struct InitView: View { @Binding var modelContainer: ModelContainer? @Binding var isReady: Bool @State private var loadingDots = "" @State private var timer: Timer? var body: some View { VStack(spacing: 16) { Text("Loading\(loadingDots)") .font(.title2) .foregroundColor(.gray) } .padding() .onAppear { startAnimation() registerTransformers() let config = ModelConfiguration() let newContainer: ModelContainer do { #if DEBUG // Use an autorelease pool to make sure Swift deallocates the persistent // container before setting up the SwiftData stack. try autoreleasepool { let desc = NSPersistentStoreDescription(url: config.url) let opts = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.my-container-identifier") desc.cloudKitContainerOptions = opts // Load the store synchronously so it completes before initializing the // CloudKit schema. desc.shouldAddStoreAsynchronously = false if let mom = NSManagedObjectModel.makeManagedObjectModel(for: [Page.self]) { let container = NSPersistentCloudKitContainer(name: "Pages", managedObjectModel: mom) container.persistentStoreDescriptions = [desc] container.loadPersistentStores { _, err in if let err { fatalError(err.localizedDescription) } } // Initialize the CloudKit schema after the store finishes loading. try container.initializeCloudKitSchema() // Remove and unload the store from the persistent container. if let store = container.persistentStoreCoordinator.persistentStores.first { try container.persistentStoreCoordinator.remove(store) } } // let fileManager = FileManager.default // let sqliteURL = config.url // let urls: [URL] = [ // sqliteURL, // sqliteURL.deletingLastPathComponent().appendingPathComponent("default.store-shm"), // sqliteURL.deletingLastPathComponent().appendingPathComponent("default.store-wal"), // sqliteURL.deletingLastPathComponent().appendingPathComponent(".default_SUPPORT"), // sqliteURL.deletingLastPathComponent().appendingPathComponent("default_ckAssets") // ] // for url in urls { // try? fileManager.removeItem(at: url) // } } #endif newContainer = try ModelContainer(for: Page.self, configurations: config) // ERROR!!! } catch { fatalError(error.localizedDescription) } modelContainer = newContainer isReady = true } .onDisappear { stopAnimation() } } private func startAnimation() { timer = Timer.scheduledTimer( withTimeInterval: 0.5, repeats: true ) { _ in updateLoadingDots() } } private func stopAnimation() { timer?.invalidate() timer = nil } private func updateLoadingDots() { if loadingDots.count > 2 { loadingDots = "" } else { loadingDots += "." } } } import CoreData import SwiftData import SwiftUI @main struct MyApp: App { @State private var modelContainer: ModelContainer? @State private var isReady: Bool = false var body: some Scene { WindowGroup { if isReady, let modelContainer = modelContainer { ContentView() .modelContainer(modelContainer) } else { InitView(modelContainer: $modelContainer, isReady: $isReady) } } } }
Replies
2
Boosts
0
Views
197
Activity
May ’25
Swift Data Recovery
Hi Writing an app in Swift on Xcode for my iPhone, all software is the latest version. If after making a minor change and re-building all the application data has disappeared, is there a way to see if it is still in the .modelContainer and just not showing up?
Replies
2
Boosts
0
Views
651
Activity
3w
Fatal error on rollback after delete
I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<ChildModel> I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test environment, so the model that's being deleted (or any other) is not being accessed by any other part of the application. However, problem looks the same in the real app. I also changed the target version of iOS from 18.0 to 26.0, but to no avail. My models look kind of like this: @Model final class ParentModel { var name: String @Relationship(deleteRule: .cascade, inverse: \ChildModel.parent) var children: [ChildModel]? init(name: String) { self.name = name } } @Model final class ChildModel { var name: String @Relationship(deleteRule: .nullify) var parent: ParentModel? init(name: String) { self.name = name } } I tried many approaches that didn't help: Fetching all children (via fetch) just to "populate" the context Accessing all children on parent model (via let _ = parentModel.children?.count) Deleting all children reading models from parent: for child in parentModel.children ?? [] { modelContext.delete(child) } Deleting all children like this: let parentPersistentModelID = parentModel.persistentModelID modelContext.delete(model: ChildModel.self, where: #Predicate { $0.parent.persistentModelID == parentPersistentModelID }, includeSubclasses: true) Removing @Relationship(deleteRule: .nullify) from ChildModel relationship definition I found 2 solution for the problem: To manually fetch and delete all children prior to deleting parent: let parentPersistentModelID = parentModel.persistentModelID for child in try modelContext.fetch(FetchDescriptor<ChildModel>(predicate: #Predicate { $0.parent.persistentModelID == parentPersistentModelID })) { modelContext.delete(child) } modelContext.delete(parentModel) Trying to run my code in child context (let childContext = ModelContext(modelContext.container)) All that sounds to me like a problem deep inside Swift Data itself. The first solution I found, fetching potentially hundreds of child models just to delete them in case I might need to rollback changes on some error, sounds like awful waste of resources to me. The second one however seems to work fine has that drawback that I can't fully test my code. Right now I can wrap the context (literally creating class that holds ModelContext and calls its methods) and in tests for throwing methods force them to throw. By creating scratch ModelContext I loose that possibility. What might be the real issue here? Am I missing something?
Replies
2
Boosts
0
Views
114
Activity
1w
Cannot create new CloudKit container after deleting all containers - need help
I accidentally deleted all CloudKit containers from the CloudKit Database console, and now I'm unable to create new containers. Both the CloudKit Console website and Xcode are not allowing me to create any new containers. Is there a way to restore the deleted containers? How can I create a new CloudKit container if the console website is not responding? Thank you.
Replies
2
Boosts
0
Views
120
Activity
3w
TestFlight build crashes from fetch descriptor
I have a FetchDescriptor that uses starts(with:) which works fine in debug builds but crashes in TestFlight and archive. For background information I'm using iCloud and model inheritance where the property being used in fetch descriptor is defined on the superclass, the fetch descriptor is for the subclass. Implementation: static func fetchDescriptor(nameStartingWith prefix: String) -> FetchDescriptor<ColorAsset> { let predicate = #Predicate<ColorAsset> { asset in asset.name.starts(with: prefix) } return FetchDescriptor<ColorAsset>(predicate: predicate) } @Model public class Asset: Identifiable { // MARK: - Properties var name: String = "" .... } @available(macOS 26.0, *) @Model public class ColorAsset: Asset { ... }
Replies
2
Boosts
0
Views
72
Activity
4d
Help Rescuing SwiftData Schema with Non-Optional Transformables
I currently have a schema in production (cloudKit and local files) containing non-optional transformable values, e.g. @Attribute(.transformable(by: TestTransformer.self)) var number: TestTransformable = TestTransformable.init(value: 100) Unfortunately, this is preventing any migration from succeeding (documented at length in FB22151570). Briefly summarized, any migration from a Schema containing non-optional transformable values fails between willMigrate and didMigrate with the error "Can't find model for source store". This occurs for all migrations, including lightweight with a migration plan, lightweight without a plan, and custom migrations. Worst of all, this also prevents migration to optional transformable values, or the elimination of the transformable value entirely, leaving us completely stuck. (note: optional transformable values only work when they have a default value set to nil, otherwise even these have issues migrating) We already have features being blocked by this issue, and would like to preserve user-data while restoring our ability to move forwards with database. Are there any known workarounds for using SwiftData (+CloudKit) when schema migration is non-operational?
Replies
2
Boosts
0
Views
154
Activity
4w
iCloud Account Signing Out
I have several macOS applications that use CloudKit. I need to test and finds out what happens when the user signs out of their iCloud account. That's because the application may lose data after signing out and then signing in again. Every time I do that, it'll take 15, 20 minutes... I don't time it, but it takes quite a gigantic time to sign out as the spinner keeps rolling. Why does it take so long to just sign out? This sign out effect is untestable because it takes a long time to sign out of an iCloud account and then make changes to the code and then test again. In case you need to know, my system version is Sequoia 15.7.
Replies
2
Boosts
0
Views
149
Activity
Feb ’26
Old CloudKit Data Repopulating after a Local Reset
We are trying to solve for the following condition with SwiftData + CloudKit: Lots of data in CloudKit Perform "app-reset" to clear data & App settings and start fresh. Reset data models with try modelContext.delete(model:_) myModel.count() confirms local deletion (0 records); but iCloud Console shows expectedly slow process to delete. Old CloudKit data is returning during the On Boarding process. Questions: • Would making a new iCloud Zone for each reset work around this, as the new zone would be empty? We're having trouble finding details about how to do this with SwiftData. • Would CKSyncEngine have a benefit over the default SwiftData methods? Open to hearing if anyone has experienced a similar challenge and how you worked around it!
Replies
2
Boosts
0
Views
233
Activity
Jun ’25
SwiftData + CloudKit: BGSystemTaskScheduler Code=8
Hi everyone, On macOS 26.4 beta (with Xcode 26.4 beta), I’m seeing the following console messages in a brand new SwiftData + CloudKit template project (no custom logic added, fresh CloudKit container): updateTaskRequest called for a pre-running task com.apple.coredata.cloudkit.activity.export.F9EE783D-7521-4EC2-B42C-9FD1F29BA5C4 updateTaskRequest called for an already running/updated task com.apple.coredata.cloudkit.activity.export.F9EE783D-7521-4EC2-B42C-9FD1F29BA5C4 Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=8 "(null)" These messages appear: When CloudKit is enabled Occasionally on app launch Often when bringing the app back to the foreground (Cmd-Tab away and back) Even with zero additional SwiftData logic They do not appear when CloudKit is disabled. This behavior is reproducible on a completely new project with a fresh CloudKit container. Questions: What exactly do these messages indicate? Is BGSystemTaskScheduler Code=8 expected in this context? Are these safe to ignore? Is this a known change in logging behavior in macOS 26.4 beta? Additionally, in a larger project I’ve observed SwiftData crashes and initially suspected these logs might be related. However, since the issue reproduces in a fresh template project, I’m unsure whether this is simply verbose beta logging or something more serious. Any clarification would be appreciated. Filed as FB21993521.
Replies
2
Boosts
0
Views
201
Activity
Feb ’26