I’m working on my first app and I wanted to add someone to TestFlight to help me test it. I submitted it for review and it was rejected because it’s asking for demo credentials. However, my app doesn’t use any credentials at all. It is fully local, doesn’t communicate or send any telemetry to any servers. The only servers it hits is Gmail and iCloud, if the user chooses to connect their mailboxes, and for backups to iCloud Drive. do I reach out to them and tell them that this app doesn’t need credentials or do I create a demo mode of the app and resubmit?

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?

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

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?

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?

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

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.

We have a production CloudKit container where every CKQuery against one specific user's private database returns zero records with no error. The records are present and readable by other means. In a single app launch, against the same private custom zone on that account: CKQuery, NSPredicate(value: true) 0 records, no error CKFetchRecordZoneChangesOperation 2275 records (231 Inspection, 2040 InspectionPhoto, 2 Job, 2 cloudkit.share) Queries return zero for every record type, in both the default zone and the custom zone, and with both NSPredicate(value: true) and a field predicate on an indexed queryable field. Account status is .available and userRecordID resolves normally. No client change preceded this. Other users on the same container and the same binary are unaffected. The user did not delete anything; the trigger appears to have been an unexpected iCloud sign-out mid-session. The same account's private default zone additionally cannot be enumerated at all: CKError.serverRejectedRequest (15) "AppDefaultZone does not support getChanges call" CKInternalErrorDomain code 2027 We understand getChanges is not supported on the default zone. Noting it because our Company record type lives there, so its state cannot be verified by any index-free path, and an empty query result there is uninterpretable. This looks like the container index loss described by DTS in thread 775063 ("I ever saw some CloudKit containers losing their indices, and so a query to the container may not return the right result set"). Filed as FB24641992 with a full diagnostic log attached, including the container identifier, team identifier and the affected user record ID. We have shipped a client-side workaround that falls back to zone enumeration whenever a query returns zero, so the user is unblocked, but the index is still broken and that account now runs entirely on fallback paths. Question: is there a way to get a container re-indexed for a specific account, and is there anything we can do client-side to detect or avoid this state? We could not produce a focused sample project for a code-level support request because the fault is server-side account state, not client code — the same calls on a healthy account in the same container from the same binary return matching results.

I am building a training app for endurance athletes and I am trying to get the storage design right before I write it. Guideline 5.1.3(ii) says an app "may not store personal health information in iCloud", but I cannot find anywhere that defines what falls under that phrase, and the HealthKit documentation does not mention iCloud at all. The app records workouts from Bluetooth sensors (power, speed, distance, elevation, GPS, heart rate). With permission it also reads HRV, resting heart rate and sleep from HealthKit, and calculates a daily readiness value from them. I would like to keep the app's own records in my own CloudKit container so the user sees them on their iPad. Three things I cannot resolve from the documentation: Is a developer's own CloudKit container — private or shared database — "iCloud" for the purposes of 5.1.3(ii)? Does 5.1.3(ii) apply to physiological data the app measures itself from a Bluetooth sensor and never writes to HealthKit — for instance heart rate during a workout? Is a value derived from HealthKit samples, such as a readiness score computed from HRV, resting heart rate and sleep, "personal health information" even though it is not itself a HealthKit sample? I am aware that HealthKit already syncs a user's own data across their devices, so I do not intend to mirror HealthKit samples. My question is about the app's own records and derived values. Any pointer to documentation I have missed would be very welcome.

I'm trying to review whether my database files are actually populating to the CloudKit private database. For Private and Shared databases, I get a message that I need to sign in again. I do sign in again, but this message never goes away. I have also tried acting as iCloud User. When I enter my iCloud user id and password, I get an authentication error.

