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.

I am developing an app that uses CloudKit sharing. I recently upgraded my iPad to use 23A5336a. After that upgrade, I can no longer accept a share that is sent to me. I have rebooted the iPad and logged out of the iCloud account and logged back in. Every time I get a share link and tap it, it says: " The owner stopped sharing or your account (xxx) doesn't have permission to open it" This same code, running on the iOS26 device can share with device running iOS18. Is this a known defect? Anything I can do to help resolve this issue?

Hi, I'm considering using the new SwiftData class inheritance for a new app I'm building. I have a few questions: Is it working well enough for production? I have a number of different object types in my app. Some of them are very similar, and there's always a balance to be struck when it comes to splitting them into different types using class inheritance. Are there some good advice on when to use multiple classes instead of squeezing my object types into a single class? Is there advice against using class inheritance in multiple levels (3-4)? Claes

Hello, I apologize if this post could be slightly out of forum topic but I have one issue that I cannot solve. I tried a few times to call Apple support but the only indication that have given to me is to try with this forum. The issue I have is simple. Sometimes the modifications performed on iCloud Drive on one computer are not properly synced between the local folder /Users/[username]/Library/Mobile Documents/... and the cloud and therefore are not shared across all devices that use the same iCloud Drive. This is very disturbing as it may lead to a data loss. I would like to write a simple software that activates the iCloud Drive sync between the local iCloud folder /Users/[username]/Library/Mobile Documents/... and the Cloud. A simple macOS bash script would be fine but also other pieces of software are welcome. Can anyone please help me? Thanks! Daniele

Hello Devs, I'm encountering a persistent INTERNAL_ERROR (HTTP 500) when making Server-to-Server API calls to CloudKit, specifically when trying to hit the /users/current endpoint, even after meticulously verifying all client-side components. I'm hoping someone might have insight into what could cause this. Context: Goal: Authenticate to CloudKit from a Vercel Serverless Function (Node.js) to perform operations like record queries. Problem Endpoint: POST https://api.apple-cloudkit.com/database/1/iCloud.com.dannybaseball.Danny-Baseball/production/public/users/current Key Generation Method: Using the CloudKit Dashboard's "Tokens & Keys" -> "New Server-to-Server Key" flow, where I generate the private key using openssl ecparam -name prime256v1 -genkey -noout -out mykey.pem, then extract the public key using openssl ec -in mykey.pem -pubout, and paste the public key material (between BEGIN/END markers) into the dashboard. The private key was then converted to PKCS#8 format using openssl pkcs8 -topk8 -nocrypt -in mykey.pem -out mykey_pkcs8.pem. Current Setup Being Tested (in a Vercel Node.js function): CLOUDKIT_CONTAINER: iCloud.com.dannybaseball.Danny-Baseball CLOUDKIT_KEY_ID: 9368dddf141ce9bc0da743b9f69bc3eda132b9bb3e62a4167e428d4f320b656e (This is the Key ID generated from the CloudKit Dashboard for the public key I provided). CLOUDKIT_P8_KEY (Environment Variable): Contains the base64 encoded string of the entire content of my PKCS#8 formatted private key file. Key Processing in Code: const p8Base64 = process.env.CLOUDKIT_P8_KEY; const privateKeyPEM = Buffer.from(p8Base64, 'base64').toString('utf8'); // This privateKeyPEM string starts with "-----BEGIN PRIVATE KEY-----" and ends with "-----END PRIVATE KEY-----" const privateKey = crypto.createPrivateKey({ key: privateKeyPEM, format: 'pem' }); // This line SUCCEEDS without DECODER errors in my Vercel function logs. Use code with caution. JavaScript Request Body for /users/current: "{}" Signing String (message = Date:BodyHash:Path): Date: Correct ISO8601 format (e.g., "2025-05-21T19:38:11.886Z") BodyHash: Correct SHA256 hash of "{}", then Base64 encoded (e.g., "RBNvo1WzZ4oRRq0W9+hknpT7T8If536DEMBg9hyq/4o=") Path: Exactly /database/1/iCloud.com.dannybaseball.Danny-Baseball/production/public/users/current Headers: X-Apple-CloudKit-Request-KeyID: Set to the correct Key ID. X-Apple-CloudKit-Request-ISO8601Date: Set to the date used in the signature. X-Apple-CloudKit-Request-SignatureV1: Set to the generated signature. X-Apple-CloudKit-Environment: "production" Content-Type: "application/json" Observed Behavior & Logs: The Node.js crypto.createPrivateKey call successfully parses the decoded PEM key in my Vercel function. The request is sent to CloudKit. CloudKit responds with HTTP 500 and the following JSON body (UUID varies per request): { "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "serverErrorCode": "INTERNAL_ERROR" } Use code with caution. Json This happens consistently. Previously, with other key pairs or different P8 processing attempts, I was getting AUTHENTICATION_FAILED (401) or local DECODER errors. Now that the key parsing is successful on my end with this current key pair and setup, I'm hitting this INTERNAL_ERROR. Troubleshooting Done: Verified Key ID (9368dddf...) is correct and corresponds to the key generated via CloudKit Dashboard. Verified Container ID (iCloud.com.dannybaseball.Danny-Baseball) is correct. Successfully parsed the private key from the environment variable (after base64 decoding) within the Vercel function. Meticulously checked the signing string components (Date, BodyHash, Path) against Apple's documentation. Path format is /database/1////. Ensured all required headers are present with correct values. Local Node.js tests (bypassing Vercel but using the same key data and signing logic) also result in this INTERNAL_ERROR. Question: What could cause CloudKit to return an INTERNAL_ERROR (500) for a /users/current request when the client-side key parsing is successful and all request components (path, body hash for signature, date, headers) appear to conform exactly to the Server-to-Server Web Services Reference? Are there any known subtle issues with EC keys generated via openssl ecparam (and then converted to PKCS#8) that might lead to this, even if crypto.createPrivateKey parses them in Node.js? Could there be an issue with my specific Key ID or container that would manifest this way, requiring Apple intervention? Any insights or suggestions would be greatly appreciated. I can provide more detailed logs of the request components if needed. Thank you!

