Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments. The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type: { "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" } In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails. Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x What we do (simplified) let zone = CKRecordZone(zoneID: ownerZoneID) _ = try await db.modifyRecordZones(saving: [zone], deleting: []) // succeeds let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID) // plain String / Int64 / Date fields only let share = CKShare(rootRecord: record) share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue share.publicPermission = .none _ = try await db.modifyRecords(saving: [record, share], deleting: [], savePolicy: .allKeys, atomically: true) // FAILS User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted. Already ruled out iCloud sign-in - accountStatus() == .available immediately before the call. iCloud Keychain - enabled on both the iPhone and a Mac on the same account. Advanced Data Protection - OFF. Leftover/broken share - also fails when no record exists yet (brand new). UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save. Schema - the record type and every field we write are deployed to Production. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented. Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25: "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered. "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500. Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout. Questions What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record. Is there an account-level or container-level condition that can block PCS key provisioning? Has anyone else seen CKShare creation (not query) failing in the same period? Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.

Recently, I am experiencing a CKErrorServerRejectedRequest error during my app's iCloud data sync process. I have not modified or migrated the schema recently. To troubleshoot, I logged into the iCloud Dashboard (CloudKit Console) to query the records directly. However, the dashboard also returns a generic "Internal Error" with no additional details whenever I attempt a query. Here is what I have tried so far: Private Database Only: The error only occurs within the Private Database. Querying the Public Database works normally and correctly returns "No records found." Multiple Containers: This issue affects all of my existing containers across both Development and Production environments. New Container Test: I created a brand new container with a new table, verified that the indexes are set to QUERYABLE, and attempted a query. The same "Internal Error" occurs. System Status: I checked the Apple Developer System Status page (https://developer.apple.com/system-status/), and both "CloudKit Console" and "CloudKit Database" are showing green (normal). Is anyone else experiencing this, or is there a known workaround for account-wide dashboard query failures?

Since July 25, multiple production users have been unable to load previously saved records from a CloudKit private database. The query uses CKQueryOperation with: Record type: UserAnLi Predicate: category_sub_id == "1401" Sort descriptor: creationDate descending Results limit: 20 The requests consistently fail after approximately 10 seconds with: Error domain: CKErrorDomain Error code: 15 (CKErrorServerRejectedRequest) Underlying error: CKInternalErrorDomain Code=2000 HTTP status: 500 CKErrorRetryAfterKey: absent CKErrorShouldThrottleClient: absent Examples from two different users/devices: iOS 18.3.2 RequestUUID: 67890D6B-8076-4135-9635-7DCCFF38D94F OperationID: A796C6799FA69D66 CloudKit partition: 233 Edge response time: 10024 ms iOS 26.6 RequestUUID: 1249FEAE-9D5A-40CB-9076-DAD2D8396BCF OperationID: CEC87546C31D61E2 CloudKit partition: 227 Edge response time: 10086 ms Users are signed in to iCloud, iCloud Drive is enabled, and general network access works normally. According to TN3162, documented CloudKit throttling normally returns CKErrorServiceUnavailable or CKErrorRequestRateLimited with a retry-after value. These failures instead return CKErrorServerRejectedRequest, HTTP 500, and no retry-after information. The issue has been reported through Feedback Assistant: FB24046201 Could this indicate a production CloudKit query/index problem, a server-side query timeout, or an undocumented/misreported throttle? Is there any client-side mitigation, or does this require investigation by the CloudKit backend team?

I am preparing to save CLLocation data to CloudKit. In the dashboard, when you create a location object, you only can specify lat/long. In the archived CloudKit web services reference, the location dictionary shows more than that is being saved. https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/Types.html#//apple_ref/doc/uid/TP40015240-CH3-SW5 However, this is in the archive. I want to know via documentation if all of the current properties of a CLLocation are saved, and if it is reasonable to assume future fields would be too. The documentation was likely archived BEFORE properties like speedAccuracy, courseAccuracy, source, information floor, and ellipsoidal altitude. FB24049646 - CloudKit: Do all properties of CLLocation get persisted in CloudKit when setting a record value as CLLocation - CKWS archive reference Location Dictionary doesn't show new fields (speed/course accuracy, source info, floor, ellipsoidalAltitude)

您好，想咨询下Configuration ID为32b92585-4221-4b39-a305-c3de951bb53a的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

