Filed as FB25408294 with sysdiagnose attached. After an Apple battery repair (Aug 28, 2026), my iPhone 15 Pro Max was reset and set up as new. Since then, Settings shows "Some iCloud Data Isn't Syncing." Resume Data Sync asks for my iPhone passcode, loads, then shows "Couldn't Sync iCloud Data" with only Cancel or Delete iCloud Data. iOS 27.2 developer beta Advanced Data Protection: OFF Messages in iCloud: 188 GB stored, but "0 messages" / "Not synced" Same error on my Mac; Apple Watch Ultra can't finish setup because of it Tried current and previous device passcode No Recovery Key or Recovery Contact I have NOT deleted any iCloud data and want to recover it rather than reset it. Is anyone from the iCloud / CloudKit / Keychain team able to look at the FB? Has anyone found a way to get a device back into the iCloud Keychain circle without resetting end-to-end encrypted data?

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?