CloudKit – 没有服务器端的逻辑？
使用CloudKit ，您可以专注于您的客户端应用程序开发，并让iCloud 消除编写服务器端应用程序逻辑的需要 。 CloudKit为您提供身份validation，私有和公共数据库，结构化和资产存储服务 – 所有这些服务都是免费的，且具有很高的限制。
你不能上传任何代码在苹果的服务器上运行？
我听说它与Google App Engine和其他云计算平台相比，但没有运行自己的代码的能力，是不是有限的，没有真正的可比性？
例如，如果我想构build一个新闻应用程序，该应用程序会定期向用户感兴趣的主题推送故事，那么只能使用CloudKit，因为我需要在服务器上进行预定作业和数据处理。
有什么想法吗？
服务器端
正如你所说的，CloudKit不允许服务器端的代码。
但是有可能。
Crons
您不想每天都连接到iCloud Dashboard，以便通过添加logging来执行推送。 这里的一个解决scheme是在Mac服务器上编写一个应用程序（我猜Mac mini作为服务器会变得更受CloudKit的欢迎），每天都会添加一个新的Daily CKRecord 。
订阅
订阅概念是客户注册特定的更新。 您可以创build一个名为Daily的loggingtypes，并让用户注册。 您应该检查苹果文档和WWDC14video（即使订阅不详细，这是一个很好的起点）。
好消息是推送通知与订阅概念链接。 所以基本上你说：发送我的通知每个新的CKRecordtypesDaily添加。
BaaS派对
使用CloudKit（vs Parse等）有什么意义？
- 价格：CloudKit有一个非常好的价格
- 准备好了：在XCode里面点击2次，就可以开始了
- 用户一致性：您可以通过他们的iCloud账户免费login所有设备。 拥有一个非常好的隐私系统。 你可以和一个智能系统build立关系。
但：
- 你坚持在苹果平台上。 我们甚至不知道我们是否可以导出数据
- 目前只有以数据为中心（无服务器端代码）
- CloudKit仪表板太有限了
未来
CloudKit还是很新的。 在WWDC的一些人背后让我明白，他们仍然在努力。 我的下注是他们正在做两件重要的事情：
- 通过远程计划任务执行服务器端代码
- CloudKit for Analytics（可视化方面）
编辑：苹果家伙充分意识到并担心数据的networking访问不足。 这意味着总有一天它可以从其他平台上访问。 我读了一篇评论，如果CloudKit不好，苹果公司可能会购买Parse，但是他们试图购买Parse（技能买了它，但我们并不知道）。
更新WWDC15
CloudKit现在在JS中可用，现在有一些仪表盘可用。 等着瞧。
2016年2月更新
CloudKit现在支持服务器到服务器的Web服务请求
Web服务参考
在某些情况下 ，我们不需要服务器端的逻辑，仅仅存储静态数据就可以覆盖所有的使用场景。
在这种情况下，如果有一个可以存储的东西，那么这将非常有用。 CloudKit提供了这样的东西，而不是全面的服务平台。
是的，它是有限的。 无论如何可以有用的一些人。 例如，您的案例实际上可以被CloudKit支持。 虽然CloudKit只是一个静态存储， 但它支持订阅 。 它监视一组条件并将事件通知推送给客户端。 幸运的是，CloudKit支持的唯一后台作业function正是您所需要的。
无论如何，如果你需要更多，那么你可能需要考虑完整的服务器。 通常简单的 Web服务和简单的服务器端代码执行支持也是有限的。
你不能上传任何代码在苹果的服务器上运行？
你可以和你不能。 您不能将基于代码/ SOAP的Web服务上传到服务器，而不是将其上传/存储在服务器上的观察者（称为订阅）。
整个事情相当有限，并没有真正可比性？
我会说在CloudKit和MBaas客户端通过一个更窄的更健壮的接口与服务器通信：你不能上传外来的Web服务来做XMLparsing，数据库操作，并基于它触发推送通知，但RestFull架构允许您执行4对数据存储的基本操作，并且与订阅客户端可以得到关于在表上执行的INSERT / UPDATE / DELETE操作的通知。
我认为MBaas只是服务器 – 客户端架构演进的下一步。 首先它似乎是限制性的，但是您可以像在基于SOAP的Web服务世界中那样做所有事情。 开发是非常快速/可扩展/使用舒适，更容易控制的东西，如权限/设置，维护服务器，安全需要几乎没有努力。
不pipe你信不信，用这种方法你实际上可以得到很大的回报。
我没有使用CloudKit，但我可以为你描述我的应用程序堆栈：
AngularJS （或者您最喜欢的客户端HTML呈现框架）：单个页面将托pipe由路由器select的一系列模板/控制器，并且由用户改变锚以select他们所在的页面。
Firebase.io （或您最喜爱的云存储）：任何dynamic数据都将进入云文档存储。 控制器需要加载数据并在客户端上呈现模板，当数据发生变化时，将数据发回。 这也提供了authentication和授权，因为您可以限制对数据的访问。
现在你需要一个地方为HTML / CSS / JS /图像提供服务……不需要“服务器端代码执行”，只需要一个可以放置资源的Web服务器即可。
使用这种技术，您可以将该用户的所有用户主题存储在数据库中，当页面加载时，将这些主题（也存储在数据库中）的所有源汇总到客户端。 在您的示例应用程序中，没有任何事情需要执行服务器端，只要您有云存储（将为您提供身份validation和授权服务）以及用于提供静态资源的“哑”Web服务器。
CloudKit不是一个完整的虚拟主机服务。 相反，这是一个用于iCloud的SDK。 你不应该把网站放在那里，只是存储你可能想在多个应用程序或平台上使用的用户数据。
iCloud API可让您的应用程序在iCloud中存储应用程序数据，使您的应用程序自动保持最新。 使用iCloud为您的用户提供跨iCloud设备的一致和无缝的体验。