Hello, We have a CloudKit-based sharing feature where an app owner shares a single record hierarchy (one CKShare in a dedicated CKRecordZone) with one external recipient. The recipient does not necessarily own an Apple device — they open a link in a browser on a website and authenticate via Sign in with Apple using CloudKit JS, then read and write a small subset of fields. The shared data is sensitive (health-related), so we evaluated CKRecord.encryptedValues for the sensitive fields. Our understanding is that encrypted fields are not accessible through CloudKit JS / CloudKit Web Services — only through the native frameworks or CKTool JS. If that's correct, using encryptedValues would make our web recipient flow impossible. Our questions: Is that understanding still accurate for the current CloudKit JS version, or is there a supported way to read encryptedValues fields from a browser-based CloudKit JS client? If not: for this kind of sensitive-but-web-accessible data, is relying on CloudKit's standard encryption (in transit and at rest) the intended approach, or would you recommend a different architecture — for example encrypting the payload ourselves before writing it and passing the key out-of-band with the share link? Is there any guidance on enforcing a time limit on a CKShare? We currently expire shares client-side, but that only works while the owner's app runs. Is there a server-side mechanism (or a recommended pattern) for shares that should expire automatically? We enforce "only one recipient per link" by setting share.publicPermission = .none client-side as soon as the owner's device observes an accepted participant. We found that if the accepted participant's own access had only ever been granted through publicPermission (not as an explicitly invited participant), revoking publicPermission this way also revoked that same participant's write access (CKError "Zone not found" on their next saveRecords call from CloudKit JS) — until we explicitly set participant.permission = .readWrite on the already-joined CKShare.Participant before nulling publicPermission. Is this expected/documented behavior, or is there a more official API pattern for "convert a public-permission joiner into a permanent named participant, then close the link"? Thank you!

Starting today (approximately) I've been seeing intermittent CloudKit Error Code 15 (CKErrorServerRejectedRequest). Code has not changed. Anyone else getting these errors?

Posting here per DTS guidance (no reduced sample project available). Creating a CKQuerySubscription on the PUBLIC database in the Production environment always fails, on a production-signed TestFlight build. It works in the Development environment; only Production rejects it. Error: CKError 12 (invalidArguments); underlying "BadSyntax" (2006); server message = "attempting to create a subscription in a production container". The subscription: let sub = CKQuerySubscription( recordType: "PublicSolution", predicate: NSPredicate(format: "%K == %@", "challengeAuthorID", myUserRecordName), subscriptionID: "MyChallengeSolved-", options: [.firesOnRecordCreation]) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true sub.notificationInfo = info try await container.publicCloudDatabase.save(sub) Verified (all good): TestFlight build is distribution-signed: aps-environment = production (confirmed with codesign on the archive). APNs registration succeeds on device (valid token). CKContainer.accountStatus = .available; userRecordID resolves. Reads of PublicSolution succeed in Production. challengeAuthorID on PublicSolution is QUERYABLE in the deployed Production schema (verified in CloudKit Console). Dev and Production schemas are identical; deployed to Production multiple times (Console reports "no changes"). Removing notificationInfo.desiredKeys made no difference. Push Notifications capability present; entitlement aps-environment = production. Question: What makes Production reject this public-DB CKQuerySubscription create, and what container-side configuration allows it? Same code succeeds in Development. Container: iCloud.JCM.Contraptor

My scenario I have an app which stores data using SwiftData / CloudKit automatic sync It works as expected on iOS, sync happens even when the app is closed. On Mac, when mac app is closed the data from the CloudKit is not pulled into the DB. It would be nice if the widget on the Mac is updated even when the Mac app is closed. Like from a sync from an iPhone. My problem: I don't do anything for sync other than just initializing the ModelContainer and everything is taken care of. The local store has its own system level tables to maintain the sync states. So I am a bit hesitant to do a separate sync in the background process (LoginItem / LaunchAgent / LaunchDaemon. I need to read a lot on this because I am just beginning to explore this part Questions Is it feasible / advisable to have one instance of the ModelContainer created in the background process and access it in the main app for the Mac? Reason for asking is because ModelContainer is the one that does all the sync magically. Or is this too much of an overhead and users can open the app to keep the widget updated?

