Hi, A few of my apps will be able to sync with iCloud. So I do realize that we're not allowed to mention any Apple-related names in our app descriptions. Looking for ideas on how to state that the app works with iCloud without saying "iCloud." Thanks, Dan Uff

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.

According to this comment in the sample project on GitHub and this answer by Apple Staff, CKSyncEngine should be re-initialized after signing out or switching accounts so that "CKSyncEngine schedules a new fetch on init." But according to my tests, CKSyncEngine will schedule a fetch after having a signed out and signed in again, without me ever having to reset the serialized sync state. The documentation doesn't mentioned anywhere that CKSyncEngine should be re-initialized after an account change. In fact, it states that CKSyncEngine will reset its state internally on account changes. So if that's the case, then I'm very confused as to why the "official" recommendation is to re-initialize CKSyncEngine after receiving .signOut or .accountSwitch. Can someone please clarify the correct approach here?

Hi everyone, I have a SwiftUI app using CKQuerySubscription on the public database for social notifications (friend requests, recommendations, etc.). Push notifications work perfectly in the Development environment but never fire in Production (TestFlight). Setup: iOS 26.4, Xcode 26, Swift 6 Container: public database, CKQuerySubscription with .firesOnRecordCreation 5 subscriptions verified via CKDatabase.allSubscriptions() registerForRemoteNotifications() called unconditionally on every launch Valid APNS device token received in didRegisterForRemoteNotificationsWithDeviceToken Push Notifications + Background Modes (Remote notifications) capabilities enabled What works: All 5 subscriptions create successfully in Production Records are saved and queryable (in-app CloudKit fetches return them immediately) APNS production push works — tested via Xcode Push Notifications Console with the same device token, notification appeared instantly Everything works perfectly in the Development environment (subscriptions fire, push arrives) What doesn't work: When a record is created that matches a subscription predicate, no APNS push is ever delivered in Production Tested with records created from the app (device to device) and from CloudKit Dashboard — neither triggers push Tried: fresh subscription IDs, minimal NotificationInfo (just alertBody), stripped shouldSendContentAvailable, created an APNs key, toggled Push capability in Xcode, re-deployed schema from dev to prod Additional finding: One of my record types (CompletionNotification) was returning BAD_REQUEST when creating a subscription in Production, despite working in Development. Re-deploying the development schema to production (which reported "no changes") fixed the subscription creation. This suggests the production environment had inconsistent subscription state for that record type, possibly from the type being auto-created by a record save before formal schema deployment. I suspect a similar issue may be affecting the subscription-to-APNS pipeline for all my record types — the subscriptions exist and predicates match, but the production environment isn't wiring them to APNS delivery. Subscription creation code (simplified): let subscription = CKQuerySubscription( recordType: "FriendRequest", predicate: NSPredicate(format: "receiverID == %@ AND status == %@", userID, "pending"), subscriptionID: "fr-sub-v3", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.titleLocalizationKey = "Friend Request" info.alertLocalizationKey = "FRIEND_REQUEST_BODY" info.alertLocalizationArgs = ["senderUsername"] info.soundName = "default" info.shouldBadge = true info.desiredKeys = ["senderUsername", "senderID"] info.category = "FRIEND_REQUEST" subscription.notificationInfo = info try await database.save(subscription) Has anyone encountered this? Is there a way to "reset" the subscription-to-APNS pipeline for a production container? I'd really appreciate any guidance on how to resolve and get my push notifications back to normal. Many thanks, Dimitar - LaterRex

Good morning, I assume that coredata model changes are automatically created on the development cloudkit (CD_*) as that has been the behaviour in the past and than you deploy the schema changes to prod. I have a case were a new field in a existing table is not appearing in the dev cloudkit table is there a way to "force" it to show up? thanks in advance

Hi everyone, I've recently implemented CKSyncEngine in my app, and I have two questions regarding its behavior: Duplicate FetchedRecordZoneChanges After Sending Changes: I’ve noticed that the engine sometimes receives a FetchedRecordZoneChanges event containing modifications and deletions that were just sent by the same device a few moments earlier. This event arrives after the SentRecordZoneChanges event, and both events share the same recordChangeTag, which results in double-handling the record. Is this expected behavior? I’d like to confirm if this is how CKSyncEngine works or if I might be overlooking something. Handling Initial Sync with a "Sync Screen": When a user opens the app for the first time and already has data stored in iCloud, I need to display a "Sync Screen" temporarily to prevent showing partial data or triggering abrupt, rapid UI changes. I’ve found that canceling current operations, then awaiting sendChanges() and fetchChanges() works well to ensure data is fully synced before dismissing the sync screen: displaySyncScreen = true await syncEngine.cancelOperations() try await syncEngine.sendChanges() try await syncEngine.fetchChanges() displaySyncScreen = false However, I’m unsure if canceling operations like this could lead to data loss or other issues. Is this a safe approach, or would you recommend a better strategy for handling this initial sync state?

I am planning a Core Data migration for a macOS app targeting macOS 12 and later and I would appreciate guidance on structuring the rollout to minimise risk. Context The app currently uses a SQLite store located at: ~/Library/Containers/com.company.AppName/Data/Library/Application Support/AppName I want to: Relocate the persistent store to an app group container: ~/Library/Group Containers/group.com.company.AppName Perform schema migration, including: Renaming attributes Deleting attributes Using a custom NSEntityMigrationPolicy subclass Adopt iCloud sync using NSPersistentCloudKitContainer Potentially leverage staged migration (macOS 14+) Additionally, I intend to port the app to iOS, so the end state needs to support an app group container and CloudKit with the latest schema from the outset. Questions Store relocation vs schema migration Is it advisable to perform store relocation and schema migration in a single step, or should these be separate releases? If combined, are there pitfalls when moving the SQLite file and running a migration in the same launch cycle? Custom migration policy Any best practices for structuring NSEntityMigrationPolicy when also relocating the store? Should migration policies assume the store has already been moved, or handle both concerns? Staged migration (macOS 14+) Is staged migration worth adopting when still supporting macOS 12–13? Would you gate it conditionally, or avoid it entirely for consistency? CloudKit adoption Is introducing NSPersistentCloudKitContainer in the same release as the above migrations too risky? Are there known issues when enabling CloudKit immediately after a migration? Release strategy Would you recommend: A single release handling everything Two phases: (1) store & schema migration, (2) CloudKit Or three phases: store relocation → schema migration → CloudKit Goal I want a smooth, reliable transition without data loss or duplication, particularly for existing users with non-trivial datasets. Any insights, practical experience, or recommended sequencing strategies would be very helpful.

In an iOS App that uses CKShare I have a many-to-many relationship that does not consistently sync between the share's N participants. The relationship is between Group and Player as group.players and player.groups. As an example, given 3 group each with 4 players (aka 4:4:4), some devices show CoreData (it is NOT a UI issue) with 4:2:3 or 3:4:4. (A deletion of CoreData from a device, forcing a full re-sync from CloudKit, seems to populate the group:player relationships consistently; but obviously that is impractical to resolving the issue). How do I avoid these sync-from-CloudKit inconsistencies? Note: AI agents generally suggest adding a CoreData 'join' entity - such as 'GroupPlayer'. Is that THE fix?

Hi, I do have a strange behavior in my development environment on a Mac mini (M4) running 26.2 and Xcode 26.3. Everything was working as expected. My project had a stable state and I wanted to enable iCloud support. As result I could not run the app any more because code signing failed with the message that my profile does not include the above entitlement. On my notebook (M2) with XCode 26.3 everything is working. Im am using GIT and both computers have identical code. The code compiling and running on my notebook will not run any more on my Max mini. Any help to find what might have broken the code signing and how it could be fixed? Thanks in advance.

CloudKit: Efficient way to get user's rank in leaderboard without fetching all records? I'm building a leaderboard feature using CloudKit's public database and need advice on the best approach to calculate a user's rank efficiently. Current Setup Record Structure: Record Type: LeaderboardScore Fields: period (String): "daily", "weekly", "monthly", "allTime" score (Int): User's score profile (Reference): Link to user's profile achievedAt (Date): Timestamp Leaderboard Display: Initially fetch first 15 users (sorted by score descending) Paginate to load more as user scrolls Show total player count Show current user's rank (even if not in top 15) The Challenge I can fetch the first 15 users easily with a sorted query, but I need to display the current user's rank regardless of their position. For example: User could be ranked #1 (in top 15) ✅ Easy User could be ranked #247 (not in top 15) ❌ How to get this efficiently? My Current Approach Query records with scores higher than the user's score and count them: // Count how many users scored higher let predicate = NSPredicate( format: "period == %@ AND score > %d", period, userScore ) // Rank = count + 1 Concerns For 1000+ users with better scores, this requires multiple paginated queries Even with desiredKeys: [], I'm concerned about performance and CloudKit request limits Questions Is there a CloudKit API I'm missing that can efficiently count records matching a predicate without fetching all the records and paginating? Is this approach acceptable for a leaderboard with 1K-10K users? Does fetching with desiredKeys: [] help significantly with performance? Are there any optimizations I should consider to make this more efficient? What's the recommended approach for calculating user rank in CloudKit at this scale? Current Scale Expected: 1,000-10,000 active users per leaderboard period Platform: iOS 17+, SwiftUI Any guidance on best practices for leaderboards usecase in CloudKit would be greatly appreciated!

I'm running into a problem in my attempt to clear CKAssets on the iCloud server. The documentation for CKAsset says: If you no longer require an asset that’s on the server, you don’t delete it. Instead, orphan the asset by setting any fields that contain the asset to nil and then saving the record. CloudKit periodically deletes orphaned assets from the server. I'm deleting image file assets which are properties on an ImageReference type (largeImage and thumbNailImage properties). When I delete an image, I am setting those properties to nil and sending the record for the ImageReference to iCloud using the async CKDatabase.modifyRecords method. This always results in an error: <CKError 0x600000d92a60: "Asset File Not Found" (16/3002); "open error: 2 (No such file or directory)"> And of course the assets still appear in the CloudKit dashboard. What is the proper way of orphaning the assets on the CloudKit server?

Hi, I'm having difficulties fetching many 2 many relationships. I have an Actor entity (which I can query in CloudKit JS) that has 2 relationships: inputComponents and outputComponents, both pointing towards a Component entity. How to query these relationships? Thanks Tom

I have a messaging app that has been working successfully for several years. It still works for most users, but about one month ago one of my users started experiencing issues receiving notifications. From my investigation, the user's Notification Service Extension (NSE) has not been triggered since they started reporting the issue. I was able to access the user's phone and connected it to the console to check for any logs related to the NSE being triggered or a push notification being received, but there were no relevant logs. I have already verified that notifications are enabled for the app and that Do Not Disturb is not active. I also tried sending a test notification using the CloudKit Console. The notification was successfully delivered to other push notification tokens, but it did not work for this specific device’s token. I have also confirmed that the push token on the server matches the one on the device and that it is being used with the APNs production environment. The issue for this user started in iOS version 26.2 and are still ongoing in version 26.3.1 . Has anyone encountered a similar issue or have suggestions on how to further diagnose this?

I accidentally deleted all CloudKit containers from the CloudKit Database console, and now I'm unable to create new containers. Both the CloudKit Console website and Xcode are not allowing me to create any new containers. Is there a way to restore the deleted containers? How can I create a new CloudKit container if the console website is not responding? Thank you.

I've understood that SwiftData is not abled to share the whole content of a cloudkit database. So I'm trying to rewrite everything. Does someone knows id Sharing is coming on SwiftData at WWDC 26? Anyway, can someone can point me an example a a configured coredata stack that share all its content with other icloud users (with sharing pane and accept invitation code). At this step, on the owner side, I see some data in the default zone of my private container but nothing is visible on the shared zone. Maybe I don't understand where and when I should check shared data in cloudkit console. Need Help also here. See below by configuration stack: // Core Data container public lazy var container: NSPersistentContainer = { switch delegate.usage() { case .preview : return previewContainer() case .local : return localContainer() case .cloudKit : return cloudKitContainer() } }() private func cloudKitContainer() -> NSPersistentContainer { let modelURL = delegate.modelURL() let modelName = modelURL.deletingPathExtension().lastPathComponent guard let model = NSManagedObjectModel(contentsOf: modelURL) else { fatalError("Could not load Core Data model from \(modelURL)") } let container = NSPersistentCloudKitContainer( name: modelName, managedObjectModel: model ) let groupIdentifier = AppManager.shared.groupIdentifier guard let appGroupURL = FileManager.default.containerURL ( forSecurityApplicationGroupIdentifier: groupIdentifier ) else { fatalError("App Group not found: \(groupIdentifier)") } // MARK: - Private Store Configuration let privateStoreURL = appGroupURL.appendingPathComponent("\(modelName).sqlite") let privateStoreDescription = NSPersistentStoreDescription(url: privateStoreURL) // Persistent history tracking (MANDATORY) privateStoreDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) privateStoreDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) // CloudKit options for private database // Core Data automatically uses the default zone: com.apple.coredata.cloudkit.zone let privateCloudKitOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: delegate.cloudKitIdentifier()) privateCloudKitOptions.databaseScope = .private privateStoreDescription.cloudKitContainerOptions = privateCloudKitOptions // MARK: - Shared Store Configuration guard let sharedStoreDescription = privateStoreDescription.copy() as? NSPersistentStoreDescription else { fatalError("Create shareDesc error") } // The shared store receives zones that others share with us via CloudKit's shared database sharedStoreDescription.url = appGroupURL.appendingPathComponent("\(modelName)-shared.sqlite") // Persistent history tracking (MANDATORY) sharedStoreDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) sharedStoreDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) // CloudKit options for shared database // This syncs data from CloudKit shared zones when we accept share invitations let sharedCloudKitOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: delegate.cloudKitIdentifier()) sharedCloudKitOptions.databaseScope = .shared sharedStoreDescription.cloudKitContainerOptions = sharedCloudKitOptions // Configure both stores // Private store: com.apple.coredata.cloudkit.zone in private database // Shared store: Receives shared zones we're invited to container.persistentStoreDescriptions = [privateStoreDescription, sharedStoreDescription] container.loadPersistentStores { storeDescription, error in if let error = error as NSError? { fatalError("DB init error:\(error.localizedDescription)") } else if let cloudKitContiainerOptions = storeDescription.cloudKitContainerOptions { switch cloudKitContiainerOptions.databaseScope { case .private: self._privatePersistentStore = container.persistentStoreCoordinator.persistentStore(for: privateStoreDescription.url!) case .shared: self._sharedPersistentStore = container.persistentStoreCoordinator.persistentStore(for: sharedStoreDescription.url!) default: break } } let scope = storeDescription.cloudKitContainerOptions?.databaseScope == .shared ? "shared" : "private" print("✅ \(scope) store loaded at: \(storeDescription.url?.path ?? "unknown")") } // Auto-merge container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy do { try container.viewContext.setQueryGenerationFrom(.current) } catch { fatalError("Fail to pin viewContext to the current generation:\(error)") } return container }

I'm trying to understand the terminology around forward vs backward references in CloudKit. Say I have two record types: User LeaderboardScore (a score belongs to a user) The score record stores a user reference: score["user"] = CKRecord.Reference( recordID: userRecordID, action: .deleteSelf ) So: LeaderboardScore → User The user record does not store any references to scores From a data-model perspective: Is this considered a forward reference (child → parent)? Or a back reference, since the score is "pointing back" to its owner? My use case is having leaderboard in my app and so i have created a user table to store all the users and a score table for saving the scores of each user of the app.

Hi everyone, I’m facing an issue with CloudKit sync getting stuck during initial device migration in my SwiftData-based app. The app follows a local-first architecture using SwiftData + CloudKit sync, and works correctly for: ✔ Incremental sync ✔ Bi-directional updates ✔ Small datasets However, when onboarding a new device with large historical data, sync becomes extremely slow or appears stuck. Even after two hours data is not fully synced. ~6900 Transactions 🚨 Problem When installing the app on a new iPhone and enabling iCloud sync: • Initial hydration starts • A small amount of data syncs • Then sync stalls indefinitely Observed behaviour: • iPhone → Mac sync works (new changes sync back) • Mac → iPhone large historical migration gets stuck • Reinstalling app / clearing container does not resolve issue • Sync never completes full migration This gives the impression that: CloudKit is trickling data but not progressing after a certain threshold. The architecture is: • SwiftData local store • Manual CloudKit sync layer • Local-first persistence • Background push/pull sync So I understand: ✔ Conflict resolution is custom ✔ Initial import may not be optimized by default But I expected CloudKit to eventually deliver all records. Instead, the new device remains permanently in a “partial state”. ⸻ 🔍 Observations • No fatal CloudKit errors • No rate-limit errors • No quota issues • iCloud is available • Sync state remains “Ready” • Hydration remains “mostlyReady” Meaning: CloudKit does not report failure — but data transfer halts. ⸻ 🤔 Questions Would appreciate guidance on: Is CloudKit designed to support large initial dataset migration via manual sync layers? Or is this a known limitation vs NSPersistentCloudKitContainer? ⸻ Does CloudKit internally throttle historical record fetches? Could it silently stall without error when record volume is high? ⸻ Is there any recommended strategy for: • Bulk initial migration • Progressive hydration • Forcing forward sync progress ⸻ Should initial migration be handled outside CloudKit (e.g. via file transfer / backup restore) before enabling sync? ⸻ 🎯 Goal I want to support: • Large historical onboarding • Multi-device sync • User-visible progress Without forcing migration to Core Data. ⸻ 🙏 Any advice on: • Best practices • Debugging approach • CloudKit behavior in such scenarios would be greatly appreciated. Thank you!

I was hoping for an update of SwiftData which adopted the use of shared and public CloudKit containers, in the same way it does for the private CloudKit container. So firstly, a big request to any Apple devs reading, for this to be a thing! Secondly, what would be a sensible way of adding a shared container in CloudKit to an existing app that is already using SwiftData? Would it be possible to use the new DataStore method to manage CloudKit syncing with a public or shared container?

I have several macOS applications that use CloudKit. I need to test and finds out what happens when the user signs out of their iCloud account. That's because the application may lose data after signing out and then signing in again. Every time I do that, it'll take 15, 20 minutes... I don't time it, but it takes quite a gigantic time to sign out as the spinner keeps rolling. Why does it take so long to just sign out? This sign out effect is untestable because it takes a long time to sign out of an iCloud account and then make changes to the code and then test again. In case you need to know, my system version is Sequoia 15.7.

While testing record creation in public CloudKit database for authenticated user I am able to do so without any issues. But for devices missing iCloud account or authentication expired I am seeing the below error: ▿ <CKError 0x97a959200: "Permission Failure" (10/2007); server message = "CREATE operation not permitted"; op = 67331DE3AF3DD666; uuid = 1F3ACD4F-A799-4CD4-ADF0-EDE9E12F2DCB; container ID = "***"> _nsError : <CKError 0x97a959200: "Permission Failure" (10/2007); server message = "CREATE operation not permitted"; op = 67331DE3AF3DD666; uuid = 1F3ACD4F-A799-4CD4-ADF0-EDE9E12F2DCB; container ID = "***"> I am unable to add create/write permission to _world security role in dashboard. Is this something not supported by Cloudkit? Only authenticated iCloud users will be able to create and write data to public database as well?