Brent Simmons blogged a response to my question about dependencies for apps, and he outlined a number of questions developers should consider when choosing a web service:
How long will this service be around? How difficult would it be to move? How much of this service’s unique features do I use? How much benefit do I get from those?
This extends to software, too. What is a given package’s reputation for security? Is it likely to be maintained in the future? Will upgrading to get a security fix also mean revising some of my code?
You have to plan for scale. Will this service and and those software packages allow room for growth? (Sharding, running multiple instances, etc.)
That got me thinking about how CloudKit fits into this picture. As an iOS developer, CloudKit is immensely appealing at first glance. The API is low-level enough that you have a good deal of control over how your app interacts with the server. At the same time, you get a lot of server-side functionality for free, which leaves you with more time to focus on building a great app. But I still have a lot of misgivings about it. I’m going to go through some of Brent’s questions with regard to CloudKit, changing the order a bit here and there when it makes sense.
How long will it be around? Is it likely to be maintained in the future?
I have to say this is an area where I don’t have a lot of confidence in CloudKit. Although Apple’s cloud services have improved somewhat over time, they’ve also gone through a lot of incarnations. Moreover, Apple has a tendency to lose focus on products that aren’t a huge success, and encourages developers to move to the latest and greatest tech. If CloudKit isn’t a big success, I’m not confident that Apple will continue to pour resources into improving it. Past experience leads me to worry that they’d spend more time building a replacement system and promoting it to developers.
What is a given package’s reputation for security?
This is a strong point for Apple. Although CloudKit is a new product, both security and privacy are clearly important to the company. No system is completely secure, but I don’t have any more concerns about security in CloudKit than I would with Azure or any other competing service.
Will this service and and those software packages allow room for growth?
This is a tough question to answer. CloudKit is a fairly opaque box in terms of implementation, so it’s difficult to say how well it would scale. Apple clearly has vast resources at its disposal if it chooses to use them, but the fact remains that developers probably won’t get a whole lot of information about how CloudKit scales. It’ll either scale without us having to do anything, or it won’t. Even the storage and data transfer limits are unclear beyond the free tier. The documentation lists the usage you get for free with each app and additional user, but then simply says, “If you need more capacity than the limits listed above, contact us.” That’s hard to plan for.
How difficult would it be to move?
For me, this is the killer. As it stands now, it seems that it would be incredibly hard to move a CloudKit-based app to another platform. There is simply no obvious way to move data en mass from CloudKit to any other service. Maybe this is possible and Apple just hasn’t discussed it publicly, but as a developer, I need more certainty than that. Maybe CloudKit will work wonderfully for many years to come. But maybe it won’t, or maybe I’ll eventually want to do something that CloudKit doesn’t support. For those and a host of other reasons, I can’t imagine building critical aspects of my app around a service that doesn’t let me have a backup plan.
Brent talks a bit in his post about choosing Azure for Vesper. Of course, CloudKit wasn’t available when they were adding sync to Vesper, but I imagine the decision would have been the same regardless. CloudKit sounds like a great option for some kind of incidental feature, but not for anything central to the app experience.