Since ~July 10, NSPersistentCloudKitContainer export has failed on every device on my iCloud account; import still works. In CloudKit Console → Logs (Production), the only failing operations are RecordDelete/RecordSave of record type pcs_data (error BAD_REQUEST) in the private com.apple.coredata.cloudkit.zone. No CD* app-record failures; the app schema is fully deployed to Production. Advanced Data Protection is enabled on the account, so PCS keys are managed end-to-end on-device. This looks like a wedged PCS key state rather than an app/schema problem. Tried with no effect: toggling ADP off/on, toggling iCloud Keychain, multiple reboots, app reinstall, extended foreground on Wi-Fi. Still failing after updating from iOS 27 Seed 3 to beta 4. Is there a way to get the account's Protected Cloud Storage key state reset so export can resume? Happy to share the Feedback number and sysdiagnoses privately with an Apple engineer.

Usually, when you call fetchRecordZoneChanges with the previous change token, you get a list of the record ID’s that have been deleted since your last fetch. But if you get a changeTokenExpired error because it‘s been too long since you last fetched, you have to call fetch again without a token. For my specific application, I still need to know, though, if any records have been deleted since my last sync. How can I get that information if I no longer have a valid change token?

您好，想咨询下Configuration ID为2641fd1b-8023-4644-b301-1d57785b8f6c的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

Guideline 5.1.3(ii) says apps "may not store personal health information in iCloud." Does this apply to any use of a private, per-user CloudKit database for health-related data, or is it specifically about unencrypted/shared storage, or data sourced from HealthKit? If a health app end-to-end encrypts sensitive fields so that even Apple's infrastructure can't read them, and the data never leaves the individual user's own iCloud account, does that change how 5.1.3(ii) applies — or is the guideline a blanket restriction regardless of encryption? Has anyone gotten reviewer feedback (approval or rejection) that clarifies how this is actually enforced in practice? Thanks in advance!

A sandboxed Mac app with correct CloudKit entitlements fails to connect to com.apple.cloudd (the CloudKit daemon) when distributed via TestFlight (Mac Team Store Provisioning Profile). The identical binary works correctly when launched from Xcode (Mac Team Provisioning Profile also present). All entitlements are correctly embedded and the App ID is properly configured in Apple Developer Portal. Environment macOS 26.5.1 (25F80) Xcode 26.5 (17F42) SwiftData with NSPersistentCloudKitContainer / ModelConfiguration(cloudKitDatabase: .private(...)) Steps to Reproduce Create a sandboxed Mac app using SwiftData with CloudKit sync Enable iCloud + CloudKit in Signing & Capabilities Archive and distribute to TestFlight (Mac Team Store Provisioning Profile) Install via TestFlight on macOS 26 and launch Check Console for kernel sandbox messages Expected Result CloudKit connects to com.apple.cloudd and syncs data, matching behavior of the iOS version using the same container. Actual Result Console shows repeated kernel sandbox denials followed by CloudKit setup failure: kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.cloudd kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.duetactivityscheduler CheatSheet Mac CoreData+CloudKit: Failed to set up CloudKit integration for store Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon." Key Diagnostic Finding When launched from Xcode, taskgated-helper validates both the Mac Team Store Provisioning Profile AND the Mac Team Provisioning Profile, and CloudKit succeeds: cloudd: TCC approved access for container containerID=iCloud.com.michaelendres.CheatSheet:Production When launched from TestFlight, only the Mac Team Store Provisioning Profile is present, and the sandbox denies com.apple.cloudd despite identical entitlements in the binary: codesign -d --entitlements shows: com.apple.developer.icloud-services: [CloudKit] com.apple.developer.icloud-container-identifiers: [iCloud.com.michaelendres.CheatSheet] com.apple.developer.icloud-container-environment: Production com.apple.security.app-sandbox: true Conclusion The Mac Team Store Provisioning Profile on macOS 26 does not appear to grant the sandbox exception for mach-lookup com.apple.cloudd, while the Mac Team Provisioning Profile (development) does. This prevents any Mac App Store / TestFlight app using CloudKit from syncing on macOS 26.

Hello, my question is exactly the title, is it possible to change capitalization of CloudKit container? I am unable to create a new one since it seems to be case-insensitive and tells me it would be a duplicate but I would like to change the capitalization since that is how the name appears within Settings > iCloud > Manage Storage. Thanks

