CloudKit Public database support

[malhal]

Personally I don't really see the need for private database support since we already have iCloud Core Data storage which does the same thing. Public on the other hand introduces many opportunities. Can't you use queries for higher change tag or modified time to enable you to do the sync without the requirement for custom zones and change requests?

[nofelmahmood]

Maybe you are right but according to my experience iCloud CoreData Syncing is too slow and has its own problems and at the same time its closed sourced. You cannot control/change the sync process in any way. Seam gives you more control and that may increase as the project becomes more mature. Also that CloudKit is now being used in core apps for iOS like notes, reminders etc which in my opinion shows and assures that its The Future.

I am already considering adding the public database support but there are many limitations in the CloudKit Api to implement it as of right now. Yes I can use queries and change tags or something like that but atomic commits is also a very important feature in assuring that the records on the CloudKit servers are not left in an inconsistent state which is not supported for the public database as of right now.

Still I look forward to try implementing it once I am finished upgrading the project to support swift 2.0.
Thanks for your interest in the project. Stay tuned :)

[malhal]

Thanks another thing I forgot to mention is a limitation with the iCloud Core Data is there is no option to sync partially, its all or nothing. I was wondering if you could consider making the trigger sync take a predicate to allow it to sync down only a subset of the data. For example imagine syncing down only the annotations for the current map's view rectangle.

[nofelmahmood]

Well lets put it this way that what if Seam allows you to choose the entities of the CoreData model that should be synced with CloudKit.

[nofelmahmood]

I think you should open an another issue to discuss that :)

[chrislconover]

@malhal & @nofelmahmood:

Has it been confirmed that one cannot use the Apple-provided iCloud / CoreData solution for public databases? I cannot find any explicit declaration for that, but it is suggestive since they present the topics in different sections.

It does seem that the two reasons given for not supporting public data are not blockers - that they only allow one zone and don't allow batch commits as there would be a lot of blocking on the server, from what I can surmise.

Thanks!

[mingsai]

One way to use the public database is to create user subscriptions for objects stored on that database. When invoking the subscription be sure to set the notification to nil so that users won't see notifications popping up everywhere (unless desired). This way the public database will sync shared data on each application. Adding such support would make this an ideal wrapper imho.

[malhal]

Apple's News app works with a public database with a sort-of-sync. How they achieve it is the articles are given an integer property "order", e.g. 1483365231601, the client queries using a min order and max order, and ordered by order. This however is only a read-only append and only one client (Apple's server) is inserting new records, so not a real sync. A full sync (i.e. with client writes and deletes) on the public database with the current API is impossible, you might get close using modification dates but then when you start trying to use references it will become apparent.

Another interesting thing about the News app is it also uses a private database for bookmarks and history but previously we had been told not to use CKReference across zones or databases, however all they do is reference using a article ID string instead, which is fine given they don't need any of the referential integrity features.