We ship two iOS apps from the same team that are designed to work together: App A – uses CloudKit container "Container A" App B – uses CloudKit container "Container B" Until App B version 1.5, App B also had Container A in its com.apple.developer.icloud-container-identifiers entitlement, because it read a few records from App A's container directly. App B called registerForRemoteNotifications() for its own container's subscriptions. App A creates a CKDatabaseSubscription on the shared database (and CKQuerySubscriptions on the private database) with notificationInfo.alertBody set, so that a participant gets a visible push when the owner shares something. Problem: on devices where App B 1.5 (or earlier) had run, every push generated by App A's subscriptions is delivered to both App A and App B. App B shows a banner with App A's alert text under App B's name. This still happens after we shipped App B 1.6, which removed Container A from App B's entitlements entirely (App B 1.6 never touches that container). What we have tried on an affected device, none of which stopped the deliveries to App B: Updating App B to 1.6 (entitlement removed). Deleting App B and reinstalling it from the App Store. In App B, calling unregisterForRemoteNotifications() and then registerForRemoteNotifications() again on next launch. Rebooting the iPhone. Devices that installed App B 1.6 fresh (never ran 1.5) do not receive these pushes, so the behavior seems to come from a registration that was created while App B still had the entitlement and that is not being cleaned up. Questions: Is the association "APNs token of App B ↔ Container A" kept on the CloudKit server side, and is there any way for the app (or for us as the developer) to remove it once the entitlement is gone? If it cannot be removed explicitly, does it expire? Roughly how long after the app stops registering for that container? Is there a recommended way to design this (two apps, one container) so that alert pushes from one app's subscriptions are not shown by the other app? We would rather not switch App A to content-available pushes with local notifications, because silent pushes are not delivered reliably when the app has been force-quit. Environment: iOS 26, App A 4.7.x, App B 1.6.x, Production CloudKit environment. We have also filed a DTS request with the actual identifiers and can provide device logs or a sysdiagnose if helpful. Thank you.

iOS/macOS 26 added share access requests: CKShare.allowsAccessRequests, CKShare.requesters, CKShareRequestAccessOperation, and deny/block requesters on CKShare. My app uses this flow on iOS, macOS and watchOS: The owner sets allowsAccessRequests = true and shows the share URL as a QR code. The joiner runs CKShareRequestAccessOperation for that URL. The owner reads requesters and approves (adds a participant), denies or blocks. I'd like to do part of this from the web. I can't find anything about access requests in the CloudKit Web Services reference or the CloudKit JS docs. Is there a supported way to read/set allowsAccessRequests, submit an access request, or list/approve/deny/block requesters through Web Services or CloudKit JS? If not, is there a recommended workaround? I've filed this as a suggestion: FB25372887

