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

I'm developing an app that uses CloudKit synchronization with SwiftData and on visionOS I added an App Settings bundle. I have noticed that sometimes, when the app is open and the user changes a setting from the App Settings bundle, the following fatal error occurs: SwiftData/BackingData.swift:831: Fatal error: This model instance was destroyed by calling ModelContext.reset and is no longer usable. The setting is read within the App struct in the visionOS app target using @AppStorage and this value is in turn used to set the passthrough video dimming via the .preferredSurroundingsEffect modifier. The setting allows the user to specify the dimming level as dark, semi dark, or ultra dark. The fatal error appears to occur intermittently although the first time it was observed was after adding the settings bundle. As such, I suspect there is some connection between those code changes and this fatal error even though they do not directly relate to SwiftData.

If use a SortDescriptor for a model and sort by some attribute from a relationship, in DEBUG mode it all works fine and sorts. However, in release mode, it is an instant crash. SortDescriptor(.name, order: .reverse) ---- works SortDescriptor(.assignedUser?.name, order: .reverse) ---- works in debug but crash in release. What is the issue here, is it that SwiftData just incompetent to do this?

Hello everyone, I am experiencing a persistent authentication error when querying a custom user profile record, and the error message seems to be a red herring. My Setup: I have a custom CKRecord type called ColaboradorProfile. When a new user signs up, I create this record and store their hashed password, salt, nickname, and a custom field called loginIdentifier (which is just their lowercase username). In the CloudKit Dashboard, I have manually added an index for loginIdentifier and set it to Queryable and Searchable. I have deployed this schema to Production. The Problem: During login, I run an async function to find the user's profile using this indexed loginIdentifier. Here is the relevant authentication code: func autenticar() async { // ... setup code (isLoading, etc.) let lowercasedUsername = username.lowercased() // My predicate ONLY filters on 'loginIdentifier' let predicate = NSPredicate(format: "loginIdentifier == %@", lowercasedUsername) let query = CKQuery(recordType: "ColaboradorProfile", predicate: predicate) // I only need these specific keys let desiredKeys = ["password", "passwordSalt", "nickname", "isAdmin", "isSubAdmin", "username"] let database = CKContainer.default().publicCloudDatabase do { // This is the line that throws the error let result = try await database.records(matching: query, desiredKeys: desiredKeys, resultsLimit: 1) // ... (rest of the password verification logic) } catch { // The error always lands here logDebug("Error authenticating with CloudKit: \(error.localizedDescription)") await MainActor.run { self.errorMessage = "Connection Error: \(error.localizedDescription)" self.isLoading = false self.showAlert = true } } } The Error: Even though my query predicate only references loginIdentifier, the catch block consistently reports this error: Error authenticating with CloudKit: Field 'createdBy' is not marked queryable. I know createdBy (the system creatorUserRecordID) is not queryable by default, but my query isn't touching that field. I already tried indexing createdBy just in case, but the error persists. It seems CloudKit cannot find or use my index for loginIdentifier and is incorrectly reporting a fallback error related to a system field. Has anyone seen this behavior? Why would CloudKit report an error about createdBy when the query is explicitly on an indexed, custom field? I'm new to Swift and I'm struggling quite a bit. Thank you,

I've noticed that SwiftData's @Relationship seems to potentially cause application crashes. The crash error is shown in the image. Since this crash appears to be random and I cannot reproduce it under specific circumstances, I can only temporarily highlight that this issue seems to exist. @Model final class TrainInfo { @Relationship(deleteRule: .cascade, inverse: \StopStation.trainInfo) var stations: [StopStation]? } @Model final class StopStation { @Relationship var trainInfo: TrainInfo? } /// some View var origin: StopStationDisplayable? { if let train = train as? TrainInfo { return train.stations?.first(where: { $0.isOrigin }) ?? train.stations?.first(where: { $0.isStarting }) } return nil } // Some other function or property func someFunction() { if let origin, let destination { // Function implementation } }

