I am using SwiftData with CloudKit to synchronize data across multiple devices, and I have encountered an issue: occasionally, abnormal sync behavior occurs between two devices (it does not happen 100% of the time—only some users have reported this problem). It seems as if synchronization between the two devices completely stops; no matter what operations are performed on one end, the other end shows no response. After investigating, I suspect the issue might be caused by both devices simultaneously modifying the same field, which could lead to CloudKit's logic being unable to handle such conflicts and causing the sync to stall. Are there any methods to avoid or resolve this situation? Of course, I’m not entirely sure if this is the root cause. Has anyone encountered a similar issue?

The NSPersistentCloudKitContainer synchronization between core data and iCloud was working fine with phone 15.1. Connected a new iPhone iOS 15.5, it gives error: CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2504): <NSCloudKitMirroringDelegate: 0x28198c000>: Observed context save: <NSPersistentStoreCoordinator: 0x2809c9420> - <NSManagedObjectContext: 0x2819ad520> 2022-12-05 13:32:28.377000-0600 r2nr[340:6373] [error] error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _importFinishedWithResult:importer:](1245): <PFCloudKitImporter: 0x2837dd740>: Import failed with error: Error Domain=NSCocoaErrorDomain Code=4864 "*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: incomprehensible archive (0x53, 0x6f, 0x6d, 0x65, 0x20, 0x65, 0x78, 0x61)" UserInfo={NSDebugDescription=*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: incomprehensible archive (0x53, 0x6f, 0x6d, 0x65, 0x20, 0x65, 0x78, 0x61)} CoreData: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _importFinishedWithResult:importer:](1245): <PFCloudKitImporter: 0x2837dd740>: Import failed with error: Error Domain=NSCocoaErrorDomain Code=4864 "*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: incomprehensible archive (0x53, 0x6f, 0x6d, 0x65, 0x20, 0x65, 0x78, 0x61)" UserInfo={NSDebugDescription=*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: incomprehensible archive (0x53, 0x6f, 0x6d, 0x65, 0x20, 0x65, 0x78, 0x61)} I go back and try with my old iPhone iOS 15.1, gives same error.

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?

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?

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?

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

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() } } }

While testing record creation in public CloudKit database for authenticated user I am able to do so without any issues. But for devices missing iCloud account or authentication expired I am seeing the below error: ▿ <CKError 0x97a959200: "Permission Failure" (10/2007); server message = "CREATE operation not permitted"; op = 67331DE3AF3DD666; uuid = 1F3ACD4F-A799-4CD4-ADF0-EDE9E12F2DCB; container ID = "***"> _nsError : <CKError 0x97a959200: "Permission Failure" (10/2007); server message = "CREATE operation not permitted"; op = 67331DE3AF3DD666; uuid = 1F3ACD4F-A799-4CD4-ADF0-EDE9E12F2DCB; container ID = "***"> I am unable to add create/write permission to _world security role in dashboard. Is this something not supported by Cloudkit? Only authenticated iCloud users will be able to create and write data to public database as well?

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.

I have a SwiftData flashcard app which I am syncing with CloudKit using NSPersistentCloudKitContainer. While syncing itself is working perfectly, I have noticed a dramatic increase in the app size after enabling sync. Specifically, without CloudKit, 15k flashcards results in the default.store file being about 4.5 MB. With CloudKit, default.store is about 67 MB. I have inspected the store and found that most of this increase is due to the ANSCKRECORDMETADATA table. My question is, does implementing CloudKit normally cause this magnitude of increase in storage? If it doesn’t, is there something in my model, schema, implementation, etc. that could be causing it? Below are two other posts describing a similar issue, but neither with a solution. I replied to the first one about a month ago. I then submitted this to Developer Technical Support, but was asked to post my question in the forums, so here it is. Strange behavior with 100k+ records in NSPersistentCloudKitContainer Huge increase in sqlite file size after adopting CloudKit

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?

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????

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!

Since running on iOS 14b1, I'm getting this in my log (I have Core Data logging enabled): error: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store at 'file:///private/var/mobile/Containers/Shared/AppGroup/415B75A6-92C3-45FE-BE13-7D48D35909AF/StoreFile.sqlite' As far as I can tell, it's impossible to open my store without that key set - it's in the init() of my NSPersistentContainer subclass, before anyone calls it to load stores. Any ideas?

