Hello,
We have a CloudKit-based sharing feature where an app owner shares a single record hierarchy (one CKShare in a dedicated CKRecordZone) with one external recipient. The recipient does not necessarily own an Apple device — they open a link in a browser on a website and authenticate via Sign in with Apple using CloudKit JS, then read and write a small subset of fields.
The shared data is sensitive (health-related), so we evaluated CKRecord.encryptedValues for the sensitive fields. Our understanding is that encrypted fields are not accessible through CloudKit JS / CloudKit Web Services — only through the native frameworks or CKTool JS. If that's correct, using encryptedValues would make our web recipient flow impossible.
Our questions:
-
Is that understanding still accurate for the current CloudKit JS version, or is there a supported way to read encryptedValues fields from a browser-based CloudKit JS client?
-
If not: for this kind of sensitive-but-web-accessible data, is relying on CloudKit's standard encryption (in transit and at rest) the intended approach, or would you recommend a different architecture — for example encrypting the payload ourselves before writing it and passing the key out-of-band with the share link?
-
Is there any guidance on enforcing a time limit on a CKShare? We currently expire shares client-side, but that only works while the owner's app runs. Is there a server-side mechanism (or a recommended pattern) for shares that should expire automatically?
-
We enforce "only one recipient per link" by setting share.publicPermission = .none client-side as soon as the owner's device observes an accepted participant. We found that if the accepted participant's own access had only ever been granted through publicPermission (not as an explicitly invited participant), revoking publicPermission this way also revoked that same participant's write access (CKError "Zone not found" on their next saveRecords call from CloudKit JS) — until we explicitly set participant.permission = .readWrite on the already-joined CKShare.Participant before nulling publicPermission. Is this expected/documented behavior, or is there a more official API pattern for "convert a public-permission joiner into a permanent named participant, then close the link"?
Thank you!