Bundle ID: com.lavillamergo.Betriebszentrale CloudKit Container: iCloud.com.lavillamergo.Betriebszentrale Environment: Production Stack: SwiftUI + SwiftData with NSPersistentCloudKitContainer (cloudKitDatabase: .automatic) Issue: CloudKit sync (export) fails consistently in the Production environment with CKError.partialFailure (CKErrorDomain error 2). The underlying console log (captured via Console.app on a connected device) reveals: CoreData+CloudKit: -[PFCloudKitExporter exportOperationFinished:withSavedRecords:deletedRecordIDs:operationError:]: Modify records finished: ... Error Domain=CKErrorDomain Code=2 "CKInternalErrorDomain: 1011" ... Never successfully initialized and cannot execute request. Reproducibility: The error occurs on every device that connects to this container in Production, including a brand-new iPhone (iPhone 12, iOS 26.5.2) that had never previously used this app or synced with this iCloud account — ruling out device-local corruption. Already ruled out: iCloud storage quota (6TB plan, 2TB used, ample free space) Stale/duplicate records in the Production zone (queried CD_Verkauf sorted by createdTimestamp ascending via CloudKit Console — no pre-existing records found, all from the current session) Development/Production schema mismatch ("Deploy Schema Changes" dialog shows 0 pending changes across Record Types, Indexes, and Security Roles) Network connectivity (stable fiber WiFi throughout all testing) Recent schema changes made: added missing inverse relationships on several @Relationship properties, changed deleteRule from .cascade to .nullify on three relationships (Verkauf.positionen, LVVerkauf.positionen, Aufgabe.checklistePunkteStorage) — required by CloudKit's relationship constraints. Impact: Cross-device sync via Production CloudKit is effectively non-functional. Local per-device data storage works correctly. Question: What causes "Never successfully initialized" (CKInternalErrorDomain 1011) in this scenario, and how can it be resolved without a full container/environment reset?

Overview Using NotificationCenter's messages NSPersistentCloudKitContainer.EventChangedMessage (AsyncMessage) causes crash When the this project is run on iOS 27 simulator, app crashes Environment macOS: 26.5.1 (25F80) Xcode: Version 27.0 beta (27A5194q) Simulator: iPhone 17 Pro Simulator OS: iOS 27 Code causing the crash: let messages = NotificationCenter.default.messages( of: NSPersistentCloudKitContainer.self, for: .eventChanged ) Looks like the symbol is not even present Feedback: FB23220378 Logs dyld[31078]: Symbol not found: _$sSo29NSPersistentCloudKitContainerC8CoreDataE19EventChangedMessageVSo20NSNotificationCenterC10FoundationE05AsyncI0ACMc Referenced from: <488D9AA6-ED4C-3189-9A08-044D576D498D> /Users/username/Library/Developer/CoreSimulator/Devices/331ADE41-8F3A-4EBE-9E3B-B335B29224D3/data/Containers/Bundle/Application/573DF3FC-E202-4D47-A85F-E5D4D1421EAC/NotificationMessageDemo.app/NotificationMessageDemo.debug.dylib Expected in: <483D9879-24DB-3695-AFE5-B14E2D673F36> /private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreData.framework/CoreData Symbol not found: _$sSo29NSPersistentCloudKitContainerC8CoreDataE19EventChangedMessageVSo20NSNotificationCenterC10FoundationE05AsyncI0ACMc Referenced from: <488D9AA6-ED4C-3189-9A08-044D576D498D> /Users/username/Library/Developer/CoreSimulator/Devices/331ADE41-8F3A-4EBE-9E3B-B335B29224D3/data/Containers/Bundle/Application/573DF3FC-E202-4D47-A85F-E5D4D1421EAC/NotificationMessageDemo.app/NotificationMessageDemo.debug.dylib Expected in: <483D9879-24DB-3695-AFE5-B14E2D673F36> /private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreData.framework/CoreData dyld config: DYLD_SHARED_CACHE_DIR=/Library/Developer/CoreSimulator/Caches/dyld/25F80/com.apple.CoreSimulator.SimRuntime.iOS-27-0.24A5355p/ DYLD_ROOT_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=/Users/username/Library/Developer/Xcode/DerivedData/NotificationMessageDemo-gungjtytarzeijdspglltylscocj/Build/Products/Debug-iphonesimulator DYLD_INSERT_LIBRARIES=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libLogRedirect.dylib:/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=/Users/username/Library/Developer/Xcode/DerivedData/NotificationMessageDemo-gungjtytarzeijdspglltylscocj/Build/Products/Debug-iphonesimulator DYLD_FALLBACK_FRAMEWORK_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib Debug session ended with code 9: killed

