Hi, I'm having trouble implementing iCloud Drive in my app. I've already taken the obvious steps, including enabling iCloud Documents in Xcode and selecting a container. This container is correctly specified in my code, and in theory, everything should work. The data generated by my app should be saved to iCloud Drive in addition to local storage. The data does get stored in the Files app, but the automatic syncing to iCloud Drive doesn’t work as expected. I’ve also considered updating my .entitlements file. Since I’m at a loss, I’m reaching out for help maybe I’ve overlooked something important that's causing it not to work. If anyone has an idea, please let me know. Thanks in advance!

I would like to have a SwiftData predicate that filters against an array of PersistentIdentifiers. A trivial use case could filtering Posts by one or more Categories. This sounds like something that must be trivial to do. When doing the following, however: let categoryIds: [PersistentIdentifier] = categoryFilter.map { $0.id } let pred = #Predicate<Post> { if let catId = $0.category?.persistentModelID { return categoryIds.contains(catId) } else { return false } } The code compiles, but produces the following runtime exception (XCode 26 beta, iOS 26 simulator): 'NSInvalidArgumentException', reason: 'unimplemented SQL generation for predicate : (TERNARY(item != nil, item, nil) IN {}) (bad LHS)' Strangely, the same code works if the array to filter against is an array of a primitive type, e.g. String or Int. What is going wrong here and what could be a possible workaround?

I'm working on a macOS app with a Safari web extension. I'm trying to share a SwiftData model between devices using CloudKit synchronization. I am able to get synchronization in the main app on the same device, CloudKit sync works correctly — changes appear in the CloudKit Dashboard under com.apple.coredata.cloudkit.zone. However, in the Safari App Extension, data is saved locally and persists across launches, but never syncs to CloudKit. I have followed the recommended practices for configuring the App Group and entitlements, but the issue persists. Questions: Is there an official limitation preventing Safari App Extensions from connecting to the CloudKit daemon (cloudd)? If not, what entitlements or configuration changes are required for a Safari App Extension to successfully sync with CloudKit? Is the xpc_error=159 from bootstrap_look_up() a known sandbox restriction for this extension type? Any guidance from Apple engineers or others who have successfully used CloudKit from a Safari App Extension would be appreciated. What I’ve confirmed: The extension’s .entitlements includes: com.apple.security.app-sandbox com.apple.developer.icloud-services CloudKit com.apple.developer.icloud-container-identifiers iCloud.dev.example.myapp Same iCloud container ID for both app and extension CloudKit container exists and is initialized in CloudKit Console Running in :Sandbox environment during development Database name in SwiftData matches container identifier (without the iCloud. prefix) The extension’s codesign output shows correct entitlements App Group is configured (although in this case, extension and app use separate stores intentionally) Observed behavior in Console.app logs: CloudKit sync engine initializes in the extension XPC activities are registered for import/export: _xpc_activity_register: com.apple.coredata.cloudkit.activity.export. xpc_activity_set_criteria: ... import. Then a bootstrap lookup fails: failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] CloudKit daemon connection error: CKErrorDomain Code=6 "Error connecting to CloudKit daemon" NSCocoaErrorDomain Code=4099 There is no “Will attempt to upload transactions” or “Upload succeeded” logs are ever seen. Symptoms When the extension is run, I see logs like the following in Console.app: [0x13e215820] failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] CoreData+CloudKit: -[PFCloudKitSetupAssistant _checkAccountStatus:]_block_invoke(342): Fetched account info for store : (null) Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon. This could happen for many reasons..."