So i created an App and for some time it was working fine. The app has features to show pdf to users without logging in. I needed to upload all data to cloudkit on public database. I was not having knowledge that there are 2 mode being a noob in coding so after i saved all records in development mode in cloudkit when i published my app, i was not able to see them (Reason because live mode works in Production mode). So i need help now to transfer data from development mode to production mode or any app or code that can help me upload all data in production mode.

I am working with SwiftData and get the below error. I can't find any documentation on it to see what to fix. Any help would be appreciated. Fatal error: This relationship already has a value but it's not the target:

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..."

I have made a Swift App for MacOS 15 under XCode 16.3, which runs fine. I also want to run it under the previous MacOS 14. Unfortunately it crashes without even starting up (it does not even reach the first log output statement on the first view) The crash reason is Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [2970] I have set the miminium deployment to MacOS 14.0 but to no effect. The XCode machine is a MacOS 15.4 on Arm M3 and the target machine is MacOS 14.7.5 on Intel (MacBook Air) I think it might be related to the compiler and linker settings.

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!

We're in the process of migrating our app to the Swift 6 language mode. I have hit a road block that I cannot wrap my head around, and it concerns Core Data and how we work with NSManagedObject instances. Greatly simplied, our Core Data stack looks like this: class CoreDataStack { private let persistentContainer: NSPersistentContainer var viewContext: NSManagedObjectContext { persistentContainer.viewContext } } For accessing the database, we provide Controller classes such as e.g. class PersonController { private let coreDataStack: CoreDataStack func fetchPerson(byName name: String) async throws -> Person? { try await coreDataStack.viewContext.perform { let fetchRequest = NSFetchRequest<Person>() fetchRequest.predicate = NSPredicate(format: "name == %@", name) return try fetchRequest.execute().first } } } Our view controllers use such controllers to fetch objects and populate their UI with it: class MyViewController: UIViewController { private let chatController: PersonController private let ageLabel: UILabel func populateAgeLabel(name: String) { Task { let person = try? await chatController.fetchPerson(byName: name) ageLabel.text = "\(person?.age ?? 0)" } } } This works very well, and there are no concurrency problems since the managed objects are fetched from the view context and accessed only in the main thread. When turning on Swift 6 language mode, however, the compiler complains about the line calling the controller method: Non-sendable result type 'Person?' cannot be sent from nonisolated context in call to instance method 'fetchPerson(byName:)' Ok, fair enough, NSManagedObject is not Sendable. No biggie, just add @MainActor to the controller method, so it can be called from view controllers which are also main actor. However, now the compiler shows the same error at the controller method calling viewContext.perform: Non-sendable result type 'Person?' cannot be sent from nonisolated context in call to instance method 'perform(schedule:_:)' And now I'm stumped. Does this mean NSManageObject instances cannot even be returned from calls to NSManagedObjectContext.perform? Ever? Even though in this case, @MainActor matches the context's actor isolation (since it's the view context)? Of course, in this simple example the controller method could just return the age directly, and more complex scenarios could return Sendable data structures that are instantiated inside the perform closure. But is that really the only legal solution? That would mean a huge refactoring challenge for our app, since we use NSManageObject instances fetched from the view context everywhere. That's what the view context is for, right? tl;dr: is it possible to return NSManagedObject instances fetched from the view context with Swift 6 strict concurrency enabled, and if so how?

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.

In a document based SwiftData app for macOS, how do you go about opening a (modal) child window connected to the ModelContainer of the currently open document? Using .sheet() does not really result in a good UX, as the appearing view lacks the standard window toolbar. Using a separate WindowGroup with an argument would achieve the desired UX. However, as WindowGroup arguments need to be Hashable and Codable, there is no way to pass a ModelContainer or a ModelContext there: WindowGroup(id: "myWindowGroup", for: MyWindowGroupArguments.self) { $args in ViewThatOpensInAWindow(args: args) } Is there any other way?

