CKSyncEngine doesn't fetch changes when saving or deleting CKShare

[AllanJuenemann]

I've noticed that saving a CKShare using CKDatabase directly or deleting a CKShare via UICloudSharingController doesn't cause CKSyncEngine to fetch new changes (nor include them in updates when you call CKSyncEngine.fetchChanges) until the app is relaunched.

Is there a recommended way for dealing with CKShare together with CKSyncEngine?

[thevarsek]

I noticed this too, interested in the answer

[thevarsek]

@AllanJuenemann

Worked out a workaround with Claude 4.6: Direct CKQuery fallback for shared database records

We hit this exact issue in our production app (iOS 17+, CKSyncEngine, CKShare for sharing records between users). After extensive debugging, here's what we found and how we worked around it.

Root cause on the owner's side:
On the owner's device, the shared baby's CKRecord lives in the owner's private zone. CKSyncEngine saves it to the private database successfully, but the change never propagates to the participant's shared database view. The owner cannot write directly to sharedDatabase either — from the owner's perspective, the shared DB only contains zones that other users have shared with them.

We tried re-saving the record via privateDatabase.modifyRecords() after the private engine confirmed the save (directPushToSharedZone). The API call succeeds with no errors, but it still does NOT force CloudKit to propagate the change to participants' shared database. The bug appears to be deeper than just CKSyncEngine — it's in CloudKit's server-side propagation for CKShare.

The workaround that actually works: fetchSharedRecordsDirect()

On the recipient's device, instead of relying on CKSyncEngine's broken shared database change feed, we query the shared database directly using CKQuery:

// For each shared item, query the shared database directly
let predicate = NSPredicate(format: "itemId == %@", itemId.uuidString)
let query = CKQuery(recordType: "Event", predicate: predicate)
query.sortDescriptors = [NSSortDescriptor(key: "updatedAt", ascending: false)]

// CRITICAL: Use cursor-based pagination. Default CKQuery limit is 100 records.
var allRecords: [CKRecord] = []
var cursor: CKQueryOperation.Cursor? = nil

// First page
let (results, firstCursor) = try await sharedDatabase.records(
matching: query,
inZoneWith: sharedZoneID,
resultsLimit: 200
)
allRecords.append(contentsOf: results.compactMap { try? $0.1.get() })
cursor = firstCursor

// Continue with cursor until no more pages
while let currentCursor = cursor {
let (moreResults, nextCursor) = try await sharedDatabase.records(
continuingMatchFrom: currentCursor,
resultsLimit: 200
)
allRecords.append(contentsOf: moreResults.compactMap { try? $0.1.get() })
cursor = nextCursor
}

// Compare remote updatedAt/isVoided against local GRDB data
// Import new records, update existing ones when remote is newer

Key details:

• We call this at the end of every sync() invocation (on app foreground and pull-to-refresh)
• Cursor-based pagination is essential — the default CKQuery limit is 100 records, which silently drops anything beyond that
• We compare updatedAt timestamps and isVoided flags rather than just checking existence
• We use soft delete (isVoided = true) instead of CKRecord deletion to avoid issues with CloudKit's deletion tracking
• We batch local DB reads (one query per baby) instead of per-record to avoid N+1 performance issues
• Sort by updatedAt DESC so newest changes come first

What works and what doesn't:

Direction	Works?	Mechanism
Participant → Owner	Yes, near-instant	CKSyncEngine shared engine handles this correctly via silent push
Owner → Participant	Yes, with workaround	fetchSharedRecordsDirect() CKQuery on app foreground / pull-to-refresh
Participant → Owner (delete/void)	Yes	CKSyncEngine shared engine
Owner → Participant (delete/void)	Yes, with workaround	fetchSharedRecordsDirect() detects isVoided diff

Our parent hierarchy: CKShare → ItemShare (root record) → Item → Event with action: .none on all parent references.

It's not ideal (changes only appear when the recipient opens the app or pulls to refresh), but it's reliable. Hope this helps others hitting the same issue.