Hello, I'm hitting a persistent CKQuerySubscription save failure on the public database in my Production CloudKit container. I want to flag this is NOT the iOS 26.4 silent-push regression resolved in 26.4.1 (I've confirmed it manifests differently and on devices that predate that bug). App: Win 10 Min (com.luiz.PandaApp) Container: iCloud.com.luiz.PandaApp Current shipping version: 3.2.1 build 420 (approved 2026-05-19) Public database THE ERROR (captured from CKError.userInfo) CKErrorCode 12 (badRequest) CKInternalErrorDomain code 2006 ("BadSyntax") ServerErrorDescription: "attempting to create a subscription in a production container" Execution time per failed attempt: 45-90ms (gateway-level rejection, not data validation). CODE let subscription = CKQuerySubscription( recordType: "GuardianRequest", predicate: NSPredicate(format: "guardianRecordName == %@", me), subscriptionID: "guardian-incoming-(me)", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true subscription.notificationInfo = info try await container.publicCloudDatabase.save(subscription) The .save() throws every time. REPRODUCES ACROSS iPhone on iOS 26.4.2 (i.e., has the 26.4.1 CloudKit regression fix) iPhone on iOS 18.6.x (predates the 26.4 regression entirely) Multiple distinct Apple IDs / userId hashes Fresh installs via TestFlight Updated installs from production CONSISTENTLY: USER_ERROR / BAD_REQUEST. Same error every time. WHY THIS ISN'T THE iOS 26.4 REGRESSION (Thread 820562) That regression caused silent notifications to be DROPPED client-side AFTER successful subscription creation. Our failure is SubscriptionCreate itself being rejected by the CloudKit server before any subscription exists. Different layer, different symptom. iOS 18.6.x devices also fail (they never had the 26.4 token-validation regression code). CLOUDKIT CONSOLE LOGS (sample request UUIDs Apple engineers can lookup) EB30E9D0-8C97-4685-BD16-3E79B3328D6F (2026-05-17 8:08 UTC) EEAA0606-5B50-4640-A950-EEA33B790B8E (2026-05-17, captured in-app) EB4C90CE-9172-4942-B00F-DE4A28388FBA (2026-05-19 7:18 UTC, iOS 18.6.x) F2DF69D9-2339-437A-B59B-7FBD4D57442F (2026-05-19 7:51 UTC, iOS 26.4.x) CloudKit Console → Production → Subscriptions: 0 entries despite 70+ attempts since 2026-05-11. WHAT I'VE VERIFIED / TRIED Schema: GuardianRequest.guardianRecordName and GuardianResponse.requesterRecordName both have QUERYABLE indexes in the Production schema (confirmed in Console). Field types: all STRING. aps-environment entitlement: "production" (changed from "development" in build 420; no change in error pattern). Push Notifications capability: enabled on App ID in Developer Portal AND in Xcode Signing & Capabilities for the main app target. UIBackgroundModes: includes "remote-notification". Re-deployed Production schema from Development on 2026-05-19 (Console reported "no changes"; failure pattern unchanged). Tried with and without info.desiredKeys = []. RecordQuery operations on the same fields and record types in the same container succeed consistently. QUESTIONS Is there a known infrastructure issue affecting public database CKQuerySubscription creation that is distinct from the iOS 26.4 regression (thread 820562)? Is there a per-container configuration that may be in an unexpected state, and if so what should I check? Are there workarounds beyond schema redeployment that have helped other developers in similar situations? Thanks for any guidance.

I’m investigating an authentication discrepancy in CloudKit’s Development private database, using a Safari Dock web app on macOS 26.5. All records contain fabricated test data. Names below are anonymized. In one signed-in SDK session, records/lookup successfully read a private default-zone marker. The following zones/lookup for TestZone failed with auth-failed/noAccount. Two private reads, zero writes. A separately inspected full-trial zone request returned AUTHENTICATION_FAILED with the reason: “Authentication failed. Please check you have the correct API token for this container.” In a fresh session, records/lookup directly read metadata for TestHead in TestZone and returned revision 1. It used zoneID and non-asset desiredKeys, without zones/lookup. One private read, zero asset downloads, zero writes. The existing website API token was recopied from the selected container, not regenerated. The inspected request Origin matched the configured allowed origin. The app uses a custom fetch adapter and RAM-only authTokenStore. It checks identity before private requests and rebinds only ckWebAuthToken to the token validated by that check. This is not an unmodified SDK request path. Does private zones/lookup have a documented authentication requirement that differs from records/lookup? Could this custom request handling explain these results? The root cause is still unconfirmed.

Saving any CKQuerySubscription to the private database fails in the Production environment with CKError 12 (badRequest): “attempting to create a subscription in a production container”. The same subscriptions save fine in Development. The schema, including the needed QUERYABLE index, has been deployed to Production. This looks like the same issue as FB22867235 and Developer Forums thread 826814. Container: iCloud.com.darkstardev.chorecalendar Environment: Production (TestFlight build 0.2 (5)) Device / OS: iPhone18,2, iOS 27.0.1 App: Core Data with NSPersistentCloudKitContainer (private and shared stores), sharing a zone with CKShare Database: privateCloudDatabase of the share owner’s account Zone: the Core Data share zone, com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 Subscription: CKQuerySubscription on recordType CD_Mark predicate CD_status == "waiting" options .firesOnRecordCreation and .firesOnRecordUpdate zoneID set to the share zone Schema: CD_Mark has a QUERYABLE index on CD_status in Production, which I verified in the CloudKit Console. All three notificationInfo variants fail the same way in Production. All three succeed in Development: An alert with titleLocalizationKey, alertLocalizationKey and alertLocalizationArgs ["CD_kidName", "CD_choreName"] A plain alert with titleLocalizationKey and alertLocalizationKey, without args A silent subscription with shouldSendContentAvailable = true and desiredKeys Because even the silent subscription is refused, the cause isn’t the alert configuration. Production refuses CKQuerySubscription creation for this container. Steps to reproduce: Install the TestFlight build, signed in as the share owner. Create and share a family record through NSPersistentCloudKitContainer. Turn on the in-app setting that saves the subscription. Expected: the subscription is saved, and a push arrives when a participant creates or updates a waiting CD_Mark record. Actual: all three saves fail. Error text: “Error saving record subscription with id check-ins-com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 to server: attempting to create a subscription in a production container” (CKError 12). Already tried: Deploying the schema from Development to Production. Turning the setting off and on again a day later.

I have a shipped App Store app (bundle ID com.stoolkit.app) using a private iCloud container (iCloud.com.stoolkit.app) purely for file-based backup via FileManager's ubiquity container APIs, not CloudKit database/CKContainer. The availability check is as simple as: FileManager.default.ubiquityIdentityToken != nil This consistently returns nil, even though: the app's embedded provisioning profile (verified by extracting embedded.mobileprovision from the built .ipa and parsing it) correctly includes com.apple.developer.icloud-container-identifiers, com.apple.developer.ubiquity-container-identifiers (both = iCloud.com.stoolkit.app), and com.apple.developer.icloud-services. The app's entitlements plist correctly declares com.apple.developer.icloud-container-identifiers: [iCloud.com.stoolkit.app] and com.apple.developer.icloud-services: [CloudDocuments]. The test device is signed into iCloud. Settings > Apple ID > iCloud > Apps Using iCloud shows the app listed and toggled on. The device-wide iCloud Drive toggle is on. No Content and Privacy / Screen Time restrictions are active. It reproduces identically on two separate physical devices (an iPad via TestFlight, an iPhone via the live App Store), both running the same signed build. Relaunching the app and toggling iCloud Drive off/on device-wide did not change the behavior. I don't currently have access to a Mac/Xcode to produce a verified minimal reproduction project, but the check itself is a single system API call, so I'd expect a fresh single-view app with the same iCloud container entitlement to reproduce it directly. What could cause ubiquityIdentityToken to return nil under these conditions? Is there an account- or container-side initialization step I might be missing beyond registering the container under the App ID's capabilities?

I am evaluating the storage architecture for a native iOS family-organising application using CloudKit. The design is preliminary, and I am seeking clarification before native testing and production deployment. Proposed test scenario Apple Account A owns a custom record zone in its private CloudKit database. Account A creates a root CKRecord and CKShare. Independent Apple Account B accepts the share with read/write permissions. Account B accesses and updates shared records through sharedCloudDatabase. Both accounts initially have separate iCloud storage allocations. 1. Storage ownership and quota accounting Apple's documentation appears to describe shared CloudKit storage using different terminology. The native sharedCloudDatabase documentation references the application's iCloud storage quota, while CKError.Code.quotaExceeded describes a shared-zone write failing when the zone owner's iCloud storage is full. For records, shares, metadata and CKAssets created or modified by Account B in Account A's shared zone: Whose iCloud storage allocation is consumed? Is any additional storage counted against Account B? Does any usage count against a developer-level CloudKit quota or generate operator charges? 2. Storage exhaustion and error behaviour If Account A reaches its iCloud storage limit while Account B has available storage, should B's writes to A's shared zone fail with quotaExceeded? Conversely, if B's storage is full but A has capacity, should B still be able to modify A's shared records? How should the application distinguish quota failures affecting B's private database from failures affecting A's shared zone? Does behaviour change when both accounts use the same Apple Family iCloud storage pool or when an account downgrades its storage plan? 3. Current CloudKit limits and costs Could Apple clarify or identify authoritative documentation for: Current native CloudKit storage, request and data-transfer allowances. Whether 400 records/shares per operation and 2 MB per request remain current guidelines. How change fetches, retries and partial failures are accounted for. Any differences between CloudKit development and production environments. Whether private/shared CloudKit usage can result in developer-billed charges. Where developers can verify the applicable allowances for their own containers before production deployment. I have not yet reproduced a quota-exceeded scenario in a focused Xcode project. I am seeking architectural clarification to design appropriate storage limits, recovery behaviour and native verification tests. Links to authoritative Apple documentation or clarification from an Apple frameworks engineer would be greatly appreciated.

Hello Apple Developer Support, I'm developing an iOS application called LuckyWinston that uses CloudKit for its backend. I'm trying to assign a custom CloudKit security role to a specific user in the public database. However, I've encountered the following issues: The built-in Users record type cannot be queried normally. Attempting to fetch the user record directly by its record ID also fails. I haven't found a supported method in the current CloudKit Console for assigning a custom security role to an individual user. I understand that CloudKit restricts queries against its built-in user records, but I would like clarification on how developers are expected to assign custom security roles. My questions are: Is assigning custom security roles to individual CloudKit users still supported? If so, what is the correct procedure using the current CloudKit Console or supported APIs? Is there an alternative supported method for assigning user-specific permissions without exposing sensitive records? If individual custom-role assignments are no longer supported, what architecture does Apple recommend? I want to ensure that LuckyWinston follows Apple's recommended CloudKit security practices before proceeding further. Thank you for your assistance.

I'm hitting the same issue. Deploying the Development schema to Production fails every time with HTTP 500 internal-error on the …/schema/<developmentSchemaId>/promote request. It fails from both the "Changes" tab and the "Diff View" tab of the Confirm Deployment dialog. detailedMessage is undefined. Filed as FB25280547, with the container ID, request UUIDs and screenshots. Example requestUuid: 7f4aec62-6ead-4e86-8784-77be751d3622 The diff is purely additive: Core Data / NSPersistentCloudKitContainer fields such as _ckAsset assets, CD_moveReceipt and one new string field, plus QUERYABLE indexes on ___recordID. No type changes and no removals. I tried refreshing, re-signing in, and a private window. It still fails. This blocks our App Store release because the new build writes a field that Production doesn't have yet. Could someone from the CloudKit Console team take a look? Thank you!

I export a small image with size of 100 kilobytes (or less) via CoreData+CloudKit. The image data is then stored in a data field in user's private database. In CloudKit dashboard, it shows that the data size is 100 kilobytes - as it should. The device's local storage increase by 100 kilobytes - as expected. However, I check the user's iCloud storage (in Settings>Apple ID>iCloud>Manage Storage). The app's storage in crease by approximately 1 megabytes. Larger by a factor of 10! I try uploading the same image to a test asset field via CloudKit Dashboard. The user's iCloud storage increase by 100 kilobytes - as expected. Why the data (bytes) field take up more of user's iCloud quota than asset field? I really prefer to directly store as data rather than as a CKAsset. Is this just the way it is... or a bug?

We use CloudKit JS for TillDone with the existing Production container iCloud.com.bahir.remindloop (bundle ID com.bahir.remindloop). Apple's hosted authentication page has shown the technical container identifier instead of TillDone. The App ID description is already the product name, and Certificates, Identifiers & Profiles shows the same named container checked in the app's iCloud Container Assignment. Our first public iOS App Store submission is currently In Review; the app is not yet publicly released on the App Store. We reviewed CloudKit.ContainerConfig and Composing Web Service Requests. The documented configuration includes token persistence and sign-in button styling but does not describe a title override for Apple's authentication page. The Apple-hosted captions for WWDC 2015 session 710, around 17:43-17:53, describe the authentication page's app name and icon as coming from iTunes Connect for an App Store-published app. Is successful public App Store publication a prerequisite for this metadata to appear on the CloudKit authentication page? If so, is the mapping automatic for the app's associated Production container? If not, which supported metadata setting or support route corrects the mapping without replacing the Production container? We need to preserve all existing private records and shared zones. We are not trying to edit Apple's sign-in page, change the container identifier, collect Apple Account passwords, or migrate user data merely to change this label. References: https://developer.apple.com/documentation/cloudkitjs/cloudkit.containerconfig https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/SettingUpWebServices.html https://devstreaming-cdn.apple.com/videos/wwdc/2015/710jle9eakx/710/subtitles/eng/fileSequence17.webvtt

Same symptom here, and I can add evidence that isolates it to the Console's schema backend rather than to my project or my schema. Container: iCloud.com.zx.PatternMaking Team ID: T8B35NA44M Platform: CloudKit Console (web), Safari + Chrome, also in Private Browsing First seen: 2026-10-11. Last successful promotion to Production: 2026-09-18. WHAT FAILS (both Development and Production environments) Schema -> Indexes / Record Types / Security Roles: "Internal error". Record Types intermittently renders but shows "No record types found". Settings -> Tokens & Keys: "Error fetching API tokens / Internal error". (The account-level Settings -> Tokens panel works fine, so the failure is scoped to this container.) Deploy Schema Changes... -> "Confirm Deployment": BOTH the "Changes" tab and the "Diff View" tab show "Internal error", and "Deploy" is disabled. WHAT WORKS (same team, same account, same browser) All of Data -> Records / Zones / Subscriptions. Another container, iCloud.com.zx.GradientWallpaper, is fully functional, including its schema pages and deployment. The CloudKit Web Services API via cktool, for THIS container: cktool export-schema --environment development -> 6 record types cktool export-schema --environment production -> 3 record types Both files are byte-for-byte identical (same SHA-256) to the files produced by the Console's own "Export Schema...", so the stored schema is intact, readable and well-formed. This is not a corrupt-schema problem. THE PENDING CHANGE IS PURELY ADDITIVE Field-by-field diff of the two exports, including index flags: present in Production but missing from Development: 0 additions: 5 fields on CD_CanvasItem plus 3 whole record types. Nothing removed, retyped or renamed, so it satisfies the CloudKit rule that production schema changes may only add. The Console fails before it can even compute the diff. THERE IS NO NON-CONSOLE PATH TO PROMOTE cktool import-schema --environment production and cktool validate-schema --environment production both fail with: "The request was not allowed: BadRequestException: endpoint not applicable in the environment 'production'" and cktool has no promote/deploy subcommand. So the one and only way to promote a schema - the Console - is exactly the thing that is broken. SERVER LOGS SHOW ZERO SERVER-SIDE ERRORS Console -> Logs export for 2026-10-07 .. 2026-10-11 UTC, 181 events: 176/181 SUCCESS, no server errors at all. The only 5 failures are USER_ERROR/BAD_REQUEST RecordQuery calls issued by the Console itself (interfaceType=WEB) on 10-07. The schema/management surface writes no entries to this log, which is consistent with the failure being isolated there. I'd be grateful for any workaround, or for someone from Apple to promote the Development schema of this container to Production on my behalf - the change is purely additive and I'm blocked from shipping. I have filed a feedback report. The report id is FB25146476.

Apple's app-specific password support article says: "For supported third-party apps that access your iCloud Mail, Calendar, and Contacts, you can authorize the app using your Apple Account instead of using an app-specific password." I can't find any documentation about (1) what makes an app "supported," (2) how to apply or qualify, or (3) the technical mechanics — Sign in with Apple, OAuth scopes, MDM, etc. I'm building an iOS app (already approved for Gmail with the gmail.modify scope and CASA-assessed) that monitors a user's mailbox for scam emails with their explicit consent. I'd love to offer the same to iCloud Mail users without requiring the manual app-specific password flow, if there's a Sign in with Apple-style alternative available. Has anyone had success applying for this, or can an Apple engineer point to additional documentation? Thanks!

I’m investigating an authentication discrepancy in CloudKit’s Development private database, using a Safari Dock web app on macOS 26.5. All records contain fabricated test data. Names below are anonymized. In one signed-in SDK session, records/lookup successfully read a private default-zone marker. The following zones/lookup for TestZone failed with auth-failed/noAccount. Two private reads, zero writes. A separately inspected full-trial zone request returned AUTHENTICATION_FAILED with the reason: “Authentication failed. Please check you have the correct API token for this container.” In a fresh session, records/lookup directly read metadata for TestHead in TestZone and returned revision 1. It used zoneID and non-asset desiredKeys, without zones/lookup. One private read, zero asset downloads, zero writes. The existing website API token was recopied from the selected container, not regenerated. The inspected request Origin matched the configured allowed origin. The app uses a custom fetch adapter and RAM-only authTokenStore. It checks identity before private requests and rebinds only ckWebAuthToken to the token validated by that check. This is not an unmodified SDK request path. Does private zones/lookup have a documented authentication requirement that differs from records/lookup? Could this custom request handling explain these results? The root cause is still unconfirmed.

I’m experiencing a CloudKit Dashboard failure that is preventing me from releasing an app update, and I’m looking for help escalating it to the team responsible for CloudKit’s schema-management services. Symptoms For one CloudKit container, both Development and Production are affected: Record Types cannot be displayed. Indexes returns an Internal Error. Deploy Schema to Production also returns an Internal Error. Schema export to .ckdb succeeds. The Logs section is accessible, with no obvious errors. Other containers in the same developer account work normally. My app appears to continue operating against both environments. Apple System Status reports CloudKit as operational. Diagnostic information Safari’s Web Inspector reports HTTP 429 responses for the diff and recordTypes requests. The response includes: code: 429 message: too-many-requests reason: Internal error requestUuid: 47b6b1be-ce3c-41a4-bd3d-6f5c38ec875c Impact I added a new Core Data entity, CD_ShipsPaperEntity. It is present in the Development schema export but absent from Production. I opened CloudKit Dashboard to deploy the schema change and discovered the problem. I cannot deploy the schema required for my next app release. I have exported both schemas and confirmed that their existing shared record types are consistent. This appears to be a container-specific CloudKit Dashboard or backend failure, rather than an application-code issue. A sample application would not necessarily reproduce a failure in the Dashboard’s own schema-management requests. Could an Apple engineer investigate the request UUID and advise how to get the affected container’s schema deployment working again? Thanks

I am developing a LINE-based service for users in Japan. With each user's explicit consent, our backend would read their selected iCloud calendars and send event reminders through LINE. Users would not be required to install a native iOS or macOS app. Apple's support article describes Apple Account authorization for supported third-party apps: https://support.apple.com/en-us/121539 Is this authorization available to a web service with this architecture? What are the eligibility requirements, application process, and Calendar integration documentation? If it is not available, does Apple officially support server-side CalDAV access using a user-generated app-specific password for this use case? What requirements and limitations apply to credential handling, access scope, and synchronization frequency? Do the requirements differ between reading calendars and potentially creating or updating events in the future? If this architecture is not supported, is there another documented integration path? I would appreciate links to the relevant documentation or the appropriate technical contact.

Apple Support article 121539 describes Apple Account authorization for supported third-party apps that access iCloud Mail, Calendar, and Contacts: https://support.apple.com/121539 An Apple DTS engineer directed developers to the “Express interest in Auth 2.0 for iCloud Mail, Calendar, and Contacts” form: https://developer.apple.com/forums/thread/825772 I develop Zefir Calendar, an independent Windows desktop app built with Electron. It currently accesses remote iCloud calendars through CalDAV with the user's Apple Account email address and an app-specific password. It supports personal and shared calendars and event reading, creation, editing, and deletion according to the user's permissions. We want to request Calendar access only. A related discussion says the interest form requires an App Store URL: https://developer.apple.com/forums/thread/847329. A Windows-only app has no Apple App Store URL. Could an Apple engineer clarify: Can an independent Windows app use this authorization flow? If so, how should a Windows-only developer submit the interest form without an Apple App Store URL? Is paid Apple Developer Program membership or separate approval required? What registration, service, capability, or entitlement is required? Is there technical documentation for the flow and its Calendar scopes? Can authorization be limited to Calendar, and does it support read/write access to personal and shared iCloud calendars? Are the granted credentials used with the existing iCloud CalDAV service, or with a different API? What are the supported token refresh, revocation, and desktop callback mechanisms? This question concerns authorization for remote iCloud Calendar data, not Sign in with Apple for identity or EventKit access to local device calendars. Our goal is to replace app-specific passwords while preserving our CalDAV functionality if Apple supports it.

My question Is there a way to perform an iCloud keychain reset in order to be able to test CKErrorUserDidResetEncryptedDataKey ? I found this section in the CloudKit documentation https://developer.apple.com/documentation/cloudkit/encrypting-user-data#Handle-a-User-Keychain-Reset I want to be prepared for the zoneNotFound / CKErrorUserDidResetEncryptedDataKey case. However, I can't find a way to actually reproduce this error with an iCloud (test-) user and can't find any Apple documentation on how to perform sucha "User Keychain Reset". The only thing that almost looked like it I came across was in the Keychain.app's Settings "Reset Default Keychains…". However, performing this didn't seem to affect the CloudKit data used in our App at all. I've been trying to do this with an Apple account that has 2FA active and a recovery account assigned. We're only targetting >= iOS 18, macOS >= 15.

I’m seeing a repeatable failure to export changes in the background with an NSPersistentCloudKitContainer private database on iPhone. While offline, I create an object and save its managed object context. I then leave the app and lock the phone. After Wi‑Fi reconnects, the change remains absent from the same app on my Mac. Opening the iPhone app causes it to sync and appear on the Mac. The unplugged sequence reproduces this. When I tried the same sequence with the iPhone plugged in, background sync worked. In a sysdiagnose from an unplugged occurrence: 16:44:21: The context saved the new object. 16:44:21: dasd queued the CloudKit export but reported networkPathAvailability = 0. 16:44:27: iOS suspended the app. 16:48:21: Wi‑Fi reported a satisfied path. Through 16:54:42: No subsequent export attempt appeared in the logs. Opening the iPhone app caused the change to appear on the Mac. In the same offline-to-online routine, a reminder created in Apple Reminders appears on my Mac without reopening Reminders on the iPhone; my app’s new object does not appear until I reopen my app on the iPhone. Is a queued NSPersistentCloudKitContainer export expected to run after connectivity returns while the app remains suspended and unplugged? If so, what should I check to learn why it did not run here? Or does Reminders receive background scheduling priority that third-party apps cannot use?

I am developing an iOS/iPadOS app using SwiftUI, SwiftData, CloudKit, and CKShare. I need help determining why an already-approved CKShare recipient is not receiving updated application-level authorization. Architecture The owner stores working data locally in SwiftData and explicitly mirrors shared data into a custom CloudKit zone named AthleteVaultSharedSchoolData. The owner writes these records to privateCloudDatabase. Recipients accept a zone-wide CKShare and read the accepted zone through sharedCloudDatabase. Each approved recipient also has an AVSchoolMembershipAuthorization record in that shared zone. Its deterministic record name is based on the recipient's CloudKit user record ID: AVSchoolMembershipAuthorization- The authorization contains the recipient's role and arrays of permitted team, sport, and player UUIDs. What works The recipient successfully accepted the share and can download the shared school data. The recipient has previously fetched his authorization from the accepted shared zone and received the correct initial permissions. The owner can change that recipient's permissions and save the updated authorization. I verified in CloudKit Console → Production → Private Database that there is exactly one authorization record for this recipient. It is active and contains the newly selected playerIDs. The record's updatedAt also changes when the administrator saves the permissions. Both owner and recipient are testing the same TestFlight Production build. The problem After changing an already-approved recipient's permissions, the Production authorization record is correct, but the recipient continues operating with the previous player permissions after closing and reopening the app. For example, the administrator removes Player A and grants Player B. CloudKit Console shows the authorization now contains Player B instead of Player A, but the recipient continues seeing Player A and does not see Player B. On the recipient I obtain the current CloudKit user record ID, locate the accepted shared zone, construct the deterministic authorization record ID, and fetch it from the shared database: let recordID = CKRecord.ID( recordName: "AVSchoolMembershipAuthorization-(userRecordID.recordName)", zoneID: acceptedZoneID ) container.sharedCloudDatabase.fetch(withRecordID: recordID) { record, error in // decode current authorization } Once the authorization is returned, the app explicitly reconciles its local SwiftData permission rows: permissions absent from the current authorization are deleted and newly granted permissions are inserted. Production schema During troubleshooting I discovered that AVSchoolMembershipAuthorization had initially existed only in Development. That schema has now been deployed to Production. Before deployment, Production correctly returned a “Cannot create new type AVSchoolMembershipAuthorization in production schema” error. After deploying the schema, the owner save succeeds and the updated authorization is visible directly in the Production CloudKit Console. Therefore the current problem occurs after the Production authorization has been successfully saved. Questions With a zone-wide CKShare, should records created or modified in the owner's shared custom zone automatically become visible to an already-accepted participant through sharedCloudDatabase? If AVSchoolMembershipAuthorization was created after the recipient originally accepted the zone-wide share, is any additional operation required to expose that record to the existing participant? Is sharedCloudDatabase.fetch(withRecordID:), using the accepted shared-zone ID and exact deterministic record ID, the appropriate way to retrieve the latest server version? Can an accepted participant continue receiving an older version of a record after the owner successfully saves a newer version to the Production private database? If so, what API or synchronization pattern should be used to reliably obtain the current version? When changing CKShare.Participant.permission for an existing participant at the same time as changing application-level authorization in a custom CKRecord, is there another CKShare operation required? Is a per-recipient authorization CKRecord inside a zone-wide shared zone an appropriate CloudKit design, or is there a recommended pattern for per-recipient authorization? I can provide the relevant CloudKit service code, CloudKit Console screenshots, and additional diagnostics if needed. Thank you for any guidance on the expected CloudKit behavior for updated records in an already-accepted zone-wide CKShare.