I am trying out the new AttributedString binding with SwiftUI’s TextEditor in iOS26. I need to save this to a Core Data database. Core Data has no AttributedString type, so I set the type of the field to “Transformable”, give it a custom class of NSAttributedString, and set the transformer to NSSecureUnarchiveFromData When I try to save, I first convert the Swift AttributedString to NSAttributedString, and then save the context. Unfortunately I get this error when saving the context, and the save isn't persisted: CoreData: error: SQLCore dispatchRequest: exception handling request: <NSSQLSaveChangesRequestContext: 0x600003721140> , <shared NSSecureUnarchiveFromData transformer> threw while encoding a value. with userInfo of (null) Here's the code that tries to save the attributed string: struct AttributedDetailView: View { @ObservedObject var item: Item @State private var notesText = AttributedString() var body: some View { VStack { TextEditor(text: $notesText) .padding() .onChange(of: notesText) { item.attributedString = NSAttributedString(notesText) } } .onAppear { if let nsattributed = item.attributedString { notesText = AttributedString(nsattributed) } else { notesText = "" } } .task { item.attributedString = NSAttributedString(notesText) do { try item.managedObjectContext?.save() } catch { print("core data save error = \(error)") } } } } This is the attribute setup in the Core Data model editor: Is there a workaround for this? I filed FB17943846 if someone can take a look. Thanks.

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 { ... }

I'm a first time developer for Swift, (getting on a bit!) but after programming in VB back in the late 90s I wanted to write an app for iPhone. I think I might have gone about it the wrong way, but I've got an app that works great on my iPhone or works great on my iPad. It saves the data persistently on device, but, no matter how much I try, what I read and even resorting to AI (ChatGPT & Gemini) I still can't get it to save the data on iCloud to synchronise between the two and work across the devices. I think it must be something pretty fundamental I'm doing (or more likely not doing) that is causing the issue. I'm setting up my signing and capabilities as per the available instructions but I always get a fatal error. I think it might be something to do with making fields optional, but at this point I'm second guessing myself and feeling a complete failure. Any advice or pointers would be really gratefully appreciated. I like my app and would like eventually to get it on the App Store but at this point in time I feel it should be on the failed projects heap! I've even tried a new Xcode project for iOS and asking it to use SwiftData and CloudKit - the default project should work - right? But it absolutely doesn't for me. Please send help!!

I've run into a strange issue. If a sheet loads a view that has a SwiftData @Query, and there is an if statement in the view body, I get the following error when running an iOS targetted SwiftUI app under MacOS 26.1: Set a .modelContext in view's environment to use Query While the view actually ends up loading the correct data, before it does, it ends up re-creating the sqlite store (opening as /dev/null). The strange thing is that this only happens if there is an if statement in the body. The statement need not ever evaluate true, but it causes the issue. Here's an example. It's based on the default xcode new iOS project w/ SwiftData: struct ContentView: View { @State private var isShowingSheet = false var body: some View { Button(action: { isShowingSheet.toggle() }) { Text("Show Sheet") } .sheet(isPresented: $isShowingSheet, onDismiss: didDismiss) { VStack { ContentSheetView() } } } func didDismiss() { } } struct ContentSheetView: View { @Environment(\.modelContext) private var modelContext @Query public var items: [Item] @State var fault: Bool = false var body: some View { VStack { if fault { Text("Fault!") } Button(action: addItem) { Label("Add Item", systemImage: "plus") } List { ForEach(items) { item in Text(item.timestamp, format: Date.FormatStyle(date: .numeric, time: .standard)) } } } } private func addItem() { withAnimation { let newItem = Item(timestamp: Date()) modelContext.insert(newItem) } } } It requires some data to be added to trigger, but after adding it and dismissing the sheet, opening up the sheet with trigger the Set a .modelContext in view's environment to use Query. Flipping on -com.apple.CoreData.SQLDebug 1 will show it trying to recreate the database. If you remove the if fault { Text("Fault!") } line, it goes away. It also doesn't appear to happen on iPhones or in the iPhone simulator. Explicitly passing modelContext to the ContentSheetView like ContentSheetView().modelContext(modelContext) also seems to fix it. Is this behavior expected?

The production macOS build is showing severe performance problems, while Mac_Dev performs normally. Observed behavior in production Mac build: Issue board scrolling becomes inconsistent or nearly unusable Changing an issue status in detail view is very slow Scrolling the status menu/options can be slow Typing in issue description/notes fields becomes sluggish Dragging issues between milestones/statuses on the board can lag badly Observed behavior in Mac_Dev: Board scrolling is smooth Status changes are immediate Typing in description fields is responsive Drag/drop between milestones works well Important comparison: Mac_Dev appears to run against an isolated local SwiftData store Production Mac app uses the normal CloudKit-backed store Because the same UI is fast in Mac_Dev, this does not look like a pure rendering problem Most likely cause is production store / CloudKit sync churn amplifying existing SwiftUI invalidation and save behavior Current hypothesis: The production app is saving or observing live Issue mutations too aggressively Detail view edits and some quick actions may be causing repeated saves / broad view invalidation Cloud-backed persistence likely makes the problem much worse than the isolated dev store The UI architecture may still need cleanup, but the production data lane is likely a major factor Any help in understanding how best to address this would be helpful.

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?