クライアント/サーバー型iOSアプリの「ミドルグラウンド」アーキテクチャ？
IOSアプリのアーキテクチャには、仕事をするためにサーバーと通信する必要がある2つの明らかなアプローチがあります。
Webブラウザのふりをする
このアプローチでは、アプリはユーザーアクション（新しいビューコントローラーへの移動、[更新]のタップなど）に応答してサーバーからデータのチャンク（通常はJSON）をフェッチし、スピナーまたはその他の進行状況インジケーターを表示します、リクエストが完了するとビューを更新します。 「モデル」クラスは、着信JSONから直接マッピングされ、場合によっては不変であり、ユーザーがフェッチして入力した画面から移動すると破棄されます。
このアプローチの「純粋な」バージョンでは、サーバーに適切なヘッダーを設定し、NSURLSessionとその仲間にキャッシュを処理させます。
これは、ユーザーが高速で低遅延のネットワーク接続を持ち、ほとんどの場合サーバーからデータを読み取り、書き込みを行っていないと想定できる場合は正常に機能します。
同期
「同期」アプローチでは、アプリはユーザーに表示するモデルオブジェクトのローカルCoreDataストアを維持します。ユーザーの操作に応じて、または定期的にこれを更新し、モデルが変更されるとUIを（KVOなどを介して）更新します。ユーザーがモデルを変更すると、これらの変更はサーバーに非同期で送信されます。対立を解決するためのメカニズムがなければなりません。
このアプローチは、アプリがオフラインまたは高レイテンシ/低速ネットワークコンテキストで機能する必要がある場合、またはユーザーが大量のデータを書き込み、サーバーのラウンドトリップを待たずにモデルの変更を確認する必要がある場合に適しています。
3番目の中間の方法はありますか？ mostlyであるが常に読み取れるわけではないが、書き込みがある場合、ユーザーはそれらの更新をすぐにUIに反映するはずです。アプリは、ネットワークが少ない、またはネットワークがない状況で使用できる必要があります（サーバーへのリクエストが応答するまで、以前にキャッシュされたデータを表示します）。
Core-Data-with-syncを完全に使用せずに（重量感があり、正しく理解するのが難しい）、両方の世界を最大限に活用できますか？また、誤ってバグのある不完全なCore Dataのクローンを実装することもありませんか？
努力の観点からではありません。同期モデルを介して何かを実装している場合は、それに伴うすべてを構築する必要があります。オプションで、パフォーマンスの観点から望ましい場合は、更新時に遅延読み込みを許可することを選択できます（これは、ユーザーベースの50％未満がナビゲートする、小さくてあいまいなフィードの一般的な方法です）。
もちろん、これは上記のように「どちらか一方」を実行するよりも優れていますが、基本的にビルドする必要がある問題があります両方。ただし、モバイルアプリへのデータの読み込みを処理する最も効率的な方法は私の意見です。