An optional coaching feature in my planned app would, after explicit opt-in, send a short text summary (for example sleep duration or heart rate variability over the last week) to a third-party AI service to generate advice for that same user. The data is not used for advertising, marketing or data mining. Guideline 5.1.3(i) allows disclosure of HealthKit-derived data only "for improving health management, or for the purpose of health research, and then only with permission", and DPLA 3.3.3(H) allows disclosure to a third party only with prior express consent and only to provide health, motion or fitness services. Is a per-user coaching feature like this within what 5.1.3(i) and 3.3.3(H) permit? Does it matter whether the summarised values were entered manually (and stored in HealthKit) or measured by a device? I understand this is not a pre-approval; I would like to know how the rule is meant to be read. Thank you.

I am planning an iOS app for strength training, nutrition and sleep. Before I build the data layer I would like to understand how Apple reads the following rules. Planned design: Body measurements and sleep values live in HealthKit only and are never written to iCloud or CloudKit. Training sessions and meal entries (food, calories, macronutrients, entered manually or by barcode scan) are stored on the device and in the user's private CloudKit database. Nothing is stored on our own servers. The app also caches packaged food products the user has scanned (name, ingredients, allergens, nutrition facts from the public Open Food Facts database) in the same private CloudKit database. Guideline 5.1.3(ii) says apps "may not store personal health information in iCloud", and DPLA 3.3.3(D) restricts using iCloud or CloudKit for "sensitive, individually-identifiable health information" unless Apple permits it in writing. Questions: Does a meal log or a product cache in the user's private CloudKit database count as "personal health information" in this sense, as long as no HealthKit values are stored there? Is the answer different if the private CloudKit data is end-to-end encrypted (encryptedValues)? I understand that App Review cannot pre-approve an app. I am only asking how the rule is meant to be read. Thank you.

Apple thought it was impossible. I made it possible. No server. Just an iPhone. LUMEN-JEV OS v3.0 — On-device OS using Pyto + iCloud Drive + Obsidian Architecture: Pyto runtime = server: Persistent loop, 922 tickers scanned, 502.6 ev/s, 12ms latency, sub-2ms cache iCloud Drive = bus: Writes JEV-BUS.md every 15s, shared working directory Obsidian = OS window manager: 00-JEV-DASHBOARD-main 48 nodes live Vault: 11/11 LOCKED, Factory Complete Anchor: 572b9df5e8e1f101365f8316ba7b34da4aa54ff89a2dcdb68ed20b126e8cabed Chain: REAL-EXCHANGE-PUBLIC-WS -> 8-MODULE-DEMO -> DEMO-TERMINATED -> NO EXECUTION Feed: real-public-readonly / public_ticker_only Modules (8-MODULE-v1px): WARREN-WATCHDOG, KEEPER-BOX, NODE-MODE-SYNC, VAULT-MULT, SCOUT-SCAN, SIREN-FILTER, FOCUS-SIGNAL-20K, ORACLE-PRICE-FEED, RELAY-ROUTER, AKE-ARBITRAGE, YIELD-BACK-4, MEDUSAs: 03 DYNAMIC OBSERVER-SPACE Context: Built in 33hrs over 11 nights, day job, single dad, solo dev, on iPhone only. Pyto working directory set to iCloud Drive. No Mac backend, no CloudKit function, no external server. Why this matters for iOS: Apple's sandbox says you can't run a persistent OS-like loop with live file sync on iOS. Pyto + iCloud Drive persistence proves you can. iPhone becomes the server. Proof: 48 NODES LIVE canvas PROOF CHAIN 11/11 FLAT VIEW VAULT LOCKED Jev.py V2.6 CLEAN BUS log (checked 50/100/150/200 -> 922/922 passes) Anchor hash matches zip JEV-OS-v3.0-572b9df5-40files.zip Requesting: Guidance on showcasing this as an iOS innovation + Ask Apple office hours. X proof pinned: @Activepython007

I was following the instructions of TN3163: Understanding the synchronization of NSPersistentCloudKitContainer to get a sysdiagnose from my machine (after installing the CloudKit profile for macOS) Then, I found an error message that looked interesting in the log, but it looked like this CoreData+CloudKit: -[NSCloudKitMirroringDelegate _exportFinishedWithResult:exporter:](1492): <private>: Export failed with error: Error Domain=CKErrorDomain Code=2 UserInfo={ContainerID=<private>, NSDebugDescription=<private>, CKPartialErrors=<private>, RequestUUID=<private>, NSLocalizedDescription=<private>, CKErrorDescription=<private>, NSUnderlyingError=0x768ff1ca50 {Error Domain=CKInternalErrorDomain Code=1011 UserInfo={CKErrorDescription=<private>, NSLocalizedDescription=<private>, CKPartialErrors=<private>}}}There is some problems mentioned in <private>. Those logs where from subsystem = com.apple.coredata and category = CloudKit Looking at the profile from Apple to debug this i see the subsystem com.apple.coredata was not in there. I could finally get the logs by adding to my Info.plist <key>OSLogPreferences</key> <dict> <key>com.apple.coredata</key> <dict> <key>CloudKit</key> <dict> <key>Enable-Private-Data</key> <true/> </dict> </dict> </dict>as explained in Recording Private Data in the System Log Still, it surprises me this is a problem to begin with. Should i report to Apple an incomplete debugging profile? Is it safe to keep the OSLogPreferences on for coredata/cloudkit for my app?

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.

On 25 October 2026, signing in to an Apple Account in the Simulator (Settings > Apple Account > Sign in Manually) fails on iOS 27.0 and iOS 26.5 runtimes (Xcode 27.1, macOS 27.0.1, Apple silicon), for a new account (SMS second factor) and for an established account (trusted-device second factor). The password and second-factor steps complete; then akd logs "Will check in with IDMS" and POST gsas.apple.com/grandslam/GsService2/postdata returns HTTP 401 with ec -22411, sec -42023 ("This action cannot be completed at this time"), followed by "Failed to check in with IDMS! ... AKAuthenticationError Code=-7026". Settings then says the account or password is incorrect. The host Mac checks in with IDMS successfully, and the account works on icloud.com. I need a second account in the Simulator to test CloudKit share acceptance. Is this a known issue, and is there a workaround? Feedback: FB25318712.

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.

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

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 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!