Early last fall, I wrote a post about the strengths and weaknesses of CloudKit as a back end for iOS apps. In part, I was inspired by a post by Brent Simmons, and Greg Pierce chimed in about why he chose to build the sync service for Drafts on CloudKit. At the time, I had some reservations about CloudKit, but it was also too early to say much for certain. A lot has changed since then, and my views on CloudKit have shifted significantly in favor of using it.

One of my concerns last year was that CloudKit might not gain wide adoption, and then quickly be abandoned by Apple. I think it’s now safe to say that won’t happen. Apple has pretty much gone all in on CloudKit with their own apps, including cornerstone apps like Photos. That alone is enough to ensure CloudKit’s longevity. Moreover, CloudKit seems to be reasonably popular among iOS developers for many of the reasons that Greg outlined in his post. Unlike some of it’s predecessors, CloudKit should be with us for a while.

The other, bigger concern was that apps were pretty much the only interface to CloudKit. If I needed to migrate data away from CloudKit, I’d have to write an iOS or Mac app to do it. Moreover, there was no way to build a web interface to a CloudKit-based app. That all changed at WWDC 2015 when Apple introduced CloudKit JS and CloudKit Web Services These provide a lot more flexibility, and for me, piece of mind. Although I’ll almost certainly start using CloudKit exclusively through apps, an having an HTTP interface means I can expand in the future if I feel the need. Even if I never end up doing anything with it, it’s nice to know I have options.

I remember thinking last year that there were just a couple of smallish hurtles before I’d be totally comfortable adopting CloudKit. In 2015, Apple has cleared them with room to spare, and I’m confident in saying I’ll use CloudKit next time I need to build a sync service for an app. (Hopefully before too long – but more on that later.)