Choosing CloudKit
Drafts 4 will use Apple’s new CloudKit services for sync.
Brent Simmons and Tim Schmitz have done a good job covering developer perspectives on selection of backend service dependencies. Scalability, longevity, security, etc. are all factors that have guided decisions about the future of sync and Drafts.
Honestly, CloudKit is not the right choice for the vast majority of apps. CloudKit will limit my deployment options to Apple platforms. At least for the time being, it will not allow me to move any logic to the cloud.
Choosing CloudKit was not the easy choice. The current version of Drafts uses the Simperium sync service, and my experience with the service has generally been a good one. Sticking with it would have required the least effort on my part. I have also deployed iCloud-Core Data in Terminology and Phraseology and have been pleased with the ease of deployment (since iOS 7 only!). Both Simperium and iCloud-Core Data lacked the level of control I wanted for some of the new features I’m adding to Drafts though, so it was time to move on.
CloudKit was not the easier choice from a client-side development perspective. This is new technology. There is not a lot of sample code, there are bumps in the road – and as a purely client-side technology, there are not things I can keep on the server side to more efficiently manage and update code.
I’m glad choosing CloudKit removes the need for me to manage servers or engage another third party service to do so, but that is not why I chose it. I’m not afraid of servers.
Why am I willing to make these trade-offs for CloudKit, despite it’s limitations? Because, ultimately, developer perspectives aside, I felt it was the right choice for my customers.
They will not need to setup another account with yet another set of credentials to manage. More importantly, their data will be stored with Apple, a vendor they have already choosen to trust. It will be stored in siloed, private data stores that not even the developer can access. That cannot be said for apps using Azure, Parse or other backend services.
Only time will tell if this is a wise choice, but for my particular app I feel very good about the decision.