Am I misunderstanding the expected behavior here, or is there a bug in the behavior of @Attribute(.ephemeral) tagged SwiftData model properties? The documentation for .ephemeral says "Track changes to this property but do not persist". I started using .ephemeral because @Transient was inhibiting SwiftUI from reacting to changes to the property through @Observable. I am updating the value of my @Attribute(.ephemeral) property about once a second and I am seeing corresponding console log output showing the property as part of the generated CKRecord object. I then confirmed in the CloudKit dev portal that the .ephemeral property was added to the Record schema and contains real values. The behavior seems as though the .ephemeral property is being completely ignored. This is observed in a new Xcode project using SwiftData with CloudKit, Xcode 16.2, macOS 15.3.1 and during Build & Run testing on physical devices.

If Cloudkit is enabled, SwiftData @Query operation hangs when the View scenePhase becomes active. Seems like the more @Query calls you have, the more it hangs. This has been first documented some time ago, but in typical Apple style, it has not been addressed or even commented on. https://developer.apple.com/forums/thread/761434

I have a widely-used app that lets users keep track of personal data. This data is persisted with SwiftData, and synced with CloudKit. I understand that if the user's iCloud account changes on a device (for example, user logs out or toggles off an app's access to iCloud), then NSPersistentCloudKitContainer will erase the local data records on app launch. This is intentional behavior, intended as a privacy feature. However, we are receiving regular reports from users for whom the system has incorrectly indicated that the app's access to iCloud is unavailable, even when the user hasn't logged out or toggled off permission to access iCloud. This triggers the behavior to clear the local records, and even though the data is still available in iCloud, to the user, it looks like their data has disappeared for no reason. Helping the user find and troubleshoot their iCloud app data settings can be very difficult, since in many cases the user has no idea what iCloud is, and we can't link them directly to the correct settings screen. We seem to get these reports most frequently from users whose iCloud storage is full (which feels like punishment for not paying for additional storage), but we've also received reports from users who have enough storage space available (and are logged in and have the app's iCloud data permissions toggled on). It appears to happen randomly, as far as we can tell. I found a blog post from two years ago from another app developer who encountered the same issue: https://crunchybagel.com/nspersistentcloudkitcontainer/#:~:text=The%20problem%20we%20were%20experiencing To work around this and improve the user experience, we want to use CKContainer.accountStatus to check if the user has an available iCloud account, and if not, disable the CloudKit sync before it erases the local data. I've found steps to accomplish this workaround using CoreData, but I'm not sure how to best modify the ModelContainer's configuration after receiving the CKAccountStatus when using SwiftData. I've put together this approach so far; is this the right way to handle disabling/enabling sync based on account status? import SwiftUI import SwiftData import CloudKit @main struct AccountStatusTestApp: App { @State private var modelContainer: ModelContainer? var body: some Scene { WindowGroup { if let modelContainer { ContentView() .modelContainer(modelContainer) } else { ProgressView("Loading...") .task { await initializeModelContainer() } } } } func initializeModelContainer() async { let schema = Schema([ Item.self, ]) do { let accountStatus = try await CKContainer.default().accountStatus() let modelConfiguration = ModelConfiguration( schema: schema, cloudKitDatabase: accountStatus == .available ? .private("iCloud.com.AccountStatusTestApp") : .none ) do { let container = try ModelContainer(for: schema, configurations: [modelConfiguration]) modelContainer = container } catch { print("Could not create ModelContainer: \(error)") } } catch { print("Could not determine iCloud account status: \(error)") } } } I understand that bypassing the clearing of local data when the iCloud account is "unavailable" introduces possible issues with data being mingled on shared devices, but I plan to mitigate that with warning messages when users are in this state. This would be a far more preferable user experience than what's happening now.

I'm having some issues where only a subset of records appear in CloudKit dashboard after I have saved some records in my iOS app using NSPersistentCloudKitContainer. I have noticed that when I'm running my app using the development environment of my CloudKit container everything works smoothly and is uploaded as expected but when I'm using the production environment only a subset of records are actually uploaded. I'm pulling my hair on how to debug this. -com.apple.CoreData.CloudKitDebug and -com.apple.CoreData.SQLDebug pukes out too much info in the console for me to pinpoint any issue.

I'm implementing SwiftData with inheritance in an app. I have an Entity class with a property name. This class is inherited by two other classes: Store and Person. The Entity model has a one-to-many relationship with a Transaction class. I can list all my Entity models in a List with a @Query annotation without a problem. However, then I try to access the name property of an Entity from a Transaction relationship, the app crashes with the following error: Thread 1: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x96530ce28d41eb63 <x-coredata://DABFF7BB-C412-474E-AD50-A1F30AC6DBE9/Person/p4>))) with Optional(F07E7E23-F8F0-4CC0-B282-270B5EDDC7F3) From my attempts to fix the issue, I noticed that: The crash seems related to the relationships with classes that has inherit from another class, since it only happens there. When I create new data, I can usually access it without any problem. The crash mostly happens after reloading the app. This error has been mentioned on the forum (for example here), but in a context not related with inheritance. You can find the full code here. For reference, my models looks like this: @Model class Transaction { @Attribute(.unique) var id: String var name: String var date: Date var amount: Double var entity: Entity? var store: Store? { entity as? Store } var person: Person? { entity as? Person } init( id: String = UUID().uuidString, name: String, amount: Double, date: Date = .now, entity: Entity? = nil, ) { self.id = id self.name = name self.amount = amount self.date = date self.entity = entity } } @Model class Entity: Identifiable { @Attribute(.preserveValueOnDeletion) var name: String var lastUsedAt: Date @Relationship(deleteRule: .cascade, inverse: \Transaction.entity) var operations: [Transaction] init( name: String, lastUsedAt: Date = .now, operations: [Transaction] = [], ) { self.name = name self.lastUsedAt = lastUsedAt self.operations = operations } } @available(iOS 26, *) @Model class Store: Entity { @Attribute(.unique) var id: String var locations: [Location] init( id: String = UUID().uuidString, name: String, lastUsedAt: Date = .now, locations: [Location] = [], operations: [Transaction] = [] ) { self.locations = locations self.id = id super.init(name: name, lastUsedAt: lastUsedAt, operations: operations) } } In order to reproduce the error: Run the app in the simulator. Click the + button to create a new transaction. Relaunch the app, then click on any transaction. The app crashes when it tries to read te name property while building the details view.

CloudKit CKRecordZone Deletion Issue Problem: CloudKit record zones deleted via CKDatabase.modifyRecordZones(deleting:) or CKModifyRecordZonesOperation are successfully removed but then reappear. I suspect they are automatically reinstated by CloudKit sync, despite successful deletion confirmation. Environment: SwiftData with CloudKit integration Custom CloudKit zones created for legacy zone-based sharing Observed Behavior: Create custom zone (e.g., "TestZone1") via CKDatabase.modifyRecordZones(saving:) Copy records to zone for sharing purposes Delete zone using any CloudKit deletion API - returns success, no errors Immediate verification: Zone is gone from database.allRecordZones() After SwiftData/CloudKit sync or app restart: Zone reappears Reproduction: Tested with three different deletion methods - all exhibit same behaviour: modifyRecordZones(deleting:) async API CKModifyRecordZonesOperation (fire-and-forget) CKModifyRecordZonesOperation with result callbacks Zone deletion succeeds, change tokens (used to track updates to shared records) cleaned up But zones are restored presumably by CloudKit background sync Expected: Deleted zones should remain deleted Actual: Zones are reinstated, creating orphaned zones

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

Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great. The problem: Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups. When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one. Could not cast value of type 'Swift.Optional<Any>' (0x20a676be0) to 'Swift.Array<App.CodableStructModel>' (0x207a2bc08). Where CodableStructModel is a Codable Value type inside Item. Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is "supported" by SwiftData by default, meaning that the developer has to actively either wholly opt out of undo support in their modelContainer setup or do it on a per action scale with the only thing I know of: modelContext.processPendingChanges() modelContext.undoManager?.disableUndoRegistration() ..... modelContext.processPendingChanges() modelContext.undoManager?.enableUndoRegistration() General rant on SwiftData: Random crashes, inconsistencies, random cryptic errors thrown by the debugger and general lack of production level stability. Each update breaks something new and there is very little guidance and communication from the Swift Data team on how to adapt and more importantly consideration for developers that have adopted Swift Data. If SwiftData is not ready for production, it would go a long way to clearly communicate that and mark it as Beta product.

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;

I have an app which uses ubiquitous containers and files in them to share data between devices. It's a bit unusual in that it indexes files in directories the user grants access to, which may or may not exist on a second device - those files are identified by SHA-1 hash. So a second device scanning before iCloud data has fully sync'd can create duplicate references which lead to an unpleasant user experience. To solve this, I store a small binary index in the root of the ubiquitous file container of the shared data, containing all of the known hashes, and as the user proceeds through the onboarding process, a background thread is attempting to "prime" the ubiquitous container by calling FileManager.default.startDownloadingUbiquitousItemAt() for each expected folder and file in a sane order. This likely creates a situation not anticipated by the iOS/iCloud integration's design, as it means my app has a sort of precognition of files it should not yet know about. In the common case, it works, but there is a corner case where iCloud sync has just begun, and very, very little metadata is available (the common case, however, in an emulator), in which two issues come up: I/O may hang indefinitely, trying to read a file as it is arriving. This one I can work around by running the I/O in a thread created with the POSIX pthread_create and using pthread_cancel to kill it after a timeout. Attempts to call FileManager.default.startDownloadingUbiquitousItemAt() fails with an error Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it.". The permissions aspect of it is nonsense, but I can believe there's no applicable "sort of exists, sort of doesn't" error code to use and someone punted. The problem is that this same error will be thrown on any attempt to access that file for the life of the application - a restart is required to make it usable. Clearly, the error or the hallucinated permission failure is cached somewhere in the bowels of iOS's FileManager. I was hoping startAccessingSecurityScopedResource() would allow me to bypass such a cache, as it does with URL.resourceValues() returning stale file sizes and last modified times. But it does not. Is there some way to clear this state without popping up a UI with an Exit button (not exactly the desired iOS user experience)?

I haven't been able to find a definitive answer to this online. Is NSUbiquitousKeyValueStore end-to-end encrypted with Advanced Data Protection turned on? It’s not specifically called out here https://support.apple.com/en-us/102651.

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?

Hi, I am testing a situation with shared CKRecords where the data in the CKRecord syncs fine, but the creatorUserRecordID.recordName and lastModifiedUserRecordID.recordName shows "defaultOwner" (which maps to the CKCurrentUserDefaultName constant) even though I made sure I edit the CKRecord value from a different iCloud account. In fact, on the CloudKit dashboard, it shows the correct user recordIDs in the metadata for the 'Created' and 'Modified' fields, but not in the CKRecord. I am mostly testing this on the iPhone simulator with the debugger attached. Is that a possible reason for this, or is there some other reason the lastModifiedUserRecordID is showing the value for 'CKCurrentUserDefaultName'? It would be pretty difficult to build in functionality to look up changes by a different userID if this is the case.

Hi, I am implementing a premium feature in my app where CloudKit syncing is available only for "Pro" users. The Workflow: Free Users: I initialize the ModelContainer with cloudKitDatabase: .none so their data stays local. Pro Upgrade: When a user purchases a subscription, I restart the container with cloudKitDatabase: .automatic to enable syncing. The Problem: If a user starts as "Free" (creates local data) and later upgrades to "Pro", the app crashes immediately upon launch with the following error: Fatal error: Failed to create ModelContainer: SwiftDataError(_error: SwiftData.SwiftDataError._Error.loadIssueModelContainer, _explanation: nil) It seems that SwiftData fails to load the existing data once the configuration changes to expect a CloudKit-backed store. My Question: Is there a supported way to "toggle" CloudKit on for an existing local dataset without causing this crash? I want the user's existing local data to start syncing once they pay, but currently, it just crashes. My code: import Foundation import SwiftData public enum DataModelEnum: String { case task, calendar public static let container: ModelContainer = { let isSyncEnabled = UserDefaults.isProUser let config = ModelConfiguration( groupContainer: .identifier("group.com.yourcompany.myApp"), cloudKitDatabase: isSyncEnabled ? .automatic : .none ) do { return try ModelContainer(for: TaskModel.self, CalendarModel.self, configurations: config) } catch { fatalError("Failed to create ModelContainer: \(error)") } }() }

Hi everyone, I am experiencing an iCloud provisioning problem I cannot resolve, and Developer Support has not been able to help. My App ID: com.exaqservices.ArkyvTiles Symptoms: 1. In Xcode (v16.2), enabling iCloud in Signing & Capabilities repeatedly fails with: The app ID does not include the iCloud container. Click Try Again. Clicking Try Again does nothing. The error persists forever. 2. In Certificates, Identifiers & Profiles: • The iCloud capability is enabled for this App ID. • The CloudKit container is selected. • But the portal no longer shows the “iCloud Documents” checkbox, which used to be required for ubiquitous document support. 3. Xcode cannot regenerate provisioning profiles because it claims the App ID is missing the iCloud container — even though the container is attached. 4. Provisioning profiles on the Apple Developer site all appear expired, and new ones do not generate correctly. 5. The App Store Connect interface also does not show an iCloud Services section under App Information → Capabilities as older guides describe. Expected Behavior: Since iCloud and the CloudKit container are enabled on the App ID, Xcode should successfully enable: • com.apple.developer.icloud-services • com.apple.developer.icloud-container-identifiers • com.apple.developer.ubiquity-container-identifiers (if needed) • com.apple.developer.ubiquity-kvstore-identifier Instead, the entitlements never propagate. What I suspect: This seems like an App ID metadata mismatch or a stale backend entry where: • the CloudKit container is attached but the entitlement isn’t linked, • the “iCloud Documents” flag is missing due to a UI transition, • provisioning profiles cannot be regenerated because the App ID is not updating correctly. What I need help with: Can someone from Apple engineering confirm: • Whether my App ID metadata is corrupted, • If entitlements need to be manually refreshed, • Or if the “iCloud Documents” toggle has moved or is no longer exposed? This is blocking development completely — I cannot build, sign, or deploy the app with iCloud. Thank you! Alan Metzger