Apple's iCloud File Management documentation says to "avoid special punctuation or other special characters" in filenames, but doesn't specify which characters. I need a definitive list to implement filename sanitization in my shipping app. Confirmed issues Our iOS app (CyberTuner, App Store, 15 years shipping on App Store) manages .rcta files in the iCloud ubiquity container via NSFileManager APIs. We've confirmed two characters causing sync failures: Ampersand (&): A file named Yamaha CP70 & CP80.rcta caused repeated "couldn't be backed up" dialogs. ~12 users reported this independently. Replacing & resolved it immediately. No other files in the same directory were affected. Percent (%): A file with % in the filename was duplicated by iCloud sync (e.g., filename% 1.rcta, filename% 2.rcta), and the original was lost. Currently reproducing across multiple devices. Both characters have special meaning in URL encoding (% is the escape character, & is the query parameter separator), which suggests the issue may be in URL handling within the sync pipeline. What I'm looking for: A definitive list of characters that cause problems in the iCloud sync pipeline specifically — not APFS restrictions, but CloudDocs/FileProvider/server-side issues. Confirmation whether these characters are problematic: & % # ? + / : * " < > | Is there a system API for validating or sanitizing filenames for iCloud compatibility before writing to the ubiquity container? Our users are piano technicians who naturally name files "Steinway & Sons" — we need to know exactly what to sanitize rather than guessing. Environment: iOS 17–26, Xcode 26.1, APFS, NSFileManager ubiquity container APIs Bundle FEEDBACK ASSISTANT ID FB21900837

I am implementing a custom migration, and facing an issue while implementing a WAL checkpointing. Here is the code for WAL checkpointing func forceWALCheckpointingForStore(at storeURL: URL, model: NSManagedObjectModel) throws { let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: model) let options = [NSSQLitePragmasOption: ["journal_mode": "DELETE"]] let store = try persistentStoreCoordinator.addPersistentStore(type: .sqlite, at: storeURL, options: options) try persistentStoreCoordinator.remove(store) } When the coordinator tries to add the store I am getting the following error fault: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store My questions are Is it really necessary to force WAL checkpointing before migration? I am expecting NSMigrationManager to handle it internally. I am assuming this because the migrateStore function asks for the sourceType where I am passing StoreType.sqlite If checkpointing is required, then how do I address the original issue Note: Since my app supports macOS 13, I am not able to use the newly introduced Staged migrations. There is similar question on Stackoverflow that remains unanswered. https://stackoverflow.com/q/69131577/1311902

Hi everyone, Im trying to set up CloudKit for my Unreal Engine 5.4 project but seem to be hitting some roadblocks on how to set up the Record Types. From my understanding I need to set up a "file" record type with a "contents" asset field - but even with this it doesn't seem to work :( Any unreal engine devs with some experience on this who could help me out? Thanks!

I’m seeing an issue with CloudKit sharing in iOS 26.2.1: When I call CKShare(rootRecord:) with a brand-new record in a fresh custom zone, the share is created with no root attached (rootFromShare == nil). After saving both the root and share in a single CKModifyRecordsOperation, fetching the share from the server still shows no root reference (rootRecordID == nil). No errors are thrown, but sharing simply fails. Key facts: • Custom zone created and confirmed (sharing enabled, capsRaw=7/15) • Brand-new record type and fresh IDs each run • Never reusing records or shares • Saving both root and share together in one operation • No default zone usage; always custom private zone Tested: • Multiple devices, iCloud accounts, and app versions • Both simulator and physical device Debug logs consistently show: • SHARE_CREATE_SHARE_LOCAL ... rootFromShare=nil • After save/fetch: rootRecordID=nil on server Has anyone seen this? Is there a new CloudKit regression in iOS 26.x, or am I missing something subtle? Minimal sample project and full debug logs available if needed. Any insights or workarounds would be hugely appreciated!