Hello, I am building an iOS app that uses NSPersistentCloudKitContainer with a two-store configuration (.private + .shared), following the "Sharing Core Data objects between iCloud users" sample. Sharing works in one direction only: the owner's records reach the participant, but nothing the participant writes is ever exported. I have spent a full day isolating this and have ruled out every cause I can think of. I would appreciate guidance on what else to check, or confirmation that this is a limitation I have misunderstood. I have deliberately kept the details below complete, because the interesting part of this report is not the failure itself but everything that has already been eliminated. Environment Xcode 26.6 (17F113) Owner device: iPhone 15 Pro, iOS 26.5.2 Participant device: iPhone 13 mini, iOS 26.0.1 Two devices, two different iCloud accounts CloudKit container: iCloud.com.onton.quipuledger, Development environment NSPersistentCloudKitContainer with two stores: private.sqlite — databaseScope = .private shared.sqlite — databaseScope = .shared Both created exactly as in the sample (the shared description is a copy() of the private one, with a new NSPersistentCloudKitContainerOptions whose scope is .shared) Both stores have NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey set viewContext has transactionAuthor, mergePolicy (NSMergeByPropertyObjectTrumpMergePolicy) and automaticallyMergesChangesFromParent = true What works The owner calls share(_:to:) with a set of objects and gets a CKShare. The owner sets publicPermission = .readWrite, saves the share via CKDatabase.modifyRecords, then calls persistUpdatedShare(_:in:). The participant accepts the invitation link. All shared records arrive correctly in the participant's shared.sqlite (164 objects), and subsequent owner-side changes continue to arrive. Import events succeed. What fails Every export from the participant's .shared store fails, regardless of what is written. On the participant device: New object assigned to the shared store via context.assign(_:to:) → never exported Update to an existing record that arrived from the owner → never exported Both are saved successfully to the local store (verified by reading the sqlite file) and appear in the persistent history The corresponding NSPersistentCloudKitContainer.Event reports: type: .export succeeded: false error: NSCocoaErrorDomain Code=134060 userInfo: [:] // completely empty — no underlying error countAffectedObjects: 0 Reading the store's internal metadata tables shows the export never begins: ANSCKEXPORTMETADATA — empty (no history token was ever recorded) ANSCKEXPORTEDOBJECT — 0 rows ANSCKEXPORTOPERATION — 0 rows Meanwhile the same device's .private store exports successfully, and the owner device's .private store (which holds the shared zone) exports successfully as well. What I have ruled out Permissions. On the participant, share.currentUserParticipant reports permission == .readWrite, role == .publicUser, acceptanceStatus == .accepted. Record types. All types exist in the Development schema (verified in CloudKit Console). I also ran initializeCloudKitSchema() to be certain. Server-side rejection. The CloudKit Console Logs show no errors at all — the request never reaches the server. The records themselves. Failure is independent of content: a single entity with no relationships fails exactly like a multi-object graph. Association with the share. fetchShares(matching:) on the participant returns the correct share for the record, with the correct zone name and owner name. Core Data does know the object belongs to the shared zone. Corrupted mirroring metadata. Deleting and reinstalling the app on the participant device reproduces the problem from a clean state. CloudKit itself refusing participant writes. Using the raw CloudKit API on the same device, I saved a CKRecord directly into the same shared zone — this succeeded, and the owner device received a push notification for it. So the account, the zone, the permissions and the record type are all fine; only the Core Data mirroring path fails. Question Given that Core Data correctly associates the object with the share, and that the same device can write to the same zone through the raw CloudKit API, why would the mirroring delegate never schedule an export for the .shared store? Specifically: Is exporting participant-side changes from a .shared store supported by NSPersistentCloudKitContainer? The sample project demonstrates share management and owner-side writes, but I could not find an example of a participant creating or modifying objects in the shared store. If it is supported, what would cause NSCocoaErrorDomain 134060 with an empty userInfo and zero affected objects? Is there a way to obtain the underlying reason? (-com.apple.CoreData.CloudKitDebug 1 produced no additional output for me when the app was launched via devicectl.) Is there any additional setup required on the participant side beyond accepting the share — for example, does a newly created object need to be related to an object that is already part of the share in order to be exported? Thank you very much for your help.

