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.

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

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.

Our SwiftData app (NSPersistentCloudKitContainer under the hood, Production environment, iOS 27.0, private database, default zone com.apple.coredata.cloudkit.zone, no sharing) can no longer export for one user account. On every launch, the first export is a RecordDelete of duplicate records (CD_HealthMetricsSnapshot / CD_DailyLog) that our deduplication removed locally. The CloudKit Console shows it failing with overallStatus: USER_ERROR, error: BAD_REQUEST, returnedRecordTypes: "_pcs_data". On device it surfaces as CKErrorDomain Code=2 "CKInternalErrorDomain: 1011" (partialFailure). After that, NSCloudKitMirroringDelegate reports "Never successfully initialized" and no further export happens in that process. Imports still succeed. It reproduces after deleting and reinstalling the app. On a fresh install, the initial import succeeds, and the very first export, deleting records that were only downloaded and never modified locally, fails the same way. Earlier delete batches from the same deduplication on the same account succeeded, so it seems tied to specific records or the zone's PCS state. Request IDs: E49E4252-99A6-4103-8C03-1D0738005AA3, 4BA5133D-A1F5-423F-BDE6-F65B76B66375, E8D27548-BED1-49A4-9214-3C1A35CDC8C7. Container: iCloud.com.backbonesvc.fastsignal.ios. Questions: What causes a RecordDelete to fail with BAD_REQUEST on _pcs_data? Is there a supported way to clear this without purging the zone? purgeObjectsAndRecordsInZone is documented to also delete local objects, which we must avoid. Can Apple inspect or repair the server-side state for these request IDs?

Most of my CloudKit data has been missing from my container for over a week. No response from Apple support. I am very worried it may be unrecoverable.my apps can not access the data and the dashboard shows a huge amount of files and data in other files missing. These are needed to operate our chiropractic clinic and contain patient and transaction history. This might be a disaster for us.

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

Hi, I’m seeing a CloudKit Production sync failure in an iOS app using SwiftData/Core Data with private CloudKit mirroring. Sync worked correctly after release, then stopped working without any new app build being released. Device logs show: CKInternalErrorDomain Code=1011 and Core Data reports that CloudKit mirroring was never successfully initialized. CloudKit Production logs also show a native PRIVATE database request failing with: USER_ERROR / BAD_REQUEST involving the internal record type: _pcs_data The Production schema, private zone, and subscription are still present. I have not reset Production or deleted any zones/subscriptions. I have already filed a Feedback Assistant report with diagnostics. Has anyone seen this pattern before? Is there a safe developer-side remediation, or is this typically an Apple-side CloudKit/PCS issue? I want to avoid any destructive action that could risk existing user data.

Hi, Overview I have a SwiftData project which automatically syncs with CloudKit. When I run the app, I see the following error in Xcode logs. Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)" My attempt I can enable Background processing (under Signing & Capabilities > Background modes), but I don't know the BGTaskSchedulerPermittedIdentifiers to add in the Info.plist Questions How can I resolve this? If I should enable background processing, what are the BGTaskSchedulerPermittedIdentifiers to add in Info.plist?

Every CloudKit request from my app fails with CKError "Permission Failure" (10/2007), server message "Invalid bundle ID for container". Setup: SwiftData / NSPersistentCloudKitContainer, private database, Development environment, explicit container identifier (not the default container). What I verified, following TN3164: The App ID has iCloud with CloudKit enabled and exactly this container assigned. The container is visible in CloudKit Console under the same team. The Xcode-managed provisioning profiles contain the container in both the production and the development container identifier lists. The signed entitlements of the app match: application-identifier, team identifier, container identifiers, environment Development, CloudKit service, get-task-allow. The error occurs on two different devices and in two independent code paths: initializeCloudKitSchema and the normal SwiftData store. It fails while setting up the record zone com.apple.coredata.cloudkit.zone. Per TN3164 this means the association is not synchronized to the CloudKit server. The app is already on the App Store (the current version does not use CloudKit yet) and the next version must keep this container identifier, so switching to a new container is not an option. I have reported this through Feedback Assistant and to Developer Support. I can provide the App ID, container identifier and the failing request IDs privately to anyone from Apple who needs them. Is there anything else I can check on my side, or does this need a manual fix on the CloudKit server?

