Search code examples
iossynchronizationcloudkitcksubscription

How to use database subscriptions correctly when using CloudKit sharing


I'm working through how to handle CloudKit sharing and database subscriptions and I need help understanding how Apple envisions us using subscriptions and CloudKit sharing together given the properties and delegate methods we have available.

This thread is very similar but doesn't bring sharing into the equation and is a bit different functionality-wise than what I have set up.

Setting up the subs is the easy part. If there's no subscription, set one up. And if the owner stops sharing there's a delegate method that gets called so you can just delete all subs except your own. My problem comes in when a participant leaves a share. The subscription associated with that person should be deleted, but they now don't have access to the shared database to do it. And I see no way to associate a subscription with a participant ID. The only way I can figure out how to do this is basically what is mentioned in that other thread. Create a new Subscription recordType that indexes participant id to subscriptions id.

Conceptually I had this backwards and had assumed each user would be responsible for their own subs. Using a new recordType flips that so the share owner is responsible for all the subs.

Is this really the way to do it? Anyone who uses sharing runs into this so I had thought there should be some way to handle it without creating another recordType?


Solution

  • I misunderstood something very basic and important. For some reason I had it in my head that subs for shared databases actually lived on the owner database, and when sharing stopped they would lose access to the database and wouldn't be able to delete their own sub. That's not the case (obviously?), as you can only see your own subs, and the owner can't see any subs of participants.

    When sharing stops you lose access to the CKShare record, but you still have access to your sub on the shared database. So it's trivial to delete it when needed - if the owner was responsible it would be more involved (as I was thinking above).