Since approximately 03:11 UTC on 2026-08-28, every CloudKit private-database write from my iCloud account fails. The app had been syncing normally for weeks before this moment. Failure signature: Every record save returns HTTP 500 with an empty response body (Server: AppleHttpServer, via icloud-xrail). Client-side error: CKErrorDomain 15 (Server Rejected Request) with underlying CKInternalErrorDomain: 2001. Reads succeed. CKContainer.accountStatus reports available. Authentication is fine. Only writes fail. Reproduces identically via NSPersistentCloudKitContainer mirroring and via a raw CKModifyRecordsOperation probe. Device: iPhone 15 Pro Max, iOS 17.2.1. Development environment, private database. Evidence this is account-scoped server state, not app configuration: It reproduces identically in two containers: the original production container and a freshly created container set up after the failures began. A brand-new container failing the same way rules out container-specific corruption or schema issues. Entitlements, embedded provisioning profile, and App ID iCloud capability have all been verified correct (codesign inspection and App Store Connect API). No code or configuration change coincided with the onset. The failure follows my Apple ID across probes over many hours. Every write 500s, without exception. Correlating event: the legal name on my Apple Account was changed at account.apple.com the same morning, shortly before the failures began. I cannot prove causation, but the timing is exact, and the account-scoped, writes-only signature is consistent with a wedge in the account's server-side state (PCS / user-record layer) introduced by the identity change. I request a check of this account's CloudKit/PCS state. Sample failing request UUIDs (x-apple-request-uuid) for locating these in server logs: 244DA811-E4AA-4771-88F0-7C092EFD8DEF, 2026-08-28 ~09:57 UTC 1FD544D6-6ED2-4181-8976-B4F4C35830D9 E55EFF8F-FC32-48BD-9165-F4EA263F130A Many more available on request. The app logs every attempt. Related reports: this appears closely related to thread 843819 (same week, same signature: private-db writes CKError 15 / HTTP 500, fresh container also affected, Console works), and possibly to the recent cluster of private-database reports in threads 838743, 840248, and 839650. Please correlate rather than triage in isolation. Impact: this blocks shipping a family-sharing feature built on CKShare, the purchase-deciding feature of the app. All development on sync is stopped. I can supply on request: a CloudKit sysdiagnose captured during a failing save (per TN3163), additional request UUIDs with timestamps, and the exact local timeline of the account name change.

Hi, I’m running into a strange CloudKit issue and I’m trying to figure out whether this could be related to the China mainland iCloud environment, or whether I’m missing something on the client side. I’m testing on macOS with Xcode 26.6, using the CloudKit Development environment and the Private Database. The Apple Account signed in on the Mac is a China mainland account, and CKAccountStatus reports available. The original container is: iCloud.com.hu.sujian With that container: I can create a custom zone in CloudKit Console. The app can save a normal CKRecord to the Private Database default zone. But the app consistently fails when creating a custom CKRecordZone. The error is: CKErrorDomain Code=15 (serverRejectedRequest) Underlying CKInternalErrorDomain Code=2000 I also opened DTS case 21678909 and filed FB24394907. As part of the DTS investigation, I created a completely new CloudKit container: iCloud.com.hu.sujian.dtstest21678909 I then repeated the same tests using the same Apple Account and the same minimal test app. On the new container, both of these app-side operations fail: Saving a CKRecord to the Private Database default zone CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: D4B4DC7A-4167-4987-8BB1-4C61E658EDB6 Creating a custom CKRecordZone named SujianLibrary CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: 00B4A294-9C63-4DBC-9133-03D969536B73 However, if I open CloudKit Console for that same new container, I can create a custom Private Database zone successfully. I created: DTSConsoleTest21678909 and it shows up normally as: REGULAR_CUSTOM_ZONE The code is very small. The relevant paths are essentially: let container = CKContainer(identifier: containerIdentifier) let database = container.privateCloudDatabase let record = CKRecord(recordType: "DTSWriteTest") record["message"] = "test" as CKRecordValue try await database.save(record) and: let zone = CKRecordZone(zoneName: "SujianLibrary") try await database.save(zone) What confuses me is that CloudKit Console works, while the app receives an HTTP 500 from the CloudKit service. The behavior also changed slightly between the two containers: Original container: default-zone record write from app: works custom-zone creation from app: fails custom-zone creation in Console: works New container: default-zone record write from app: fails custom-zone creation from app: fails custom-zone creation in Console: works FB24394907 contains the full reproduction details and logs. Has anyone seen something similar, especially with a China mainland iCloud account? I also have a small standalone reproduction project if that would be useful. Thanks.