I’m using SwiftData with CloudKit and running into an issue during initial sync on a fresh device. I’m importing a small set of records, some records has images as CKAsset (with about 5 images ~3MB). Records indexes are the default ones for the Dev env. The problem is that the import process never seems to complete. However, if I delete those records that contains the assets from the iCloud Dashboard, the import finishes successfully. Has anyone experienced something similar? What approach would you recommend to handle this without implementing a custom sync layer on top of CloudKit? I am logging remote changes events (NSPersistentStoreRemoteChange): CloudKit import in progress...|2026-04-25 22:18:10| Then I see: Background Task 49 ("CoreData: CloudKit Import"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. And then the import never ends. Thanks!

We’re using a private database with a custom zone. Record types and related schema are created programmatically rather than through the dashboard. When running the app in the development environment, I can see that data is saved and can be retrieved successfully. However, in the iCloud console, I don’t see any record types or even the custom zone. Additionally, I’m unable to deploy any schema to production because no changes are detected. Do you have any ideas on what we might be missing? Installing the app from TestFlight when trying to upload a record CloudKit reports this error: <CKError 0x13f40bb10: "Invalid Arguments" (12/2006); server message = "Cannot create new type MyType in production schema" ...>

Summary On macOS 26.4.1 (25E253), iCloud Drive file uploads can enter a silent deadlock where every upload attempt fails at the transport layer. No error is surfaced anywhere — not in Finder, not in System Settings, not in the iCloud status panel. The upload queue simply stops. Other iCloud services (Photos, Mail, App Store) continue to work normally through the same networking infrastructure at the same time. Root Cause The issue is a stale HTTP/3 (QUIC) session cached in the user-level nsurlsessiond process's BackgroundConnectionPool. The deadlock cycle: cloudd requests an upload to the GCS storage endpoint nsurlsessiond provides the cached (broken) HTTP/3 session The TLS handshake succeeds, but the body upload dies mid-transfer (err=T, requestDuration=-1.000, responseHeaderBytes=0) cloudd retries with a new connectionUUID — but nsurlsessiond still routes through the same poisoned QUIC session This repeats indefinitely Killing cloudd alone does not help — nsurlsessiond retains the poisoned pool. Only killing both the user-level cloudd and nsurlsessiond clears the pool and forces a fresh protocol negotiation. The Smoking Gun After killing both daemons, the system falls back to HTTP/1.1 for the stuck uploads — and they complete instantly: Before Kill After Kill Protocol h3 (QUIC) http/1.1 (TCP) Largest upload Failed at partial offsets 26 MB in 1.6 seconds Server response 0 bytes 596 bytes (normal) Same endpoint, same files, same network interface (en5), same power state. The only change was the protocol negotiation after a fresh nsurlsessiond. Reproduction Reproduced 3 times on April 11, 2026 using a standardized set of 8 test files (8 bytes to 20 MB) in a non-shared iCloud Drive folder. Each run showed the identical pattern: Small files (<100 KB) squeeze through before the QUIC session stalls Larger files trigger the deadlock every time 5–6 retries with fresh connectionUUIDs, all failing over protocol=h3 After kill cloudd + nsurlsessiond: immediate flush via protocol=http/1.1 An automated evidence-collection script (collect_h3_deadlock_evidence.sh) captures paired before-kill / after-kill logs. Included in the Feedback report. Symptom Check (for others hitting this) /usr/bin/log show --predicate 'process == "cloudd"' --last 5m 2>&1 \ | grep "putContainer.*err=T.*requestDuration=-1.000.*protocol=h3" | wc -l Output > 0 = this deadlock. Output = 0 = different issue. Recovery (one-liner) kill $(ps -axo user,pid,command | awk -v u="$USER" \ '($1==u && /CloudKitDaemon.framework.*cloudd/ && !/--system/) \ || ($1==u && /\/usr\/libexec\/nsurlsessiond/ && !/--privileged/) \ {print $2}') Both daemons respawn within 1–2 seconds. Do not use killall nsurlsessiond — it would also kill the privileged system instance. What was ruled out Network connectivity (Photos uploaded 8 MB through the same pool simultaneously) iCloud account (metadata operations succeeding, only body uploads failing) File type/content (random data, correlation is with size, not type) Storage quota (1.65 TB free) CFNetworkHTTP3Enabled=false (key is ineffective in 26.4.1) Suggested fixes (from the Feedback report) CFNetwork: Invalidate the QUIC session after N consecutive requestDuration=-1.000 failures CloudKit/NSURLSession: Expose a pool invalidation API like [NSURLSession invalidatePoolEntryForEndpoint:] cloudd: Self-healing retry — create a fresh NSURLSession after M consecutive deadlock-signature failures Finder: At minimum, surface the stuck state to the user instead of failing silently Filed as FB22476701 — includes full reproduction timelines, request/connection UUIDs, sysdiagnose, and a 12-page investigation PDF with architecture diagrams and protocol comparison tables. If you're experiencing the same issue, please file a duplicate referencing FB22476701 — Apple prioritizes by duplicate count. System MacBook Air, macOS 26.4.1 (25E253) iCloud Drive with Desktop & Documents sync en0 (WLAN) + en5 (USB-LAN via Studio Display)

We are seeing a CloudKit private database failure for this specific container: iCloud.com.matrixqlc.photodiet.sync Failure pattern: accountStatus succeeds in some cases ensure/create custom zone succeeds but record/database-level operations consistently fail with: CKErrorDomain code = 15 CKInternalErrorDomain code = 2000 HTTP 500 Failing operations include: allRecordZones() databaseChanges(since:nil) allSubscriptions() fetch record zone metadata save record fetch record query records What makes this unusual is that the issue follows the container, not the app. On the same physical device, same Apple ID, same developer team: PhotoDiet + iCloud.com.matrixqlc.photodiet.sync => fails RepaymentCalculator + iCloud.com.matrixqlc.photodiet.sync => fails PhotoDiet + iCloud.com.matrixqlc.repaymentcalculator.sync2 => succeeds RepaymentCalculator + iCloud.com.matrixqlc.repaymentcalculator.sync2 => succeeds So this does not currently look like: app-specific entitlement/provisioning issues device/account issues CloudKit API misuse in one app record schema or app business logic issues It currently looks like the container iCloud.com.matrixqlc.photodiet.sync itself may be in a bad backend state. Sample request identifiers: RequestUUID: C8403047-0037-4D36-A7A7-CF3C83584A42 RequestUUID: 04437D9D-115E-45F5-87B5-A8CD146AE705 RequestUUID: C924B620-BAEE-403D-B944-151ADCF3419F RequestUUID: A54E79E1-6037-4533-BA09-18FBC436851C RequestUUID: 3EFD8913-3781-47CF-A48C-B651BF38EA50 RequestUUID: 2677A991-40B3-42AB-9CE5-3C4F1288EE08 Feedback Assistant ID: FB22539748 Has anyone seen a container-specific CloudKit private database failure like this, where multiple apps under the same team can access one container normally but consistently fail on another container with CKError 15 / HTTP 500?

I'm seeing a critical issue where a custom CKRecordZone is consistently deleted server-side when a second iCloud account interacts with a zone-wide CKShare. I've reproduced this 20+ times across two days and have exhausted every client-side fix I can think of. Looking for guidance on what might be going wrong. Setup Container: iCloud.com.cohencooks (production app on App Store) Custom CKRecordZone in owner's private database Zone-wide CKShare(recordZoneID:) (iOS 15+ zone sharing) SwiftData with ModelConfiguration(cloudKitDatabase: .none) — no automatic CloudKit mirroring Acceptance via CKFetchShareMetadataOperation → CKContainer.accept(metadata) (no UICloudSharingController) Minimal reproduction // 1. Owner creates zone + share let zone = CKRecordZone(zoneName: "MyZone") try await privateDB.save(zone) let share = CKShare(recordZoneID: zone.zoneID) share[CKShare.SystemFieldKey.title] = "My Share" as CKRecordValue share.publicPermission = .readWrite let (results, _) = try await privateDB.modifyRecords(saving: [share], deleting: []) // 2. Owner pushes ~500 records to zone — all succeed // 3. Second user (different iCloud account) accepts share let metadata = try await container.shareMetadata(for: shareURL) try await container.accept(metadata) // 4. Owner's next CKFetchRecordZoneChangesOperation → zoneNotFound (code 26) // Zone is permanently gone. allRecordZones() confirms deletion. What I observe Three distinct failure patterns depending on configuration: Pattern 1 — publicPermission = .readWrite, no addParticipant: Zone dies instantly after acceptance. First push notification shows cloudkit.share changed (zone alive), second push notification returns zoneNotFound. The non-owner never successfully wrote anything. Pattern 2 — publicPermission = .none with explicit addParticipant: Zone survives acceptance and 2-3 minutes of bidirectional sync (non-owner pulls 578 records, pushes meal plans back). Then a push notification arrives and the zone is gone. This is dramatically better than Pattern 1 but still fails. Pattern 3 — Container destabilization after repeated testing: After 20+ create/delete cycles in one day, zones die from the owner's own push notifications — no second device involved at all. The container appears to enter an unstable state. What I've ruled out Hypothesis Test Result publicPermission = .readWrite Changed to .none + explicit addParticipant Zone survived longer but still eventually deleted Zone name tombstoning Tested 6 fresh names never used in this container All eventually deleted Non-owner writes causing deletion Gated ALL non-owner push methods (recipe, meal plan, grocery, photo, event) Zone still deleted database.save(share) vs modifyRecords Switched to modifyRecords(saving:deleting:) Zone still deleted NSPersistentCloudKitContainer interference Removed all Core Data CloudKit code Zone still deleted Double share acceptance Fresh app install, single acceptance only Zone still deleted Advanced Data Protection Neither account has ADP enabled Not the cause Programmatic vs system acceptance Tested both container.accept() and tapping share link Zone still deleted CloudKit Dashboard No ZoneDelete operation is visible in the logs. All operations are ZoneFetch, ZoneChanges, RecordQuery, RecordFetch. I do see EphemeralGroup operations targeting the custom zone — not sure what generates those. Comparison with working apps I compared my implementation with another app (Spotbook) that uses the exact same zone-wide CKShare(recordZoneID:) pattern with publicPermission = .readWrite and programmatic acceptance — and it works. The main difference is that app uses CKSyncEngine (iOS 17+) rather than raw CKFetchRecordZoneChangesOperation / CKModifyRecordsOperation. Could CKSyncEngine be handling something internally that prevents this issue? Questions Is there a known interaction between zone-wide CKShare(recordZoneID:) acceptance and zone lifecycle that could cause zone deletion? Does CKSyncEngine handle zone-wide sharing differently than manual CKFetchRecordZoneChangesOperation + CKModifyRecordsOperation? What generates EphemeralGroup operations in CloudKit Dashboard? Could these trigger a zone delete? After 20+ zone create/delete cycles in a container, is there a server-side rate limit or tombstone mechanism that would destabilize new zones? Is the custom programmatic acceptance flow (CKFetchShareMetadataOperation → container.accept()) fully supported for zone-wide shares, or does it require UICloudSharingController? Any guidance would be greatly appreciated. This is blocking multi-user functionality for our app (mesa, a meal planning app on the App Store). Single-user sync works perfectly — the issue only manifests when a second iCloud account is involved. Environment: iOS 18.4.1, Xcode 16+, Swift, SwiftUI

We have a user from Asia whose subscription failed to be detected by our app. On 26.4. They also tried revoking the yearly subscription and activating a monthly. Payment ok and the device reported that the subscription is active. Our code relies on Transaction.currentEntitlements in StoreKit, which seems to be broken, at least for this user. None of these worked: Installing iOS 26.4.1 Reinstalling our app Logging out and in from iCloud. Hard device reset Full iOS reinstall. User finally gave up and got a refund. I am reporting here in case other apps experienced similar problems. This discussion mentions that a regression in 26.4 might have contributed to the issue which is supposed to be fixed in 26.4.1. ( https://aninterestingwebsite.com/forums/thread/820562?answerId=883682022#883682022 ) The issue may have persisted or left the entitlements corrupt for this particular user. Hoping that the issue is resolved so we do not have more problems in the future.

I am debugging a CloudKit sharing issue in an iOS app that uses NSPersistent​Cloud​Kit​Container with Core Data backed sharing. The symptom is that collaboration/share creation appears to succeed locally, but the resulting CKShare never gets a server-backed URL. UICloud​Sharing​Controller therefore cannot proceed because share​.url remains nil. (I do see the UICloudSharingcontroller Dialog and am abble to select people to share, one executed the share icon in the message window just spins After adding extensive logging, it looks like the real problem is not the sharing UI itself, but that Core Data + CloudKit mirroring is already in a bad state before share presentation begins. What I am seeing: Repeated CloudKit import failures with CKError​.partial​Failure The partial failure always contains one stale share zone with: • CKError​.zone​Not​Found • server message: "​Zone does not exist" Core Data then repeatedly logs: • NSCloud​Kit​Mirroring​Delegate​Will​Reset​Sync​Notification​Name • reason: Zone​Deleted • followed by a full mirroring reset Only after that reset loop do I attempt to prepare the collaboration share fetch​Share(object:) returns a share record named cloudkit​.zoneshare participants is 1 but share​.url remains nil forever, even after polling for ~20 attempts / ~20+ seconds Representative log sequence: CoreData+CloudKit ... Fetch finished with error: <CKError ... "Partial Failure"... partial errors: { com.apple.coredata.cloudkit.share.33781809-778A-461C-ABAB-872746C8F80D:defaultOwner = <CKError ... "Zone Not Found" (26/2036); server message = "Zone does not exist"> }> NSCloudKitMirroringDelegateWillResetSyncNotificationName reason: 'ZoneDeleted' NSCloudKitMirroringDelegateDidResetSyncNotificationName reason: 'ZoneDeleted' Preparing collaboration share for cruise 'Share 658' Fetching existing collaboration share for cruise 'Share 658' Fetch existing collaboration share result: found record='cloudkit.zoneshare' url='nil' participants='1' You cannot get the URL of a share until it's been saved to the server Collaboration share URL polling attempt 1/20 ... ... Collaboration share URL polling attempt 20/20 ... Collaboration share 'cloudkit.zoneshare' never produced a URL Important detail: This stale-zone Zone ​Not ​Found / Zone​Deleted reset cycle happens before the collaboration flow starts, so it looks like sharing is running inside an already unhealthy mirroring state rather than causing the corruption itself. Questions: Is this a known failure mode where a deleted/stale Core Data CloudKit share zone can keep the mirroring delegate in a reset loop and prevent newly fetched/created CKShare objects from ever receiving a server URL? Is there an Apple-recommended way to recover from this in development besides deleting the app / resetting local data / clearing CloudKit development data? Is there any supported way to identify and purge stale share metadata or orphaned Core Data share zones without fully resetting the local store? If fetch​Share returns a CKShare whose record exists locally as cloudkit​.zoneshare but url stays nil, does that generally mean the share was never fully saved to the server, or can mirroring-reset churn itself prevent the URL from materializing? Environment: • iOS app • Core Data + NSPersistent​Cloud​Kit​Container • CloudKit sharing enabled • issue observed in development environment At this point my working theory is: • stale/deleted share zone in CloudKit development environment • NSPersistent​Cloud​Kit​Container import repeatedly hits zone​Not​Found • mirroring resets continuously • collaboration share can be fetched locally but never becomes server-backed enough to produce share​.url If anyone from Apple or anyone who has hit this exact Zone​Deleted reset loop has guidance on the correct recovery path, I’d appreciate it.

I'm seeing a critical issue where a custom CKRecordZone is consistently deleted server-side when a second iCloud account interacts with a zone-wide CKShare. I've reproduced this 20+ times across two days and have exhausted every client-side fix I can think of. Looking for guidance on what might be going wrong. Setup Container: iCloud.com.cohencooks (production app on App Store) Custom CKRecordZone in owner's private database Zone-wide CKShare(recordZoneID:) (iOS 15+ zone sharing) SwiftData with ModelConfiguration(cloudKitDatabase: .none) — no automatic CloudKit mirroring Acceptance via CKFetchShareMetadataOperation → CKContainer.accept(metadata) (no UICloudSharingController) Minimal reproduction // 1. Owner creates zone + share let zone = CKRecordZone(zoneName: "MyZone") try await privateDB.save(zone) let share = CKShare(recordZoneID: zone.zoneID) share[CKShare.SystemFieldKey.title] = "My Share" as CKRecordValue share.publicPermission = .readWrite let (results, _) = try await privateDB.modifyRecords(saving: [share], deleting: []) // 2. Owner pushes ~500 records to zone — all succeed // 3. Second user (different iCloud account) accepts share let metadata = try await container.shareMetadata(for: shareURL) try await container.accept(metadata) // 4. Owner's next CKFetchRecordZoneChangesOperation → zoneNotFound (code 26) // Zone is permanently gone. allRecordZones() confirms deletion. What I observe Three distinct failure patterns depending on configuration: Pattern 1 — publicPermission = .readWrite, no addParticipant: Zone dies instantly after acceptance. First push notification shows cloudkit.share changed (zone alive), second push notification returns zoneNotFound. The non-owner never successfully wrote anything. Pattern 2 — publicPermission = .none with explicit addParticipant: Zone survives acceptance and 2-3 minutes of bidirectional sync (non-owner pulls 578 records, pushes meal plans back). Then a push notification arrives and the zone is gone. This is dramatically better than Pattern 1 but still fails. Pattern 3 — Container destabilization after repeated testing: After 20+ create/delete cycles in one day, zones die from the owner's own push notifications — no second device involved at all. The container appears to enter an unstable state. Inconsistent state after deletion Here's something that might help narrow this down. After one of the zone deletions, I deployed the same build to a second device signed into a different iCloud account that had previously accepted the CKShare. Without sending a new invite, that device found the "Household" zone via allRecordZones() on sharedCloudDatabase — it could pull all 578 records, push updates, and the share URL still resolved. Meanwhile, the owner device (zone creator) gets "zone not found" from both allRecordZones() and direct recordZone(for:) on privateCloudDatabase. So it looks like the zone is deleted from the owner's private database, but the CKShare and zone records remain accessible to participants via the shared database. Participants can still read and write as if nothing happened — the owner just can't see the zone anymore. This also creates a recovery problem — when the owner creates a new zone with the same name, it gets a new CKShare URL, but the participant is still connected to the old "ghost" zone. The two sides are permanently split. Does this mean the zone deletion is happening through a path that doesn't properly clean up the sharing infrastructure? Is this expected behavior when a zone-wide CKShare's zone is deleted, or does it suggest the deletion is happening through an abnormal server-side path? What I've ruled out Hypothesis Test Result publicPermission = .readWrite Changed to .none + explicit addParticipant Zone survived longer but still eventually deleted Zone name tombstoning Tested 6 fresh names never used in this container All eventually deleted Non-owner writes causing deletion Gated ALL non-owner push methods (recipe, meal plan, grocery, photo, event) Zone still deleted database.save(share) vs modifyRecords Switched to modifyRecords(saving:deleting:) Zone still deleted NSPersistentCloudKitContainer interference Removed all Core Data CloudKit code Zone still deleted Double share acceptance Fresh app install, single acceptance only Zone still deleted Advanced Data Protection Neither account has ADP enabled Not the cause Programmatic vs system acceptance Tested both container.accept() and tapping share link Zone still deleted CloudKit Dashboard No ZoneDelete operation is visible in the logs. All operations are ZoneFetch, ZoneChanges, RecordQuery, RecordFetch. I do see EphemeralGroup operations targeting the custom zone — not sure what generates those. Comparison with working apps I compared my implementation with another app that uses the exact same zone-wide CKShare(recordZoneID:) pattern with publicPermission = .readWrite and programmatic acceptance — and it works. The main difference is that app uses CKSyncEngine (iOS 17+) rather than raw CKFetchRecordZoneChangesOperation / CKModifyRecordsOperation. Could CKSyncEngine be handling something internally that prevents this issue? Questions Is there a known interaction between zone-wide CKShare(recordZoneID:) acceptance and zone lifecycle that could cause zone deletion? Does CKSyncEngine handle zone-wide sharing differently than manual CKFetchRecordZoneChangesOperation + CKModifyRecordsOperation? What generates EphemeralGroup operations in CloudKit Dashboard? Could these trigger a zone delete? After 20+ zone create/delete cycles in a container, is there a server-side rate limit or tombstone mechanism that would destabilize new zones? Is the inconsistent state I described (zone gone from owner's private DB but still accessible from participant's shared DB) expected behavior, or does it indicate the deletion is happening through an abnormal path? Is the custom programmatic acceptance flow (CKFetchShareMetadataOperation → container.accept()) fully supported for zone-wide shares, or does it require UICloudSharingController? Any guidance would be greatly appreciated. This is blocking multi-user functionality for our app (mesa, a meal planning app on the App Store). Single-user sync works perfectly — the issue only manifests when a second iCloud account is involved. Environment: iOS 18.4.1, Xcode 16+, Swift, SwiftUI

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?

I've been working on an app. It uses iCloud syncing. 48 hours ago everything was working 100%. Make a change on the iPhone it immediately changed on the Mac. Change on the Mac, it immediately changed on the iPhone. I didn't work on it yesterday. I updated to iOS26.4 on the iPhone and 26.4 on the Mac yesterday instead. Today, I pull up the project again. I made NO changes to the code or settings. Make a change on the iPhone it immediately updates on the Mac. Make a change on the Mac, nothing happens on the iPhone. I've waited an hour, and the change never happens. If you leave the iPhone app, then return, it updates as it should. It appears that iCloud's silent notification is to being received by the iPhone. Anyone else having the issue? Is there something new with iOS 26.4 that needs to be adjusted to get this to work? Again, works flawlessly with the Mac, just not with the iPhone.

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?