So, It was 2014 and Apple tried its best to buy Parse. Failing at it, they did what they do most of the time. They built their own “Parse” from the ground up and then closed it to Apple Platforms which they released on WWDC 2014. The developers who went through the WWDC 2014 CloudKit Session Videos were convinced, including myself that it’s awesome. Brent Simmons even did a blog post on it and his remarks were
“First off — holy shit.”
And rest of the developers were also like.…
Then the hype went down. Developers did a sanity check and tried to let their dreams of becoming a millionaire live, by porting their iOS or Mac Apps to Android in the near future. And so CloudKit was not adopted that much because of it’s competitors like Parse, Firebase etc who provide the same functionality with more features and at the same time they’re cross platform.
Being an Indie developer I also had the same thoughts on using Parse so that I can develop an Android version of my app too. That gate is always open. But the one thing that always held me back on using CloudKit was the “no sign in feature”. Apple users most of the time have signed up for iCloud on their devices using their Apple ID and so if you use CloudKit there’s no need to authenticate the user again.
So, yes that’s the one thing that makes a huge difference for the user. It feels like the user is using just another app belonging to iOS like Notes, Reminders etc. And so it increases it’s chances of being used. User feels at home and so we as developers must take the responsibility to keep users first in anything we develop because that is what we do and that is what we live for. We want to delight our users with the stuff we make by sacrificing our time, so that we can contribute in making their life easier.
And so I decided to go with CloudKit. The first hurdle I faced was sync. CloudKit allows us to transfer data between our app and the CloudKit Servers. That’s it. Its the developer’s responsibility to provide the local cache and sync support. I had worked on CoreData a lot and to be honest I loved it. Every developer knows that CoreData comes with its own complications but at the same time most of them do agree that 90% of the time its the answer for your app.
The birth of CKSIncrementalStore
CoreData is a great ORM. Lucky me ! I had read NSHipster’s article on NSIncrementalStore. The class that allows to plugin any store type to CoreData by just subclassing and overriding a few methods (Well, its not that easy though). So I went on and wrote the CKSIncrementalStore.
CKSIncrementalStore manages its own private NSPersistentStoreCoordinator which has an Sqlite store type added to it. It fulfills all the data requests from the sqlite store, while at the same time, keeping it in sync with the data on the CloudKit servers. So any time a record gets added , removed or modified, the changes are propagated to the CloudKit servers and the changes on the servers are committed back to the Sqlite store. CKSIncrementalStore lets you know when it starts and finishes syncing, by throwing two notifications. You can observe them in code and refresh your objects when it finishes.
Conflict Resolution
Where there is sync there are conflicts and where there are conflicts there is CKSIncrementalStore to save you from its inflicted wrath.
CKSIncrementalStore supports Sync conflict resolution policies out of the box.
Seeing is believing
Update : CKSIncrementalStore has been merged into a new framework called Seam. Please check out the new framework on Github for detailed info.
So now go on and power your apps with CloudKit reusing the knowledge you already have of CoreData and amaze your users with what you build.
