Users have been reporting that the TestFlight version of my app (compiled with Xcode 26 Beta 6 17A5305f) is sometimes crashing on startup. Upon investigating their ips files, it looks like Core Data is locking up internally during its initialization, resulting in iOS killing my app. I have not recently changed my Core Data initialization logic, and it's unclear how I should proceed. Is this a known issue? Any recommended workaround? I have attached the crash stack below. Thanks! crash_log.txt

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.

Hi all, I have setup my app to use SwiftData with CloudKit sync. I have a production environment and development environment. I can reset the development environment for myself and all users in CloudKit console, but I can't reset the production one as it's tried to users' iCloud accounts, so I've added a button in-app for that feature. In the onboarding of my app, I pre-seed the DB with some default objects, which should be persisted between app install. The issue I'm running into is that I'm unable to force-pull these models from iCloud during the onboarding of a clean re-install, which leads to the models later appearing as duplicates once the user has been on the app for a few minutes and it has pulled from their iCloud account. If anyone has any suggestions on how to handle this issue, I would greatly appreciate it.

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.

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.

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

我正在使用 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 实体并允许保存？ 任何帮助或指导将不胜感激。

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?

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?

It takes a few seconds, sometimes a few minutes for records to be downloaded back from CloudKit when the user reinstalls the app, which leads users to thinking their data was lost. I would like to know if there’s any way to provide a visual feedback about the current CloudKit sync status so I can let users know their data is being in fact downloaded back to their devices.

I'm writing some tests to confirm the behavior of my app. White creating a model actor to delete objects I realized that ModelContext.model(for:) does return objects that are deleted. I was able to reproduces this with this minimal test case: @Model class Activity { init() {} } struct MyLibraryTests { let modelContainer = try! ModelContainer( for: Activity.self, configurations: ModelConfiguration( isStoredInMemoryOnly: true ) ) init() throws { let context = ModelContext(modelContainer) context.insert(Activity()) try context.save() } @Test func modelForIdAfterDelete() async throws { let context = ModelContext(modelContainer) let id = try context.fetch(FetchDescriptor<Activity>()).first!.id context.delete(context.model(for: id) as! Activity) try context.save() let result = context.model(for: id) as? Activity #expect(result == nil) // Expectation failed: (result → MyLibrary.Activity) == nil } @Test func fetchDescriptorAfterDelete() async throws { let context = ModelContext(modelContainer) let id = try context.fetch(FetchDescriptor<Activity>()).first!.id context.delete(context.model(for: id) as! Activity) try context.save() let result = try context.fetch( FetchDescriptor<Activity>(predicate: #Predicate { $0.id == id }) ).first #expect(result == nil) } } Here I create a new context, insert an model and save it. The test modelForIdAfterDelete does fail, as result still contains the deleted object. I also tried to check #expect(result!.isDeleted), but it is also false. With the second test I use a FetchDescriptor to retrieve the object by ID and it correctly returns nil. Shouldn't both methods use a consistent behavior?

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

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.

I want to get to a point where I can use a small view with a query for my SwiftData model like this: @Query private var currentTrainingCycle: [TrainingCycle] init(/*currentDate: Date*/) { _currentTrainingCycle = Query(filter: #Predicate<TrainingCycle> { $0.numberOfDays > 0 // $0.startDate < currentDate && currentDate < $0.endDate }, sort: \.startDate) } The commented code is where I want to go. In this instance, it'd be created as a lazy var in a viewModel to have it stable (and not constantly re-creating the view). Since it was not working, I thought I could check the same view with a query that does not require any dynamic input. In this case, the numberOfDays never changes after instantiation. But still, each time the app tries to create this view, the app becomes unresponsive, the CPU usage goes at 196%, memory goes way high and the device heats up quickly. Am I holding it wrong? How can I have a dynamic predicate on a View in SwiftUI with SwiftData?

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.

Hi, I’m working on a macOS app that includes a file browser component. And I’m trying to match Finder’s behavior for color tags and folder icons. For local files/folders everything works fine: Tag color key returns the expected label number via NSColor * labelColor = nil; [fileURL getResourceValue:&labelColor forKey:NSURLLabelColorKey error:nil]; NSNumber * labelKey = nil; [fileURL getResourceValue:&labelKey forKey:NSURLLabelNumberKey error:nil]; QLThumbnailGenerator obtains the expected colored folder icon (including emoji/symbol overlay if set) via QLThumbnailGenerationRequest * request = [[QLThumbnailGenerationRequest alloc] initWithFileAtURL:fileURL size:iconSize scale:scaleFactor representationTypes:QLThumbnailGenerationRequestRepresentationTypeIcon]; request.iconMode = YES; [[QLThumbnailGenerator sharedGenerator] generateBestRepresentationForRequest:request completionHandler:^(QLThumbnailRepresentation * _Nullable thumbnail, NSError * _Nullable error) { if (thumbnail != nil && error == nil) { NSImage * thumbnailImage = [thumbnail NSImage]; // ... } }]; However, for items on iCloud Drive (whether currently downloaded locally or only stored in the cloud), the same code always produces gray colors, while Finder shows everything correctly: NSURLLabelNumberKey always returns 1 (gray) for items with color tags, and 0 for non-tagged. Folder icons returned via QLThumbnailGenerator are gray, no emoji/symbol overlays. Reading tag data from xattr gives values like “Green\1” (tag name matches, but numeric value is still "Gray"). Also, if I move a correctly-tagged local item into iCloud Drive, it immediately becomes gray in my app (Finder still shows the correct colors). Question: What is the supported way to retrieve Finder tag colors and the correct folder icon appearance (color + overlays) for items in iCloud Drive, so that the result matches Finder? I am on macOS Tahoe 26.2/26.3, Xcode 26.2 (17C52). If you need any additional details, please let me know. Thanks!

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?

Hi, I am creating (or trying to) my first app using SwiftData - and I have questions :-) The main question I can't get my head wrapped around is the following: Let's say I have the sample below... @Model class Person { @Relationship(inverse:\Hat.owner) var hat:Hat } @Model class Hat { var owner:Person? } It looks like I am creating a strong reference cycle between the person and the hat objects? And in fact I am seeing these kinds of reference cycles when I look at the memory debugger. Many code samples I have seen so far use this type of relationship declaration... And I am wondering: Am I missing something? Admittedly I don't find many discussions about memory leaks caused by SwiftData despite the syntax being used in many examples? So what is the situation? Did Apple just miss to explain that the inverse: declaration causes memory leaks or is there some kind of magic that I should understand?