Hello, I'm trying to understand how dangerous it is to read and/or update model properties from a thread different than the one that instantiated the model. I know this is wrong when using Core Data and we should always use perform/performAndWait before manipulating an object but I haven't found any information about that for SwiftData. Question: is it safe to pass an object from one thread (like MainActor) to another thread (in a detached Task for example) and manipulate it, or should we re fetch the object using its persistentModelID as soon as we cross threads? When running the example app below with the -com.apple.CoreData.ConcurrencyDebug 1 argument passed at launch enabled, I don't get any Console warning when I tap on the "Update directly" button. I'm sure it would trigger a warning if I were using Core Data. Thanks in advance for explaining. Axel -- @main struct SwiftDataPlaygroundApp: App { var body: some Scene { WindowGroup { ContentView() .modelContainer(for: Item.self) } } } struct ContentView: View { @Environment(\.modelContext) private var context @Query private var items: [Item] var body: some View { VStack { Button("Add") { context.insert(Item(timestamp: Date.now)) } if let firstItem = items.first { Button("Update directly") { Task.detached { // Not the main thread, but firstItem is from the main thread // No warning in Xcode firstItem.timestamp = Date.now } } Button("Update using persistentModelID") { let container: ModelContainer = context.container let itemIdentifier: Item.ID = firstItem.persistentModelID Task.detached { let backgroundContext: ModelContext = ModelContext(container) guard let itemInBackgroundThread: Item = backgroundContext.model(for: itemIdentifier) as? Item else { return } // Item on a background thread itemInBackgroundThread.timestamp = Date.now try? backgroundContext.save() } } } } } } @Model final class Item: Identifiable { var timestamp: Date init(timestamp: Date) { self.timestamp = timestamp } }

is anyone facing the error, "The current model reference and the next model reference cannot be equal", when using SwiftData with migration and iCloud/CloudKit integration?

I've been struggling to get a ValueTransformer to work while developing in Xcode 16 for iOS 18. Despite thinking I had everything set up correctly, I keep encountering the following error whenever I create a tag: let tag = Tag(name: name, color: color.toPlatformColor()) // Converts it to NSColor or UIColor modelContext.insert(tag) SwiftData/DataUtilities.swift:184: Fatal error: Unable to determine the primitive for Attribute - name: color, options: [transformable with Optional("ColorTransformer")], valueType: UIColor, defaultValue: UIExtendedSRGBColorSpace 0 0 1 1, hashModifier: nil Here’s what I’m dealing with: Tag Model: @Model public final class Tag: Identifiable { var name: String = "" @Attribute(.transformable(by: ColorTransformer.self)) var color: PlatformColor = PlatformColor.blue init(name: String, color: PlatformColor) { self.name = name self.color = color } } ColorTransformer: final class ColorTransformer: ValueTransformer { override func transformedValue(_ value: Any?) -> Any? { guard let color = value as? PlatformColor else { return nil } do { let data = try NSKeyedArchiver.archivedData( withRootObject: color, requiringSecureCoding: true) return data } catch { assertionFailure("Failed to transform `PlatformColor` to `Data`") return nil } } override func reverseTransformedValue(_ value: Any?) -> Any? { guard let data = value as? NSData else { return PlatformColor.black } do { let color = try NSKeyedUnarchiver.unarchivedObject( ofClass: PlatformColor.self, from: data as Data) return color } catch { assertionFailure("Failed to transform `Data` to `PlatformColor`") return nil } } override class func transformedValueClass() -> AnyClass { return PlatformColor.self } override class func allowsReverseTransformation() -> Bool { return true } public static func register() { ValueTransformer.setValueTransformer(ColorTransformer(), forName: .colorTransformer) } } extension NSValueTransformerName { static let colorTransformer = NSValueTransformerName(rawValue: "ColorTransformer") } Platform Alias: #if os(macOS) typealias PlatformColor = NSColor #else typealias PlatformColor = UIColor #endif The ValueTransformer is registered when the ModelContainer is created at app startup: var sharedModelContainer: ModelContainer = { ColorTransformer.register() // Other configurations... }() I've also tried not aliasing the colors to see if that changes anything, but I still encounter the same issue. Any guidance or suggestions would be greatly appreciated!

I have a few apps that use Core Data & CloudKit to sync data to multiple devices. Everything was fine until I updated to Xcode 14. Now, although the apps work on an actual device, in the simulator, I get errors about "Failed to sync user keys" and it won't sync anything. I haven't changed the code at all. It just suddenly won't work in the simulator. Since it does this for all apps, I have to believe it's something changed with the simulator? 2022-09-13 12:47:26.766223-0400 Time Since[8061:88974] [error] error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(1134): <NSCloudKitMirroringDelegate: 0x600003b540e0>: Failed to set up CloudKit integration for store: <NSSQLCore: 0x1219071d0> (URL: file:///Users/jon/Library/Developer/CoreSimulator/Devices/1990772E-CDF1-4A58-B454-E09D327B2182/data/Containers/Data/Application/3314EA95-4D86-4053-84B3-F1523A57E204/Library/Application%20Support/TimeSince.sqlite) <CKError 0x600000cc1e60: "Partial Failure" (2/1011); "Failed to modify some record zones"; partial errors: { com.apple.coredata.cloudkit.zone:__defaultOwner__ = <CKError 0x600000cc2160: "Internal Error" (1/5000); "Failed to sync user keys"> }>

I'm continually getting an error with a new CloudKit container when I try to save data. error: Couldn't get container configuration from the server for container "iCloud.com.***.***" here's the class: private var db = CKContainer(identifier: "iCloud.com.***.***").privateCloudDatabase func addTask(taskItem: TaskItem) async throws { checkStatus() do { try await db.save(taskItem.record) } catch { print("error: \(error.localizedDescription)") } } func checkStatus() { let id = CKContainer(identifier: "iCloud.com.***.***").containerIdentifier print(id ?? "unknown") Task { let status = try await CKContainer(identifier: "iCloud.com.***.***").accountStatus() switch status { case .available: print("available") case .noAccount: print("no account") case .restricted: print("restricted") case .couldNotDetermine: print("could not determine") case .temporarilyUnavailable: print("temporarily unavailable") @unknown default: break } } } The account status reports as available but gives the error on an attempt to save.. I'm trying to work out what I might be doing wrong..

Hello, I`m working on an app that uses CloudKit and CKShare, but the app has 2 different targets, one for professional and one for patients, and theoretically the target of the professional sends the CKShare and the target of the patient should accept, but the ckshare tries to always open the target of the profissional, I would like to know if the are any way to configure the CKShare to oppen the target od the patients

My app is using SwiftData, but I deployed it to the app store with no VersionedSchema applied without thinking about migrating the model. Now I need to migrate the data and I need help from someone who has experience moving from non-versioned to versioned. Assuming I currently have a version1, version2 schema, it works fine for the initial install situation, but when I migrate to version1, version2 in an app that is listed on the app store, I run into problems. I don't have any logs to show for it. Thread 1: EXC_BAD_ACCESS (code=2, address=0x16a6578f0) If anyone has had the same experience as above, please respond, thanks! Let me know what kind of logs you need and I'll add them as a comment.

I have an app and widget that share access to a SwiftData container using App Groups. I have implemented a SwiftData migration plan, but I am unsure whether I should allow the widget to perform the migration (in addition to the app). I am concerned about two possible issues: If the app and widget are run at approximately the same time (e.g. the user taps Open after doing a manual update in the App Store), then both the app and widget might try to perform the migration at the same time, which could lead to race conditions / data corruption. If the widget is first to run but the widget gets suspended for some reasons (e.g., iOS decides it's using too many resources), then the migration might be suspended leaving the database in an corrupted state. To me, it feels like the safest option is to only allow the app itself to perform the migration – this will ensure that the migration can only happen once in a safe state. However, this will lead to problems for the widget. For example, if the user does not open the app for several days after an automatic update, the widget will be in a broken state, since it will not be able to open the container until it has been migrated by the app. Possible solutions I'm considering: Allow both the app and widget to perform the migration and cross my fingers. (Ignore Issue 1 and Issue 2) Implement some kind of UserDefaults flag that is set to true during migration, so that the app and widget will avoid performing the migration concurrently. (Solves Issue 1 but not Issue 2) Only perform the migration in the app, and then add code to the widget to detect which container version the widget has access to, so that the widget can continue to work with a v1 container until the app eventually updates it to a v2 container. (Solves Issue 1 and Issue 2, but leads to very convoluted code – especially over time) Things I'm unsure about: Will iOS continue to use v1 of the widget until the app is opened for the first time, at which point v2 of the widget is installed? Or does iOS immediately update the widget to v2 on update? Does iOS immediately refresh the widget timeline on update? Does SwiftData already have some logic to avoid migrations being performed twice, even from different threads? If so, how does it respond if one process tries to access a container while another process is performing a migration? Does anyone have any recommendations about how to handle these possible issues? What are best practices? Cheers!

After upgrading to iOS 18, my Core Data stack using NSPersistentCloudKitContainer in a shared App Group container stopped syncing correctly. The persistent store configuration, which previously worked in iOS 17, now experiences delayed or missing sync updates between devices. Then the app freezes and writes terminal the same error detail (which I provided) too many times. The debug logs from the CloudKit mirroring delegate (NSCloudKitMirroringDelegate) show repetitive notifications but no updates in persistent history. Additionally, the persistent history tracking key appears unresponsive to local changes, causing transactions to fail in updating or syncing as expected. Key setup details: Core Data is set up within an App Group container using NSPersistentCloudKitContainer. NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey options are set to true. Any insights into changes in iOS 18 Core Data or CloudKit handling with NSPersistentCloudKitContainer, especially around history tracking and sync delays, would be greatly appreciated. Thank you. Error Detail file:///private/var/mobile/Containers/Shared/AppGroup/BF95D309-EBE9-485E-B5CE-AA17097F7B60/[AppName]Database.sqlite CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](3123): <NSCloudKitMirroringDelegate: 0x3032b4870>: Observed context save: <NSPersistentStoreCoordinator: 0x302694bd0> - <NSManagedObjectContext: 0x3036b1a00> CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate remoteStoreDidChange:](3166): <NSCloudKitMirroringDelegate: 0x3032b4870>: Observed remote store notification: <NSPersistentStoreCoordinator: 0x302694bd0> - 090C4244-0101-4DEF-90D6-1260570F47A5 - <NSPersistentHistoryToken - { "090C4244-0101-4DEF-90D6-1260570F47A5" = 9; }> - Persistence.swift struct PersistenceController { let container: NSPersistentCloudKitContainer static let shared = PersistenceController() static var preview: PersistenceController = {PersistenceController()}() init() { container = NSPersistentCloudKitContainer(name: "[AppName]") // Configure CloudKit for the default container if let url = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.[CompanyName].[AppName]") { let storeURL = url.appendingPathComponent("[AppName]Database.sqlite") let description = container.persistentStoreDescriptions.first description?.url = storeURL description?.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description?.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) container.persistentStoreDescriptions = [description].compactMap { $0 } } container.loadPersistentStores { (storeDescription, error) in if let error = error as NSError? { fatalError("Unresolved error \(error), \(error.userInfo)") } } container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy } }

Hi, I'm developing an app for iOS and MacOS with SwiftData and CloudKit syncing. I had sync working very well with a set of models. This schema was also pushed to CloudKit production. Last week I added several models, and several relationship properties linking my existing models to newly added models. The schema updated just fine and everything worked. Then things went sideways: earlier this week I decided I wanted to rename a property on one of my new models. So I renamed the property, removed the application support folder for my local debug app (on Mac OS), removed the app from the iOS Simulator (to clear its local database), and finally reset my CloudKit container to its Production schema. Basically, I tried to go back to the same state I had as when I first added the new models. However, this time things don't go so smoothly, even after starting the app several times, rebooting my machine, turning iCloud on and off in Xcode and MacOS and iOS. When I look in CloudKit console, I see only my old models there: none of the new ones are added. I'd love some pointers on how I can best debug this issue, as I feel completely stuck. On MacOS I have very little mac-logs.txt to go on. Since the logs are a bit lengthy I've added them as an attachment. I get a few warnings, but it is unclear what they are warning me about. One thing that does stand out is that I am running the CloudKit in Development mode here. However, the logs do state accountPartition=Prod . And when I query CKContainer.default() for the container environment, the response is sandbox, which matches Development! On iOS The logs show a few errors, but I cannot make sense of them. error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(1240): <NSCloudKitMirroringDelegate: 0x600003d09860>: Failed to set up CloudKit integration for store: <NSSQLCore: 0x103325c90> (URL: file:///Users/bastiaan/Library/Developer/CoreSimulator/Devices/BF847CE5-A3E2-4B4C-8CD5-616B75B29AFE/data/Containers/Data/Application/0A916F67-B9B2-457B-8FA7-8C42819EA9AA/Library/Application%20Support/default.store) <CKError 0x600000c433f0: "Partial Failure" (2/1011); "Failed to modify some record zones"; partial errors: { com.apple.coredata.cloudkit.zone:__defaultOwner__ = <CKError 0x600000c956b0: "Internal Error" (1/5005); "Couldn't create new PCS blob for zone <CKRecordZoneID: 0x600000c475d0; zoneName=com.apple.coredata.cloudkit.zone, ownerName=__defaultOwner__>"> }> error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate recoverFromError:](2310): <NSCloudKitMirroringDelegate: 0x600003d09860> - Attempting recovery from error: <CKError 0x600000c433f0: "Partial Failure" (2/1011); "Failed to modify some record zones"; partial errors: { com.apple.coredata.cloudkit.zone:__defaultOwner__ = <CKError 0x600000c956b0: "Internal Error" (1/5005); "Couldn't create new PCS blob for zone <CKRecordZoneID: 0x600000c475d0; zoneName=com.apple.coredata.cloudkit.zone, ownerName=__defaultOwner__>"> }> error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _recoverFromPartialError:forStore:inMonitor:]_block_invoke(2773): <NSCloudKitMirroringDelegate: 0x600003d09860>: Found unknown error as part of a partial failure: <CKError 0x600000c956b0: "Internal Error" (1/5005); "Couldn't create new PCS blob for zone <CKRecordZoneID: 0x600000c475d0; zoneName=com.apple.coredata.cloudkit.zone, ownerName=__defaultOwner__>"> error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _recoverFromPartialError:forStore:inMonitor:](2820): <NSCloudKitMirroringDelegate: 0x600003d09860>: Error recovery failed because the following fatal errors were found: { "<CKRecordZoneID: 0x600000c8fd50; zoneName=com.apple.coredata.cloudkit.zone, ownerName=__defaultOwner__>" = "<CKError 0x600000c956b0: \"Internal Error\" (1/5005); \"Couldn't create new PCS blob for zone <CKRecordZoneID: 0x600000c475d0; zoneName=com.apple.coredata.cloudkit.zone, ownerName=__defaultOwner__>\">"; } And in CloudKit logs I see: 06/11/2024, 9:09:59 UTC 738513AC-9326-42DE-B4E2-DA51F6462943 iOS;18.1 ZoneFetch EphemeralGroup { "time":"06/11/2024, 9:09:59 UTC" "database":"PRIVATE" "zone":"com.apple.coredata.cloudkit.zone" "userId":"_0d9445f850459ec351330ca0fde4134f" "operationId":"611BA98C9B10D3F2" "operationGroupName":"EphemeralGroup" "operationType":"ZoneFetch" "platform":"iPhone" "clientOS":"iOS;18.1" "overallStatus":"USER_ERROR" "error":"ZONE_NOT_FOUND" "requestId":"738513AC-9326-42DE-B4E2-DA51F6462943" "executionTimeMs":"53" "interfaceType":"NATIVE" } Any pointers are greatly appreciated! Bastiaan

I'm building a SwiftUI social photo-sharing app that uses CloudKit, where user profiles (including a CKAsset for profile pictures) are displayed throughout the app. To reduce redundant fetching of profiles across multiple views, I’m trying to implement a cache for the profile CKRecord into a custom model. (Important for handling the CKAsset for a user’s profile picture, ensuring it’s moved from the CloudKit fileURL staging area) Here's my current approach: struct UserProfileModel: Identifiable { let id: String let displayUsername: String var profilePicture: UIImage? = nil } class UserProfileCache: ObservableObject { static let shared = UserProfileCache() @Published var cache: [UserProfileModel] = [] } Is this a solid approach for caching CKRecords, or is there a more efficient way to structure this for performance and memory management? I'd appreciate any input or advice on improving this architecture for performance, memory management, and handling profile updates. Thanks in advance for your help!

I'm getting a crash in SwiftData but only on one specific device (iPhone 16 pro running 18.2 22C5131e) and not on an ipad or simulator I cant troubleshoot this crash and its quite frustrating, all I am getting is @Query(sort: \Todo.timestamp, order: .reverse) private var todos: [Todo] ForEach(todos.filter { !$0.completed }) { item in // <---crash TodoListView() } and the error is Thread 1: signal SIGABRT An abort signal terminated the process. Such crashes often happen because of an uncaught exception or unrecoverable error or calling the abort() function. and _SwiftData_SwiftUI.Query.wrappedValue.getter : τ_0_1 -> 0x105b98b58 <+160>: ldur x8, [x29, #-0x40] 0x105b98b5c <+164>: ldur x0, [x29, #-0x38] 0x105b98b60 <+168>: ldur x1, [x29, #-0x30] 0x105b98b64 <+172>: ldur x9, [x29, #-0x20] 0x105b98b68 <+176>: stur x9, [x29, #-0x28] 0x105b98b6c <+180>: ldr x8, [x8, #0x8] 0x105b98b70 <+184>: blr x8 0x105b98b74 <+188>: ldur x0, [x29, #-0x28] 0x105b98b78 <+192>: sub sp, x29, #0x10 0x105b98b7c <+196>: ldp x29, x30, [sp, #0x10] 0x105b98b80 <+200>: ldp x20, x19, [sp], #0x20 0x105b98b84 <+204>: ret How do I fix this?

I'm developing a SwiftUI app using SwiftData and encountering a persistent issue: Error Message: Thread 1: Fatal error: Duplicate keys of type 'Bland' were found in a Dictionary. This usually means either that the type violates Hashable's requirements, or that members of such a dictionary were mutated after insertion. Details: Occurrence: The error always occurs on the first launch of the app after installation. Specifically, it happens approximately 1 minute after the app starts. Inconsistent Behavior: Despite no changes to the code or server data, the error occurs inconsistently. Data Fetching Process: I fetch data for entities (Bland, CrossZansu, and Trade) from the server using the following process: Fetch Bland and CrossZansu entities via URLSession. Insert or update these entities into the SwiftData context. The fetched data is managed as follows: func refleshBlandsData() async throws { if let blandsOnServer = try await DataModel.shared.getBlands() { await MainActor.run { blandsOnServer.forEach { blandOnServer in if let blandOnLocal = blandList.first(where: { $0.code == blandOnServer.code }) { blandOnLocal.update(serverBland: blandOnServer) } else { modelContext.insert(blandOnServer.bland) } } } } } This is a simplified version of my StockListView. The blandList is a @Query property and dynamically retrieves data from SwiftData: struct StockListView: View { @Environment(\.modelContext) private var modelContext @Query(sort: \Bland.sname) var blandList: [Bland] @Query var users: [User] @State private var isNotLoaded = true @State private var isLoading = false @State private var loadingErrorState = "" var body: some View { NavigationStack { List { ForEach(blandList, id: \.self) { bland in NavigationLink(value: bland) { Text(bland.sname) } } } .navigationTitle("Stock List") .onAppear { doIfFirst() } } } // This function handles data loading when the app launches for the first time func doIfFirst() { if isNotLoaded { loadDataWithAnimationIfNotLoading() isNotLoaded = false } } // This function ensures data is loaded with an animation and avoids multiple triggers func loadDataWithAnimationIfNotLoading() { if !isLoading { isLoading = true Task { do { try await loadData() } catch { // Capture and store any errors during data loading loadingErrorState = "Data load failed: \(error.localizedDescription)" } isLoading = false } } } // Fetch data from the server and insert it into the SwiftData model context func loadData() async throws { if let blandsOnServer = try await DataModel.shared.getBlands() { for bland in blandsOnServer { // Avoid inserting duplicate keys by checking for existing items in blandList if !blandList.contains(where: { $0.code == bland.code }) { modelContext.insert(bland.bland) } } } } } Entity Definitions: Here are the main entities involved: Bland: @Model class Bland: Identifiable { @Attribute(.unique) var code: String var sname: String @Relationship(deleteRule: .cascade, inverse: \CrossZansu.bland) var zansuList: [CrossZansu] @Relationship(deleteRule: .cascade, inverse: \Trade.bland) var trades: [Trade] } CrossZansu: @Model class CrossZansu: Equatable { @Attribute(.unique) var id: String var bland: Bland? } Trade: @Model class Trade { @Relationship(deleteRule: .nullify) var user: User? var bland: Bland } User: class User { var id: UUID @Relationship(deleteRule: .cascade, inverse: \Trade.user) var trades: [Trade] } Observations: Error Context: The error occurs after the data is fetched and inserted into SwiftData. This suggests an issue with Hashable requirements or duplicate keys being inserted unintentionally. Concurrency Concerns: The fetch and update operations are performed in asynchronous tasks. Could this cause race conditions? Questions: Could this issue be related to how @Relationship and @Attribute(.unique) are managed in SwiftData? What are potential pitfalls with Equatable implementations (e.g., in CrossZansu) when used in SwiftData entities? Are there any recommended approaches for debugging "Duplicate keys" errors in SwiftData? Additional Info: Error Timing: The error occurs only during the app's first launch and consistently within the first minute.

What is the idiomatic way to use a ModelContext in a document based SwiftData app from a background thread? The relevant DocumentGroup initializers do not give us direct access to a ModelContainer, only to a ModelContext. Is it safe to take its modelContext.container and pass it around (for creating a ModelContext on it on a background thread) or to construct a ModelActor with it? Is it safe to e.g. put a ModelActor so created into the environment of the root view of the window and execute various async data operations on it in Tasks throughout the app, as long as these are dispatched from within the window whose root view's ModelContext was used for getting the ModelContainer?

Exact same app works fine in debug builds, but on release builds I see this stacktrace indicating that assert() was hit. Incident Identifier: *** Distributor ID: com.apple.TestFlight Hardware Model: iPhone14,3 Process: AuditOS [67847] Path: /private/var/containers/Bundle/Application/*** Identifier: *** Version: 1.0 (15) AppStoreTools: 16C5031b AppVariant: 1:iPhone14,3:18 Beta: YES Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: *** Date/Time: 2025-02-11 12:37:54.7801 -0600 Launch Time: 2025-02-11 12:37:33.1737 -0600 OS Version: iPhone OS 18.3 (22D63) Release Type: User Baseband Version: 4.20.03 Report Version: 104 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000019d388e2c Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [67847] Triggered by Thread: 0 Thread 0 Crashed: 0 libswiftCore.dylib 0x000000019d388e2c _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147) 1 SwiftData 0x0000000261842e04 Schema.KeyPathCache.validateAndCache(keypath:on:) + 2628 (Schema.swift:0) 2 SwiftData 0x000000026178cac4 static PersistentModel.keyPathToString(keypath:) + 360 (DataUtilities.swift:36) 3 SwiftData 0x000000026184c9e4 static PersistentModel.fetchDescriptorKeyPathString(for:) + 36 (FetchDescriptor.swift:51) 4 SwiftData 0x00000002617b9770 closure #1 in PredicateExpressions.KeyPath.convert(state:) + 172 (FetchDescriptor.swift:458) 5 SwiftData 0x00000002617b7f48 PredicateExpressions.KeyPath.convert(state:) + 352 (FetchDescriptor.swift:438) 6 SwiftData 0x00000002617bb7ec protocol witness for ConvertibleExpression.convert(state:) in conformance PredicateExpressions.KeyPath&lt;A, B&gt; + 16 (&lt;compiler-generated&gt;:0) 7 SwiftData 0x00000002617baaa0 PredicateExpression.convertToExpressionOrPredicate(state:) + 716 (FetchDescriptor.swift:219) 8 SwiftData 0x00000002617ba6dc PredicateExpression.convertToExpression(state:) + 32 (FetchDescriptor.swift:237) 9 SwiftData 0x00000002617b7cfc PredicateExpressions.Equal.convert(state:) + 328 (:-1) 10 SwiftData 0x00000002617bba08 protocol witness for ConvertibleExpression.convert(state:) in conformance PredicateExpressions.Equal&lt;A, B&gt; + 64 (&lt;compiler-generated&gt;:0) 11 SwiftData 0x00000002617baaa0 PredicateExpression.convertToExpressionOrPredicate(state:) + 716 (FetchDescriptor.swift:219) 12 SwiftData 0x00000002617b7abc PredicateExpression.convertToPredicate(state:) + 28 (FetchDescriptor.swift:244) 13 SwiftData 0x00000002617b7190 nsFetchRequest&lt;A&gt;(for:in:) + 1204 (FetchDescriptor.swift:64) 14 SwiftData 0x0000000261783358 DefaultStore.fetch&lt;A&gt;(_:) + 292 (DefaultStore.swift:496) 15 SwiftData 0x000000026178322c protocol witness for DataStore.fetch&lt;A&gt;(_:) in conformance DefaultStore + 16 (&lt;compiler-generated&gt;:0) 16 SwiftData 0x00000002617847fc asDataStore #1 &lt;A&gt;&lt;A1&gt;(_:) in closure #1 in ModelContext.fetch&lt;A&gt;(_:) + 3152 (ModelContext.swift:2590) 17 SwiftData 0x00000002617a74d8 partial apply for closure #1 in ModelContext.fetch&lt;A&gt;(_:) + 100 (&lt;compiler-generated&gt;:0) 18 SwiftData 0x00000002617a7438 closure #1 in ModelContext.enumerateFetchableStores&lt;A&gt;(_:_:) + 208 (ModelContext.swift:2527) 19 SwiftData 0x00000002617a731c specialized ModelContext.enumerateFetchableStores&lt;A&gt;(_:_:) + 200 (ModelContext.swift:2522) 20 SwiftData 0x00000002617a6f08 ModelContext.fetch&lt;A&gt;(_:) + 144 (ModelContext.swift:2534) 21 SwiftData 0x00000002617a6e70 dispatch thunk of ModelContext.fetch&lt;A&gt;(_:) + 56 (:-1) 22 AuditOS 0x00000001041af3f4 0x10419c000 + 78836 23 AuditOS 0x00000001041bebd5 0x10419c000 + 142293 24 AuditOS 0x00000001041bbbf5 0x10419c000 + 130037 25 AuditOS 0x00000001041d8be5 0x10419c000 + 248805 26 AuditOS 0x00000001041bde6d 0x10419c000 + 138861 27 libswift_Concurrency.dylib 0x00000001aa6bfe39 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497) The code in question looks like this: func addRecord&lt;T: MyDtoProtocol&gt;(_ someDTO: T) async throws { var zone: ZoneModel? = nil let recordName = someDTO.recordNameType let fetchDescriptor = FetchDescriptor&lt;T.ModelType&gt; (predicate: #Predicate {$0.recordName == recordName}) &gt; var localEntitites: [T.ModelType] = try modelContext.fetch(fetchDescriptor) &lt;---- I have isolated crash to this line. Basically for each swiftdata model type I have associatedType for Data Transfer Object type and vice versa.

I'm calling a method with the context as parameter, within the context's perform block – is this really not legal in Swift 6? actor MyActor { func bar(context: NSManagedObjectContext) { /* some code */ } func foo(context: NSManagedObjectContext) { context.performAndWait { self.bar(context: context) // WARN: Sending 'context' risks causing data races; this is an error in the Swift 6 language mode // 'self'-isolated 'context' is captured by a actor-isolated closure. actor-isolated uses in closure may race against later nonisolated uses // Access can happen concurrently } } } The warning appears when I call a method with a context parameter, within the performAndWait-block. Background: In my app I have methods that takes in API data, and I need to call the same methods from multiple places with the same context to store it, and I do not want to copy paste the code and have hundreds of lines of duplicate code. Is there a well-known "this is how you should do it" for situations like this? This is related to a previous post I made, but it's a bit flimsy and got no response: https://developer.apple.com/forums/thread/770605

For the past several days every time I log in to to the Cloudkit dashboard I get Error looking up Developer Teams, Please sign out and try again. No amount of singing out and back in changes anything.

Background I have an established app in the App Store which has been using NSPersistentCloudkitContainer since iOS 13 without any issues. I've been running my app normally on an iOS device running the iOS 15 betas, mainly to see problems arise before my users see them. Ever since iOS 15 (beta 4) my app has failed to sync changes - no matter how small the change. An upload 'starts' but never completes. After a minute or so the app quits to the Home Screen and no useful information can be gleaned from crash reports. Until now I've had no idea what's going on. Possible Bug in the API? I've managed to replicate this behaviour on the simulator and on another device when building my app with Xcode 13 (beta 5) on iOS 15 (beta 5). It appears that NSPersistentCloudkitContainer has a memory leak and keeps ramping up the RAM consumption (and CPU at 100%) until the operating system kills the app. No code of mine is running. I'm not really an expert on these things and I tried to use Instruments to see if that would show me anything. It appears to be related to NSCloudkitMirroringDelegate getting 'stuck' somehow but I have no idea what to do with this information. My Core Data database is not tiny, but not massive by any means and NSPersistentCloudkitContainer has had no problems syncing to iCloud prior to iOS 15 (beta 4). If I restore my App Data (from an external backup file - 700MB with lots of many-many, many-one relationships, ckAssets, etc.) the data all gets added to Core Data without an issue at all. The console log (see below) then shows that a sync is created, scheduled & then started... but no data is uploaded. At this point the memory consumption starts and all I see is 'backgroundTask' warnings appear (only related to CloudKit) with no code of mine running. CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExporter analyzeHistoryInStore:withManagedObjectContext:error:](501): <PFCloudKitExporter: 0x600000301450>: Exporting changes since (0): <NSPersistentHistoryToken - { "4B90A437-3D96-4AC9-A27A-E0F633CE5D9D" = 906; }> CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExportContext processAnalyzedHistoryInStore:inManagedObjectContext:error:]_block_invoke_3(251): Finished processing analyzed history with 29501 metadata objects to create, 0 deleted rows without metadata. CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _scheduleAutomatedExportWithLabel:activity:completionHandler:](2800): <NSCloudKitMirroringDelegate: 0x6000015515c0> - Beginning automated export - ExportActivity: <CKSchedulerActivity: 0x60000032c500; containerID=<CKContainerID: 0x600002ed3240; containerIdentifier=iCloud.com.nitramluap.Somnus, containerEnvironment="Sandbox">, identifier=com.apple.coredata.cloudkit.activity.export.4B90A437-3D96-4AC9-A27A-E0F633CE5D9D, priority=2, xpcActivityCriteriaOverrides={ Priority=Utility }> CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate executeMirroringRequest:error:](765): <NSCloudKitMirroringDelegate: 0x6000015515c0>: Asked to execute request: <NSCloudKitMirroringExportRequest: 0x600002ed2a30> CBE1852D-7793-46B6-8314-A681D2038B38 2021-08-13 08:41:01.518422+1000 Somnus[11058:671570] [BackgroundTask] Background Task 68 ("CoreData: CloudKit Export"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. 2021-08-13 08:41:03.519455+1000 Somnus[11058:671570] [BackgroundTask] Background Task 154 ("CoreData: CloudKit Scheduling"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. Just wondering if anyone else is having a similar issue? It never had a problem syncing an initial database restore prior to iOS 15 (beta 4) and the problems started right after installing iOS 15 (beta 4). I've submitted this to Apple Feedback and am awaiting a response (FB9412346). If this is unfixable I'm in real trouble (and my users are going to be livid). Thanks in advance!

I'm building a macOS + iOS SwiftUI app using Xcode 14.1b3 on a Mac running macOS 13.b11. The app uses Core Data + CloudKit. With development builds, CloudKit integration works on the Mac app and the iOS app. Existing records are fetched from iCloud, and new records are uploaded to iCloud. Everybody's happy. With TestFlight builds, the iOS app has no problems. But CloudKit integration isn't working in the Mac app at all. No existing records are fetched, no new records are uploaded. In the Console, I see this message: error: CoreData+CloudKit: Failed to set up CloudKit integration for store: <NSSQLCore: 0x1324079e0> (URL: <local file url>) Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction.} I thought it might be that I was missing the com.apple.security.network.client entitlement, but adding that didn't help. Any suggestions what I might be missing? (It's my first sandboxed Mac app, so it might be really obvious to anyone but me.)

I'm using Xcode 16 and SwiftUI targeting iOS 18. I'm new to Core Data, and when I create a new project and select to use Core Data as storage, I get boilerplate code for it. The problem is that when I try to see the preview without any change to the code, I get a Fatal Error: CrashReportError: Fatal Error in Persistence.swift Test crashed due to fatalError in Persistence.swift at line 52. Unresolved error Error Domain=NSSQLiteErrorDomain Code=8 "(null)" UserInfo={NSFilePath=/Users/monni/Library/Developer/Xcode/UserData/Previews/Simulator Devices/D0D98B5B-7E6F-4DC3-B16A-34D6D2958558/data/Containers/Data/Application/A98879A6-46F5-4E29-B2D7-AD294F1EFFD0/Library/Application Support/Test.sqlite, NSSQLiteErrorDomain=8}, ["NSSQLiteErrorDomain": 8, "NSFilePath": /Users/monni/Library/Developer/Xcode/UserData/Previews/Simulator Devices/D0D98B5B-7E6F-4DC3-B16A-34D6D2958558/data/Containers/Data/Application/A98879A6-46F5-4E29-B2D7-AD294F1EFFD0/Library/Application Support/Test.sqlite] When I try to open the SQLite database there are no entities in it. I have also tried xcrun simctl --set previews delete all, but with no luck.