We recently moved our app to Unlisted App Distribution (Apple ID 6810578300) after a Guideline 3.2 (Business) rejection under Public distribution. Apple's Unlisted App Request support team approved the transition and confirmed by email that "Unlisted app distribution shouldn't impact the usage of CloudKit sharing, because unlisted app distribution only removes your app from App Store search" — but in practice, CKShare invitation acceptance is now broken. Setup: The app uses CloudKit Sharing (CKShare, generated via UICloudSharingController on macOS) to grant team members access to a shared database. An admin generates an invitation link from the Mac app and sends it to iOS users. Problem: Since the move to Unlisted distribution, tapping/opening a CKShare invitation link fails, even on devices where the app is already installed and fully up to date — including our own development devices. The failure shows one of two behaviors: "[AppName] cannot be opened because it requires a newer version of [AppName], which could not be found in the App Store." The link redirects to the app's App Store page, which itself shows "Open" (already installed/up to date), creating a loop with no way to actually accept the share. We've ruled out: stale installs, device-specific issues, reinstalling the app (Mac and iOS), and network/region issues — this reproduces consistently across multiple devices and Apple IDs. Hypothesis: CKShare's acceptance flow appears to perform a version-compatibility check against the public App Store catalog/search index. Since Unlisted apps are deliberately excluded from that index, this check seems to fail even when the installed app is current, producing a false "no compatible version found" error. Question: Is this a known interaction between CloudKit Sharing and Unlisted App Distribution? Is there a supported workaround — an entitlement, Info.plist key, or CKShare configuration — that allows share-link acceptance to succeed for an app that is intentionally excluded from App Store search? Any guidance from the CloudKit engineering team would be greatly appreciated, as this currently blocks our team from using the app's core sharing feature entirely.

I have just lost all records of all record types in a cloud kit database. All schema for all record types are still present. There are no mentions of record deletion or zone deletion in the console. The logging for the App has no mention of any deletion operations... Any idea how this could happen?

Hello, I am an individual developer enrolled in the paid Apple Developer Program, developing a native iOS calendar app that has not yet been released on the App Store. I would like to apply for iCloud Calendar access through Apple Account authorization, without requiring users to generate app-specific passwords. In this forum thread, an Apple DTS engineer recommended the iCloud OAuth2 interest form. I can access the form, but both “App Name” and “App Store URL” are required. Could someone clarify the correct process for an unreleased app? Can an individual developer submit an application before the app is published on the App Store? For “App Name,” may I enter the app’s current working name, or must it match an existing App Store Connect record? For “App Store URL,” what should I enter when no public App Store page exists? Would a URL based on an unpublished App Store Connect record’s numeric Apple ID be accepted, or is there an alternative submission process? I contacted Apple Developer Program Support, but they explained that their team handles developer account matters and referred me to technical support and the forums. If another team handles these application requirements, could you please direct me to the appropriate contact? Thank you for your guidance.

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!