I have two apps that use App Groups, CloudKit and Core Data for sharing data between multiple devices and users (one is a sample for the issue, the other one the full fledged one). In the sample app I have the following model: Collection (name) -> many Items (names and count) and corresponding views to increment the count. I also have the widget share the proper App Group and CloudKit container. It has a button that triggers an increment app intent. A create a shared collection "Shares" and add two items in it - "A" & "B". Sharing from the applications and updates of the count takes about 2 seconds. I.e. I open the item view and I tap an increment button, the second phone screen updates almost immediately. Upon each update I also call WidgetCenter.shared.reloadAllTimelines(). What I see is that widgets have are not in sync with the data of the app. I have an explicit button to trigger the reload of the timelines, I can follow along with the debugger and the Core Data data is different, i.e. different count. I also show a date property, so I know that the widget is redrawn. I think that as soon as I added the target for the widget and added it to the app group I started seeing: BUG IN CLOUDKIT: Error submitting background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)". The sync between the widget and the app on the same device is inconsistent. I also see a lot of when interactions happen fast. submitTaskRequest failed for com.apple.coredata.cloudkit.activity.import. submitTaskRequest failed for com.apple.coredata.cloudkit.activity.export. I least I hope is that after the app has synchronised, the widget will catch-up and show the same data - i.e. at least the same device will show data consistently. This does not happen though. Even on the device on which I'm doing the changes, and tapping multiple times the manual reload of widgets button, the Core Data is stale, and the time of reload of the widget is fine. The relevant threads this I've found are (none of them can shed any light): https://developer.apple.com/forums/thread/653112?answerId=697974022 https://developer.apple.com/forums/thread/650192?answerId=614112022#614112022 https://developer.apple.com/forums/thread/651648?answerId=827386022 I have tested with iOS 26.5.2 and iOS 27 Beta. The widget is it out sync

Description: When a user's iCloud storage is full, the Notes app continues to save recent edits locally to a pending-sync cache. However, if the user toggles iCloud Notes sync to "Off" in System Settings, macOS executes a total database purge script. The system completely ignores error flags indicating that the local edits never successfully reached the cloud server. This creates a critical edge case resulting in permanent user data loss. Requested Change: Implement an explicit safeguard check prior to executing the local cache purge. If local_edits > cloud_edits, the system must present a warning modal stating: "Your most recent edits have not yet uploaded to iCloud due to full storage. Disabling sync will permanently delete these un-saved notes from this device."

I'm adding CloudKit sharing to an app that already uses NSPersistentCloudKitContainer successfully. Private-database sync works flawlessly across my devices. But every attempt to create a share hangs: container.share(_:to:) never returns and never invokes its completion handler. No error is thrown, nothing prints, the operation simply stalls indefinitely. Environment: Xcode 26, iOS 26.5, iPhone 16 Paid Individual developer account Single NSPersistentCloudKitContainer, two stores (private + shared) What works: Private database sync across multiple devices (iPhone + iPad) is reliable eventChangedNotification reports setup/import/export events succeeding continuously CloudKit schema was initialized via initializeCloudKitSchema() and record types appear in the CloudKit Console The problem: Calling share on a root object hangs. I've reproduced the identical hang with all three API variants: async/await: try await container.share([object], to: nil) — never returns Completion handler: container.share([object], to: nil) { ... } — closure never fires UICloudSharingController preparation-closure initializer — the closure never fires, controller presents an empty sheet A log line immediately before the share call prints; a log line inside the completion/closure never does. My two-store setup (per WWDC21 session 10015): swiftlet sharedURL = privateDesc.url! .deletingLastPathComponent() .appendingPathComponent("YerBoat-Shared.sqlite") let sharedDesc = NSPersistentStoreDescription(url: sharedURL) let sharedOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.com.example.app") sharedOptions.databaseScope = .shared sharedDesc.cloudKitContainerOptions = sharedOptions sharedDesc.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) sharedDesc.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) container.persistentStoreDescriptions = [privateDesc, sharedDesc] Possibly relevant: the objects I'm trying to share (and their related records via cascade relationships) were all created before I added the sharing/shared-store code. Could existing records in the default zone fail to migrate into a shareable zone, causing the hang? Questions: What causes share() to hang silently with no error and no completion? Does sharing require records to be created after the shared store exists, or should existing private-database records be shareable? Is there a required step between initializeCloudKitSchema() and the first share() call that I'm missing? I've reviewed WWDC21-10015 and TN3164. Any guidance appreciated.