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.
0
0
78