Greetings my fellow engineers, I use SwiftData in my iOS app. The schema is unversioned and consists of a single model. I've been modifying the model for almost two years now and relying on automatic database migrations. I had no problems for all that time, but now trying to add a property to the model or even remove a property from the model results in an error which seems like SwiftData is no longer capable of performing an automatic migration. The log console has things like the following: CoreData: error: NSUnderlyingError : Error Domain=NSCocoaErrorDomain Code=134190 "(null)" UserInfo={reason=Each property must have a unique renaming identifier} CoreData: error: reason : Can't find or automatically infer mapping model for migration CoreData: error: storeType: SQLite CoreData: error: configuration: default CoreData: annotation: options: CoreData: annotation: NSMigratePersistentStoresAutomaticallyOption : 1 CoreData: annotation: NSInferMappingModelAutomaticallyOption : 1 CoreData: annotation: NSPersistentStoreRemoteChangeNotificationOptionKey : 1 CoreData: annotation: NSPersistentHistoryTrackingKey : 1 CoreData: error: <NSPersistentStoreCoordinator: 0x7547b5480>: Attempting recovery from error encountered during addPersistentStore: 0x753f8d800 Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model." Have you ever encountered such an issue? What are my options?

Hello everyone, I'm trying to adopt the new Staged Migrations for Core Data and I keep running into an error that I haven't been able to resolve. The error messages are as follows: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'Movie' so +entity is unable to disambiguate. warning: 'Movie' (0x60000350d6b0) from NSManagedObjectModel (0x60000213a8a0) claims 'Movie'. error: +[Movie entity] Failed to find a unique match for an NSEntityDescription to a managed object subclass This happens for all of my entities when they are added/fetched. Movie is an abstract entity subclass, and it has the error error: +[Movie entity] Failed to find which is unique to the subclass entities, but this occurs for all entities. The NSPersistentContainer is loaded only once, and I set the following option after it's loaded: storeDescription.setOption( [stages], forKey: NSPersistentStoreStagedMigrationManagerOptionKey ) The warnings and errors only appear after I fetch or save to context. It happens regardless of whether the database was migrated or not. In my test project, using the generic NSManagedObject with NSEntityDescription.insertNewObject(forEntityName: "MyEntity", into: context) does not cause the issue. However, using the generic NSManagedObject is not a viable option for my app. Setting the module to "Current Project Module" doesn't change anything, except that it now prints "claims 'MyModule.Show'" in the warnings. I have verified that there are no other entities with the same name or renameIdentifier. Has anyone else encountered this issue, or can offer any suggestions on how to resolve it? Thanks in advance for any help!

Hi all, I am using SwiftData and cloudkit and I am having an extremely persistent bug. I am building an education section on a app that's populated with lessons via a local JSON file. I don't need this lesson data to sync to cloudkit as the lessons are static, just need them imported into swiftdata so I've tried to use the modelcontainer like this: static func createSharedModelContainer() -> ModelContainer { // --- Define Model Groups --- let localOnlyModels: [any PersistentModel.Type] = [ Lesson.self, MiniLesson.self, Quiz.self, Question.self ] let cloudKitSyncModels: [any PersistentModel.Type] = [ User.self, DailyTip.self, UserSubscription.self, UserEducationProgress.self // User progress syncs ] However, what happens is that I still get Lesson and MiniLesson record types on cloudkit and for some reason as well, whenever I update the data models or delete and reinstall the app on simulator, the lessons duplicate (what seems to happen is that a set of lessons comes from the JSON file as it should), and then 1-2 seconds later, an older set of lessons gets synced from cloudkit. I can delete the old set of lessons if I just delete the lessons and mini lessons record types, but if I update the data model again, this error reccurrs. Sorry, I don't know if I managed to explain this well but essentially I just want to stop the lessons and minilessons from being uploaded to cloudkit as I think this will fix the problem. Am I doing something wrong with the code?