CloudKit-サーバー側のロジックはありませんか？
CloudKit を使用すると、クライアント側のアプリ開発に集中でき、iCloudでサーバー側のアプリケーションロジックを作成する必要がなくなります。 CloudKitは、認証、プライベートおよびパブリックデータベース、構造化およびアセットストレージサービスをすべて無料で提供し、非常に高い制限があります。
Appleのサーバーで実行するコードをアップロードできませんか？
Google App Engineや他のクラウドコンピューティングプラットフォームと比較されていると聞きましたが、独自のコードを実行する機能がなければ、全体がかなり制限されており、実際には比較できませんか？
たとえば、ユーザーが関心のあるトピックに関する記事を定期的にプッシュするニュースアプリを構築したい場合、サーバー上でスケジュールされたジョブとデータ処理が必要になるため、CloudKitを使用してこれを行うことはできません。
何かご意見は？
サーバ側
あなたが言ったように、CloudKitはサーバーサイドコードを許可していません。
しかし、可能性はあります。
Cron
レコードを追加してプッシュを実行するために、毎日iCloudダッシュボードに接続する必要はありません。ここでの解決策の1つは、毎日新しいDailyCKRecordを追加するアプリをMacサーバーでコーディングすることです（サーバーとしてのmac miniはCloudKitでより一般的になると思います）。
サブスクリプション
サブスクリプションの概念は、クライアントが特定の更新を登録することです。たとえば、Dailyというレコードタイプを作成して、ユーザーに登録させることができます。 Appleのドキュメント およびWWDC14のビデオを確認する必要があります（サブスクリプションの詳細が記載されていない場合でも、開始点として適しています）。
良い点は、プッシュ通知がサブスクリプションの概念とリンクしていることです。つまり、基本的には次のように言います。タイプCKRecordの新しいDailyが追加されるたびに通知を送信します。
BaaS党
CloudKitを使用するポイントは何ですか（vs Parseなど）
- 価格：CloudKitは本当に素晴らしい価格設定です
- 準備完了：XCode内で2回クリックすると、準備完了です
- ユーザーの一貫性：iCloudアカウントを介してすべてのデバイスの無料ユーザーログインを取得します。非常に優れたプライバシーシステムを備えています。そして、あなたはスマートシステムとの関係を得ることができます。
だが：
- あなたはAppleプラットフォームに固執しています。データをエクスポートできるかどうかさえわかりません。
- 今のところデータ中心のみ（サーバー側コードなし）
- CloudKitダッシュボードが制限されすぎています
未来
CloudKitはまだかなり新しいです。 WWDCでは、その背後にいる何人かの人が、彼らがまだそれに取り組んでいることを私に理解させました。私の賭けは、彼らが2つの重要な点に取り組んでいるということです：
- リモートのスケジュールされたタスクによるサーバー側のコード実行
- CloudKit for Analytics（視覚化側）
編集：Appleみんなは、データへのWebアクセスの欠如を完全に認識しており、心配しています。つまり、ある日それmayは他のプラットフォームからアクセス可能です。コメントを読んだところ、Apple CloudKitがあればおそらくParseを購入したでしょう。彼らはParseを購入しようとしました（スキルはそれを購入すると言われていますが、私たちは本当に知りません）。
WWDC15を更新
CloudKitがJSで利用可能になり、一部のダッシュボードが利用可能になりました。成り行きを見守る。
2016年2月の更新
CloudKitがサポートするようになりました サーバー間Webサービスリクエスト
場合によっては、サーバー側のロジックは必要なく、静的データを保存するだけですべての使用シナリオをカバーできます。
この場合、何かを保存できる無料のアクセス可能なストレージがあると非常に役立ちます。 CloudKitは、フルサービスプラットフォームではなく、そのようなものを提供します。
はい、制限があります。とにかく、一部の人にとっては便利です。たとえば、あなたのケースは実際にCloudKitをサポートできます。 CloudKitは単なる静的ストレージですが、サブスクリプションをサポートしています。一連の条件を監視し、イベント通知をクライアントにプッシュします。 CloudKitでサポートされている唯一のバックグラウンドジョブ機能が必要なものだけであることは幸いです。
とにかく、もっと必要な場合は、本格的なサーバーを検討する必要があるかもしれません。通常、単純なサーバーサイドコード実行をサポートするsimpleWebサービスも制限されます。
Appleのサーバーで実行するコードをアップロードできませんか？
できますし、できません。コード/ SOAPベースのWebサービスをサーバーにアップロードすることはできません。代わりに、サブスクリプションと呼ばれるオブザーバーをサーバーにアップロード/保存することができます。
全体がかなり制限されており、実際には比較できませんか？
CloudKitとMBaasでは、クライアントはサーバーと通信しますが、より狭く、より堅牢なインターフェイス：エキゾチックなWebサービスをアップロードしてXML解析、データベースを実行することはできません。操作とそれに基づくプッシュ通知がトリガーされますが、RestFullアーキテクチャでは、データストアで4つの基本操作を実行でき、サブスクリプションクライアントを使用すると、テーブルで実行されたINSERT/UPDATE/DELETE操作について通知を受け取ることができます。
MBaasは、サーバーの進化における次のステップ、つまりクライアントアーキテクチャだと思います。最初は制限があるようですが、SOAPベースのWebサービスの世界のようにすべてを行うことができます。開発は非常に高速/スケーラブル/使いやすく、権限/セットアップ、保守などの制御が簡単ですサーバー、セキュリティはほとんど努力を必要としません。
信じられないかもしれませんが、このアプローチで実際に遠くまで行くことができます。
私はCloudKitを使用していませんが、アプリケーションスタックについて説明できます。
AngularJS（またはお気に入りのクライアント側HTMLレンダリングフレームワーク）：単一のページは、ルーターによって選択され、ユーザーがアンカーを変更して表示しているページを選択することによって駆動される一連のテンプレート/コントローラーをホストします。
Firebase.io（またはお気に入りのクラウドストレージ）：動的データはすべてクラウドドキュメントストアに送られます。コントローラは、データをロードしてクライアントにテンプレートをレンダリングする必要があり、データが変更されたら、データを送り返します。これにより、データへのアクセスを制限できるため、認証と承認も提供されます。
ここで、HTML/CSS/JS/imagesを提供する場所が必要です...これは「サーバーサイドコードの実行」を必要とせず、アセットを配置できるWebサーバーだけです。
この手法を使用すると、そのユーザーのすべてのトピックをデータベースに保存できます。ページが読み込まれたら、それらのトピックのすべてのソース（データベースにも保存されています）を完全にクライアント側に集約します。あなたのサンプルアプリケーションには、認証と承認サービスを提供するクラウドストレージと、静的アセットを提供するための「ダム」ウェブサーバーがある限り、実際にサーバー側の実行を必要とするものは何もありません。
CloudKitは本格的なウェブホスティングサービスではありません。代わりに、それはiCloud用のSDKです。複数のアプリケーションやプラットフォームで使用したいユーザーデータを保存するだけで、そこにWebサイトを配置するべきではありません。
iCloud APIを使用すると、アプリはアプリデータをiCloudに保存し、アプリを自動的に最新の状態に保つことができます。 iCloudを使用して、iCloud対応デバイス全体で一貫したシームレスなエクスペリエンスをユーザーに提供します。