Hi. I am having this error when trying to write to CloudKit public database. <CKError 0x600000dbc4e0: "Permission Failure" (10/2007); server message = "Invalid bundle ID for container"; On app launch, I check for account status and ensure that the correct bundle identifier and container is being used. When the account status is checked, I do get the correct bundle id and container id printed in the console but trying to read or write to the container would throw that "Invalid bundle ID for container" error. private init() { container = CKContainer.default() publicDB = container.publicCloudDatabase // Check iCloud account status checkAccountStatus() } func checkAccountStatus() { print("🔍 CloudKit Debug:") print("🔍 Bundle identifier from app: (Bundle.main.bundleIdentifier ?? "unknown")") print("🔍 Container identifier: (container.containerIdentifier ?? "unknown")") container.accountStatus { [weak self] status, error in DispatchQueue.main.async { switch status { case .available: self?.isSignedIn = true self?.fetchUserID() case .noAccount, .restricted, .couldNotDetermine: self?.isSignedIn = false self?.errorMessage = "Please sign in to iCloud in Settings to use this app." default: self?.isSignedIn = false self?.errorMessage = "Unknown iCloud account status." } print("User is signed into iCloud: \(self?.isSignedIn ?? false)") print("Account status: \(status.rawValue)") } } } I have tried: Creating a new container Unselecting and selecting the container in signing & capabilities Unselecting and selecting the container in App ID Configuration I used to have swift data models in my code and read that swift data is not compatible with CloudKit public data so I removed all the models and any swift data codes and only uses CloudKit public database. let savedRecord = try await publicDB.save(record) Nothing seems to work. If anyone could help please? Rgds, Hans

Starting somewhere around macOS 26.3, my sandboxed file manager spontaneously loses access to ~/Library/Mobile Documents mid-session. Setup: at launch, the user grants access to '/', '/Users', or '~' via NSOpenPanel; I store a security-scoped bookmark and call startAccessingSecurityScopedResource(). This works fine - including iCloud Drive - until some point mid-session. When it breaks, two things happen simultaneously: Enumeration fails: NSCocoaErrorDomain Code=257 (NSFileReadNoPermissionError)< NSPOSIXErrorDomain Code=1 (EPERM) Console shows the kernel refusing extension issuance: couldn't issue sandbox extension com.apple.app-sandbox.read for '/Users//Library/Mobile Documents': Operation not permitted And probing NSFileProviderManager confirms the process has been rejected system-wide: NSFileProviderManager.getDomainsWithCompletionHandler > NSFileProviderErrorDomain Code=-2001 "The application cannot be used right now." (underlying Code=-2014) What makes this specific to FP-backed paths: regular paths under the same '/' bookmark (~/Library/Application Support, etc.) stay accessible and recover normally with a fresh startAccessingSecurityScopedResource() call. Only ~/Library/Mobile Documents and its subtree fail - the entire tree, including the parent directory itself. Relaunch always restores access. What I've tried and ruled out: Re-resolving the bookmark + startAccessingSecurityScopedResource() - returns stale=false, granted=true but access is not restored; the kernel still refuses extension issuance for FP-traversing paths. NSFileCoordinator coordinated read - doesn't help; the coordinator depends on the same sandbox extension the kernel is refusing. Instantiating NSFileProviderManager(for: domain) per domain - fails with -2001 for every domain, confirming the rejection is process-wide, not path- or domain-specific. My working theory: when a FileProvider daemon (bird/cloudd/fileproviderd) restarts mid-session, the process's FP-client XPC registration is invalidated, and the kernel subsequently refuses to issue sandbox extensions for any path served by FP - even with a valid bookmark. The process seems to have no API path to re-register its FP-client identity without relaunching. Current workaround: I detect the -2001 response and prompt the user to relaunch, then do a programmatic self-relaunch if they confirm (which is obviously horribly intrusive). Questions: Is there an API that lets a sandboxed consumer app reconnect its FP-client identity mid-session, short of relaunching? Is there an entitlement or capability that would make the kernel's extension issuance resilient to FP daemon restarts? Has anyone else hit this on 26.x and found a workaround? Filed as FB22547671.

Hi, Not sure how to describe my issue best: I am using SwiftData and CloudKit to store my data. In the past, when I tested my app on different devices, the data would sync between the devices automatically. For whatever reason this has stopped now and the data no longer syncs. No matter what I do, it feels as if all the data is actually stored just locally on each device. How can I check if the data is actually stored in the cloud and what could be reasons, why its no longer synching between my devices (and yes, I am logged in with the same Apple ID on all devices). Thanks for any hint! Max

I am trying to save to cloud kit shared database. The shared database does not allow zones to be set up. How do I save to sharedCloudDatabase without a zone? private func addItem(recordType: String, name: String) { let record = CKRecord(recordType: recordType) record[Constances.field.name] = name as CKRecordValue record[Constances.field.done] = false as CKRecordValue record[Constances.field.priority] = 0 as CKRecordValue CKContainer.default().sharedCloudDatabase.save(record) { [weak self] returnRecord, error in if let error = error { print("Error saving record: \(record[Constances.field.name] as? String ?? "No Name"): \n \(error)") return } } } The following error message prints out: Error saving record: Milk: &lt;CKError 0x15af87900: "Server Rejected Request" (15/2027); server message = "Default zone is not accessible in shared DB"; op = B085F7BA703D4A08; uuid = 87AEFB09-4386-4E43-81D7-971AAE8BA9E0; container ID = "iCloud.com.sfw-consulting.Family-List"&gt;

We are currently implementing a custom iCloud sync for our macOS and iOS apps using CloudKit. Syncing works fine as long as the number of record sends is relatively small. But when we test with a large number of changes ( 80,000+ CKRecords ) we start running into problems. Our sending strategy is very conservative to avoid rate limits: We send records sequentially in batches of 250 records With about 2 seconds pause between operations Records are small and contain no assets (assets are uploaded separately) At some point we start receiving: “Database commit size exceeds limit” After that, CloudKit begins returning rate-limit errors with retryAfter-Information in the error. We wait for the retry time and try again, but from this moment on, nothing progresses anymore. Every subsequent attempt fails. We could not find anything in the official documentation regarding such a “commit size” limit or what triggers this failure state. So my questions are: Are there undocumented limits on the total number of records that can exist in an iCloud database (private or shared)? Is there a maximum volume of record modifications a container can accept within a certain timeframe, even if operations are split into small batches with pauses? Is it possible that sending large numbers of records in a row can temporarily or permanently “stall” a CloudKit container? Any insights or experiences would be greatly appreciated. Thank you!

My Code: let op = CKModifyRecordsOperation(recordIDsToDelete:recordIDsToDelete) op.modifyRecordsCompletionBlock = { _, deleteRecordIDs, error in if error == nil { print("successful delete deleteRecordIDS = \(deleteRecordIDs)") } else { print("delete error = \(error?.localizedDescription)") } } op.database = CKContainer.default().privateCloudDatabase op.qualityOfService = .userInitiated CKContainer.default().privateCloudDatabase.add(op) My problem is that CKRecord are not deleted once I reinstall the app: when I reinstall the app and try to delete a CloudKit record, the method is executed successfully (error is nil) but the records are still in CloudKit Dashboards.

Description: I'm experiencing a critical issue with SwiftData custom migrations where objects created during migration appear to be inserted successfully but aren't persisted or found by queries after migration completes. The migration logs show objects being created, but subsequent queries return zero results. Problem Details: I'm migrating from schema version V2 to V3, which involves: Renaming Person class to GroupData Keeping the same data structure but changing the class name Using a custom migration stage to copy data from old to new schema Migration Code: swift static let migrationV2toV3 = MigrationStage.custom( fromVersion: LinkMapV2.self, toVersion: LinkMapV3.self, willMigrate: { context in do { let persons = try context.fetch(FetchDescriptor<LinkMapV2.Person>()) print("Found (persons.count) Person objects to migrate") // ✅ Shows 11 objects for person in persons { let newGroup = LinkMapV3.GroupData( id: person.id, // Same UUID name: person.name, // ... other properties ) context.insert(newGroup) print("Inserted GroupData: '\(newGroup.name)'") // ✅ Confirms insertion } try context.save() // ✅ No error thrown print("Successfully migrated \(persons.count) objects") // ✅ Confirms save } catch { print("Migration error: \(error)") } }, didMigrate: { context in do { let groups = try context.fetch(FetchDescriptor<LinkMapV3.GroupData>()) print("Final GroupData count: \(groups.count)") // ❌ Shows 0 objects! } catch { print("Verification error: \(error)") } } ) Console Output: text === MIGRATION STARTED === Found 11 Person objects to migrate Migrating Person: 'Riverside of pipewall' with ID: 7A08C633-4467-4F52-AF0B-579545BA88D0 Inserted new GroupData: 'Riverside of pipewall' ... (all 11 objects processed) ... === MIGRATION COMPLETED === Successfully migrated 11 Person objects to GroupData === MIGRATION VERIFICATION === New GroupData count: 0 // ❌ PROBLEM: No objects found! What I've Tried: Multiple context approaches: Using the provided migration context Creating a new background context with ModelContext(context.container) Using context.performAndWait for thread safety Different save strategies: Calling try context.save() after insertions Letting SwiftData handle saving automatically Multiple save calls at different points Verification methods: Checking in didMigrate closure Checking in app's ContentView after migration completes Using both @Query and manual FetchDescriptor Schema variations: Direct V2→V3 migration Intermediate V2.5 schema with both classes Lightweight migration with @Attribute(originalName:) Current Behavior: Migration runs without errors Objects appear to be inserted successfully context.save() completes without throwing errors But queries in didMigrate and post-migration return empty results The objects seem to exist in a temporary state that doesn't persist Expected Behavior: Objects created during migration should be persisted and queryable Post-migration queries should return the migrated objects Data should be available in the main app after migration completes Environment: Xcode 16.0+ iOS 18.0+ SwiftData Swift 6.0+ Key Questions: Is there a specific way migration contexts should be handled for data to persist? Are there known issues with object persistence in custom migrations? Should we be using a different approach for class renaming migrations? Is there a way to verify that objects are actually being written to the persistent store? The migration appears to work perfectly until the verification step, where all created objects seem to vanish. Any guidance would be greatly appreciated! Additional Context from my investigation: I've noticed these warning messages during migration that might be relevant: text SwiftData.ModelContext: Unbinding from the main queue. This context was instantiated on the main queue but is being used off it. error: Persistent History (76) has to be truncated due to the following entities being removed: (Person) This suggests there might be threading or context lifecycle issues affecting persistence. Let me know if you need any additional information about my setup or migration configuration!

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 work on an app that saves data to the Documents folder in the users iCloud Drive. This uses the iCloud -> iCloud Documents capability with a standard container. We've noticed an issue where a user will delete the apps data by doing to Settings > {Name} > iCloud > Storage > App Name > select "delete data from iCloud", and then our app can no longer write to or create the Documents folder. Once that happens, we get this error: Error Domain=NSCocoaErrorDomain Code=513 "You don't have permission to save the file "Documents" in the folder "iCloud~your~bundle~identifier"." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/iCloud~your~bundle~identifier/Documents, NSURL=file:///private/var/mobile/Library/Mobile%20Documents/iCloud~your~bundle~identifier/Documents, NSUnderlyingError=0x1102c7ea0 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}} This is reproducible using the sample project here https://developer.apple.com/documentation/uikit/synchronizing-documents-in-the-icloud-environment. Steps to reproduce in that project: Tap the plus sign in the top right corner to create a new document Add a document name and tap "Save to Documents" Go to Settings > {Name} > iCloud > Storage > SimpleiCloudDocument App Name > select "delete data from iCloud" Reopen the app and repeat steps 1-2 Observe error on MainViewController+Document.swift:59 Deleting and reinstalling the app doesn't seem to help.

Hi all I have a problem with core data, where when a new user login that is different from the previous user i delete all of core data by using "destroyPersistentStore". Then i recreate the persistent store, this works when i am testing. When it does not work for one of my users when she test. I am not sure why this should not work, i have added the code i use to destroy the persistent store below. This code is run after login but before the view changes away from my login view. // Retrieves the shared `AppDelegate` instance guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else { return } appDelegate.destroyDataSyncBackground() // Get a reference to a NSPersistentStoreCoordinator let storeContainer = appDelegate.persistentContainer.persistentStoreCoordinator // Delete each existing persistent store for store in storeContainer.persistentStores { if let url = store.url { do { try storeContainer.destroyPersistentStore( at: url, ofType: store.type, options: nil ) } catch { print("Failed to deleted all") } } else { print("Failed to deleted all") } } // Re-create the persistent container appDelegate.persistentContainer = NSPersistentContainer( name: "CueToCue" // the name of // a .xcdatamodeld file ) // Calling loadPersistentStores will re-create the // persistent stores appDelegate.persistentContainer.loadPersistentStores { (store, error) in // Handle errors let description = NSPersistentStoreDescription() description.shouldMigrateStoreAutomatically = true description.shouldInferMappingModelAutomatically = true appDelegate.persistentContainer.persistentStoreDescriptions = [description] } // Reapply context configuration let viewContext = appDelegate.persistentContainer.viewContext viewContext.automaticallyMergesChangesFromParent = true viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy do { try viewContext.save() appDelegate.recreateDataSyncBackground() } catch { print("Debug: saving delete all failed.") } } The function "destroyDataSyncBackground" just set the my sync class to nil so stop any changes to core data while the code is running. The function "recreateDataSyncBackground" recreate the sync class so fetch, post and patch requests is made again.

Hi, I'm trying to sign in with Apple CloudKit. I'm using the following code: 'use client'; import { CLOUDKIT_CONSTANTS } from '@/constants/cloudkit'; import { setCloudKitConfigured } from '@/lib/cloudkitSingleton'; import { CloudKitStatic } from '@/types/cloudkit'; import Script from 'next/script'; declare global { interface Window { CloudKit: CloudKitStatic; } } export default function Home() { const initializeCloudKit = async () =&gt; { console.info('⭐️ initializeCloudKit - start'); // 古い認証情報を削除 try { // LocalStorageから古い認証情報を削除 const keysToRemove = []; for (let i = 0; i &lt; localStorage.length; i++) { const key = localStorage.key(i); if (key &amp;&amp; (key.includes('cloudkit') || key.includes('CloudKit'))) { keysToRemove.push(key); } } keysToRemove.forEach(key =&gt; localStorage.removeItem(key)); // SessionStorageからも削除 const sessionKeysToRemove = []; for (let i = 0; i &lt; sessionStorage.length; i++) { const key = sessionStorage.key(i); if (key &amp;&amp; (key.includes('cloudkit') || key.includes('CloudKit'))) { sessionKeysToRemove.push(key); } } sessionKeysToRemove.forEach(key =&gt; sessionStorage.removeItem(key)); console.log('古い認証情報を削除しました'); } catch (cleanupError) { console.warn('認証情報のクリーンアップ中にエラー:', cleanupError); } try { const cloudKit = window.CloudKit.configure({ containers: [ { containerIdentifier: 'XXXXXX', apiTokenAuth: { apiToken: 'XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX', persist: false, signInButton: { id: 'cloudkit-sign-in-button', theme: 'black', }, signOutButton: { id: 'cloudkit-sign-out-button', theme: 'black', }, }, environment: 'development', }, ], }); console.info('⭐️ cloudKit', cloudKit); setCloudKitConfigured(true); const container = cloudKit.getDefaultContainer(); console.info('⭐️ CloudKit configured, setting up auth...'); // 初期認証状態をチェック try { const initialUser = await container.setUpAuth(); console.info('⭐️ setUpAuth result:', initialUser); } catch (authError) { console.info('⭐️ setUpAuth error (expected for unauthenticated):', authError); } // CloudKitの標準コールバックも併用（念のため） try { container.whenUserSignsIn().then((userInfo: any) =&gt; { console.info('⭐️ CALLBACK: whenUserSignsIn fired!', userInfo); }); container.whenUserSignsOut().then(() =&gt; { console.info('⭐️ CALLBACK: whenUserSignsOut fired!'); }); } catch (callbackError) { console.info('⭐️ Callback setup error (non-critical):', callbackError); } console.info('⭐️ initializeCloudKit - completed'); } catch (error) { console.error('⭐️ Critical CloudKit initialization error:', error); } }; return ( &lt;&gt; &lt;Script src="https://cdn.apple-cloudkit.com/ck/2/cloudkit.js" strategy="afterInteractive" onLoad={() =&gt; { initializeCloudKit(); }} onError={error =&gt; { console.error('⭐️ CloudKit initialization error:', error); }} /&gt; &lt;div id="cloudkit-sign-in-button" /&gt; &lt;div id="cloudkit-sign-out-button" /&gt; &lt;/&gt; ); } In Chrome secret tab, I can sign in successfully. But in Chrome normal tab, I can't sign in. In normal tab, following error occurs on sign in button click: cloudkit.js:14 Uncaught (in promise) Error: UNKNOWN_ERROR cloudkit.js:14 GET https://api.apple-cloudkit.com/database/1/XXXXXX/XXXXXX/public/users/caller?ckjsBuildVersion=2420ProjectDev22&amp;ckjsVersion=2.6.4&amp;clientId=XXXXX-XXXXXXX-XXXX-XXXXX&amp; ckAPIToken=XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX 421 (Misdirected Request) I think, cloudkit instance has re-initialized when I click the sign in button only in normal tab. So I can't sign in. Do you have any idea what might be causing the error ? Thanks in advance for your help!

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

Hi everyone I would like to achieve having unidirectional relationships in my SwiftData project (which I believe is possible: https://developer.apple.com/documentation/updates/swiftdata?changes=_9) but I'm afraid I'm struggling to overcome the errors I'm experiencing. For example, I have the following models: @Model final class Quota { @Attribute(.unique) var id: UUID var allowance: Int @Relationship(inverse: nil) var fish: Fish init(id: UUID = UUID(), fish: Fish, allowance: Int) { self.id = id self.fish = fish self.allowance = allowance } } @Model final class Fish { @Attribute(.unique) var id: Int var name: String init(id: Int, name: String) { self.id = id, self.name = name } } However, when I attempt to save a quota as so: let quota: Quota = .init(fish: Fish(id: 2, name: "Salmon"), allowance: 50) modelContext?.insert(quota) try save() I keep getting the following error: SwiftData.DefaultStore save failed with error: Error Domain=NSCocoaErrorDomain Code=1570 "%{PROPERTY}@ is a required value." UserInfo={NSValidationErrorObject=<NSManagedObject: 0x600002217390> (entity: Fish; id: 0x83319d001151328d <x-coredata://C76A2A64-146E-432F-A565-319B5A2F23F5/Fish/p12>; data: { id = nil; }), NSLocalizedDescription=%{PROPERTY}@ is a required value., NSValidationErrorKey=id, NSValidationErrorValue=null} %{PROPERTY}@ is a required value. However, if I set up Quota and Fish with an inverse relationship then the data saves as expected, so I'm a little confused. Is there anyone out there who can provide some guidance as to why I'm seeing this error when I try to save a record in SwiftData with no inverse relationship? I do fully understand about unidirectional vs bidirectional relationships but I have a scenario where I need the relationship to be unidirectional. Also, as a side note, the Fish record already exists in my database, but if I delete it and try to save the record I still see this error. Thank you so much in advance for any help.

Hi. I'm hoping someone might be able to help us with an issue that's been affecting our standalone watchOS app for some time now. We've encountered consistent crashes on Apple Watch devices when the app enters the background while the device is offline (i.e., no Bluetooth and no Wi-Fi connection). Through extensive testing, we've isolated the problem to the use of NSPersistentCloudKitContainer. When we switch to NSPersistentContainer, the crashes no longer occur. Interestingly, this issue only affects our watchOS app. The same CloudKit-based persistence setup works reliably on our iOS and macOS apps, even when offline. This leads us to believe the issue may be specific to how NSPersistentCloudKitContainer behaves on watchOS when the device is disconnected from the network. We're targeting watchOS 10 and above. We're unsure if this is a misconfiguration on our end or a potential system-level issue, and we would greatly appreciate any insight or guidance.

Hello, I have a iOS app I was looking at porting to Mac. I'm having an issue with both the Mac (Designed for iPad) and Mac Catalyst Destinations. I can't test Mac due to too many build issues. I'm trying to assign a new NSManagedObject into a NSPersistentStore. let object = MyObject(context: context) context.assign(object, to: nsPersistentStore) This works fine for iOS/iOS Simulator/iPhone/iPad. But on the Mac it's crashing with FAULT: NSInvalidArgumentException: Can't assign an object to a store that does not contain the object's entity.; { Thread 1: "Can't assign an object to a store that does not contain the object's entity."