我有一组相关的项目，它们都将使用相同的核心数据模型。一个用于输入数据的 OS X 应用程序，将导出到另一个充当服务器的 OS X 应用程序，以及一个充当客户端的 iOS 应用程序。每个客户端都将维护自己的本地存储，服务器上的更改将通过本地网络上的 TCP 通过 MOCDidSave 发送给客户端。
我想在所有项目/目标/应用程序的整个开发过程中共享一个模型和一组 mogenerator 生成的 NSManagedObject 子类。
我已经研究过使用工作区并使用具有多个目标的单个项目。我还查看了 Marcus Zarra 用于添加在他的 Core Data 书籍第二版中开发的 iOS 应用程序的桌面版本的解决方案。我确信还有其他方法可以实现这一点，但我不熟悉创建静态库或框架，我不确定这是解决这个问题的正确方法。
关于如何最好地做到这一点的任何建议？或者，至少对权衡取舍有所了解？
谢谢。
布拉德
这并不难做到。
基本上将所有与 CoreData 相关的类和模型保存在一个分离的文件夹系统中，您可以将其添加到您的 CoreData 项目中。
我过去曾尝试使用一个独立的数据堆栈对象层，即启动持久存储协调器、持久存储和托管对象上下文的东西，它们可以在 iOS 或 OS X 上实例化，但一旦你开始使用它就会变得粘稠NSPersistentDocument 所以最后我只是构建堆栈并将其指向每个平台的公共模型和 MOGenerated 类，以对给定平台最有效的方式。
编辑
OP 提到这是一个 B2B 应用程序，他们不会使用“NSDocument”/“NSPersistentDocument”来处理 OS X 端的事情，因此容器对象在这里可能是一个不错的选择。它的职责是管理和实例化 CoreData 堆栈。它将以在 OS X 和 iOS 上编译的方式编写。因此，要启动数据层，您需要做的就是实例化对象并请求 managedObjectContext。
查看Florien Kugler 的这篇博客，了解一些潜在的内部设置方法
优点
您的应用程序使用通用数据层和 CoreData 附带的所有免费内容
缺点
除非您使用包装文件，否则沙盒会在 OS X 上给您带来很大的痛苦，除非您不打算通过 MAS
NSPersistentDocument 不支持开箱即用的包装文件。有几个人制作了适配器。在 GitHub 上查看。但也许你不打算走那条路。
版本控制。在部署之前确保您的模型尽可能正确，因为任何数据模型更改都会强制所有客户端进行强制升级。尽管托管对象模型的更改相当容易，但在部署到您的客户时确实有一定的难度。添加额外未使用的字段以供将来扩展。
基本上确定您是否真的希望为此使用 CoreData。之前已经说过，但我会解释一下——CoreData 不是关系数据库，它是 fopen() 的时髦版本。
一种可能的方法是使用 CoreData 作为应用程序中的 shim 工作层，但将存储作为简单的 JSON 层保留在磁盘上，因此如果模型需要在未来某个时候彻底改变，您不会冒着炸毁所有客户端数据的风险.
总之。仔细考虑 CoreData 是否适合您的应用程序及其长期前景。现在可能还好，但 2 年后你可能会发现自己陷入了地狱。