Summary of my issue: CloudKit sync works perfectly in the Development environment, but every single record save to Production fails identically — every build, two different Macs, two different networks, and now under two different, unrelated Apple IDs. The failure isn't in my own record types; it fails on Apple's internal _pcs_data system record, which blocks the entire save (my app's real records included) from ever completing. Because it reproduces under a second, unrelated Apple ID, this doesn't look like account-specific corruption — it looks like broken server-side state on this container's Production environment itself. Exact error I'm seeing: Console.app (identical every occurrence): CoreData+CloudKit: -[NSCloudKitMirroringDelegate _requestAbortedNotInitialized:] (2192): – Never successfully initialized and cannot execute request '' due to error: Error Domain=CKErrorDomain Code=2 UserInfo={ContainerID=, NSDebugDescription=, CKPartialErrors=, RequestUUID=, NSLocalizedDescription=, CKErrorDescription=, NSUnderlyingError=0xa0b048810 {Error Domain=CKInternalErrorDomain Code=1011 UserInfo={CKErrorDescription=, NSLocalizedDescription=, CKPartialErrors=}}} CloudKit Dashboard → Production → Monitor → Logs (5+ RecordSave attempts across days/machines/accounts): Apple ID #1: json { "database": "PRIVATE", "zone": "com.apple.coredata.cloudkit.zone", "userId": "_e7c2879989e20df06db9ddb272805ea7", "operationType": "RecordSave", "platform": "Mac", "overallStatus": "USER_ERROR", "error": "BAD_REQUEST", "interfaceType": "NATIVE", "returnedRecordTypes": "_pcs_data" } Apple ID #2 (unrelated account, tested later): json { "database": "PRIVATE", "zone": "com.apple.coredata.cloudkit.zone", "userId": "_5b6b9a3c5c508babc44894d9f9d324e7", "operationType": "RecordSave", "platform": "Mac", "clientOS": "OSX;26.5.x", "overallStatus": "USER_ERROR", "error": "BAD_REQUEST", "interfaceType": "NATIVE", "returnedRecordTypes": "_pcs_data" } Every other operation type in the same sessions succeeds normally: ZoneFetch, ZoneSave, RecordFetch, SubscriptionCreate, AssetUploadTokenFetch, ZoneChanges, and DatabaseChanges all return overallStatus: SUCCESS. Only RecordSave fails, always on _pcs_data, for both accounts. My best guess...: _pcs_data is Apple's internal Protected Cloud Storage record, used to wrap the encryption keys NSPersistentCloudKitContainer needs before it can write anything to a zone (automatic for any CoreData/SwiftData + CloudKit app, independent of whether any schema field is manually marked "Encrypted"). If that record fails to save, the zone can never finish initializing, which produces exactly the "never successfully initialized" error above. Since Development works fine and Production fails identically for two completely unrelated Apple IDs on the same container, the broken PCS/key-wrapping state appears to live on this container's Production environment itself, not on any one account. What I've tried so far: Entitlements verified correct via codesign -d --entitlements :-, 4 separate times across different signing/provisioning states (Production icloud-container-environment, correct container/team, CloudKit + CloudDocuments services) Push Notifications / aps-environment: added, enabled on the App ID, provisioning profile regenerated — no effect, and confirmed not required for the core mirroring path anyway Schema deployment: CloudKit Dashboard "Deploy Schema Changes to Production" shows an empty diff (0 record types/indexes/security roles) — Production already matches Development exactly No fields marked "Encrypted" in any record type iCloud app permission for this app confirmed ON in System Settings iCloud Keychain "Sync this Mac" toggled off then back on — no effect Exactly 1 iCloud container assigned to the App ID, no duplicates Tested on 2 Macs, 2 networks, 2 unrelated Apple IDs — identical failure every time Development environment works perfectly on every test, including a 31.5MB audio asset upload Advanced Data Protection toggled on then off — no effect CloudKit Dashboard "Reset Environment" — not offered for Production (Apple restricts this to Development only) How to Reproduce: I built a minimal (~150 line) SwiftData + CloudKit project using the same bundle ID, team, and container as my real app: a single @Model class with one field, ModelConfiguration(cloudKitDatabase: .automatic), and a button that inserts and saves a record, observing NSPersistentCloudKitContainer.eventChangedNotification and displaying any error in its own UI. Archived and exported with Production entitlements (not a Debug run), it reproduces the same failure family while working perfectly in Development. Happy to share it if useful. What I'm asking for: This is 100% reproducible, isolated to Production for this specific container, and reproduces under two unrelated Apple IDs with every client-side configuration verified correct. Has anyone else seen _pcs_data RecordSave fail with BAD_REQUEST in Production only? Is there a known fix, or does this need Apple to inspect/reset the server-side PCS state for this container's Production environment? Related threads: I found a couple of related threads while searching before posting this. In Handling CKError.partialFailure with pcs_data errors, an Apple DTS engineer (Ziqiao Chen) explained that _pcs_data/BAD_REQUEST is normally transient and that NSPersistentCloudKitContainer retries automatically, so it usually isn't worth worrying about. That matches what I'd expect for an occasional blip — but in my case it's 100% reproducible, permanent, and blocks every save, which seems like a real deviation from that expected behavior rather than routine noise. I also found a CKShare thread with the exact same signature (RecordSave / BAD_REQUEST / returnedRecordTypes: _pcs_data in a Production private database) that appears to be unresolved, so I don't think I'm the only one hitting this.

I have a macOS app using NSPersistentCloudKitContainer with separate private and shared persistent stores and zone-wide CloudKit Sharing. The same Core Data model and sharing implementation work correctly in Development: the complete object graph is shared and bidirectional owner/participant synchronization works. In Production, however, sharing is stuck in a partially exported state. The owner has a complete and internally consistent Core Data object graph. fetchShares(matching:) reports the expected managed objects as belonging to the Production share. However, inspection of the Production shared CloudKit zone shows that many of the corresponding CKRecords were never exported. For example, the participant successfully imports records that actually exist in the shared zone, but entire expected record types such as CD_Missionary and CD_Area are absent from that zone. The Production owner's private persistent store repeatedly reports failed setup/export events. The relevant Core Data + CloudKit log pattern is: Never successfully initialized and cannot execute request due to error: CKErrorDomain Code=2 with an underlying: CKInternalErrorDomain Code=1011 I also correlated multiple failed Core Data export events with CloudKit server logs. Within seconds of the failed exports, CloudKit reports: Database: PRIVATE Operation: RecordDelete Overall Status: USER_ERROR Error: BAD_REQUEST Returned Record Type: _pcs_data The failure is reproducible across multiple export attempts. The Production shared zone itself exists and has zone-wide sharing enabled. The expected cloudkit.share record type is present in Production. I compared the visible Production and Development schemas, including cloudkit.share, and found no obvious record-type/field discrepancy. The important comparison is that Development sharing with the same model/implementation works correctly, while the existing Production mirroring/share state repeatedly fails. I have filed Feedback Assistant report FB24739413, including a sysdiagnose captured while the failure was active, Core Data/CloudKit event diagnostics, CloudKit server-log request IDs, store identifiers, zone information, and reproduction details. My main question is about recovery rather than diagnosis: What is the supported way to recover an existing Production NSPersistentCloudKitContainer share/mirroring state like this and cause the missing managed objects to be exported, without deleting or purging the owner's managed objects? I have deliberately not reset the Production environment, deleted/recreated the share, purged the shared zone, reset the owner's persistent store, or mass-modified the managed objects to try to force re-export. In particular, I understand that purgeObjectsAndRecordsInZone can delete the corresponding managed objects, so I do not want to use destructive recovery techniques without guidance. Is there a supported mechanism for rebuilding/reinitializing the Production mirroring/share state while preserving the owner's existing Core Data object graph, or is this a situation that requires intervention/instructions from Apple? Environment macOS 26.6.2 Core Data + NSPersistentCloudKitContainer CloudKit private + shared persistent stores zone-wide sharing Production failure only Development sharing works correctly Feedback: FB24739413

Hi, I’m trying to access my own iCloud Contacts via CardDAV from a self-hosted web application. Apple’s documentation still states that app-specific passwords can be used for third-party access to iCloud Contacts when the app does not support Apple’s newer authorization flow. However, authentication currently fails consistently with HTTP 401 at the very first CardDAV request. Setup: Apple Account with 2FA enabled correct Apple Account ID / iCloud address freshly generated app-specific password CardDAV endpoint: https://contacts.icloud.com/ HTTP Basic Auth read-only PROPFIND requesting current-user-principal I have reproduced the same result with three independent clients: my own PHP/libcurl implementation a minimal direct cURL/libcurl reference request vdirsyncer 0.21.0 vdirsyncer fails during discovery with: 401 Unauthorized https://contacts.icloud.com/.well-known/carddav In my direct request, Basic Authorization is definitely sent and the server responds 401 before any redirect or personal CardDAV shard discovery occurs. I have also verified: no username mismatch no redirect/auth-header loss no HTTP/1.1 vs HTTP/2 issue no password transformation by the application a fresh app-specific password was copied directly from Apple and tested immediately Interestingly, direct CardDAV access for this same project/account worked previously, so CardDAV itself has worked for this account before. Has anything changed recently regarding authentication to iCloud Contacts/CardDAV? Specifically: Are app-specific passwords still expected to authenticate directly against contacts.icloud.com? Is there any additional account setting or authorization required now? Is .well-known/carddav still the supported discovery route? Is Apple’s newer “Account Data Sharing” authorization available to independent/self-hosted applications for iCloud Contacts, and if so, is there developer documentation for that flow? I’m deliberately not asking about writing contacts yet — this is only a read-only CardDAV authentication/discovery test. Thanks for any pointers. Cheers, Vince

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.