我不明白使用Xcode工作区来组织彼此依赖的项目。例如，我看到许多开发人员创建了如下所示的工作区结构：
Workspace |-- App |-- A Common Library |-- Another Common Library
这提供了什么好处？如果有人直接打开“App”项目他们是不是无法实际构建应用程序？他们必须意识到工作空间存在必要的依赖关系。
在我看来，更好的方法是使用这样的嵌套项目：
App |-- Libraries | |-- A Common Library | |-- Another Common Library
然后没有无法构建的项目。它似乎更符合Git关于子模块的想法。
我在工作空间中看到的唯一用途是将常见项目分组，彼此之间没有依赖关系。我想听听别人对此的看法，因为我可能会遗漏一些东西。
答案 0 :(得分：18)
当我想要组合项目同时保持项目独立性时，我使用工作区。
我使用工作空间的一个示例是一系列教程项目，从非常简单到复杂。每个项目都可以作为独立项目运行，但在工作区中将它们组合在一起有助于我组织整个项目。
在另一个例子中，我有一个为客户开发的应用程序。该应用程序既可作为独立应用程序，也可作为整个项目中的模块。独立项目可以构建独立应用程序。另一个应用程序使用包含两个项目的工作区。应用程序的模块版本是根据特殊方案构建的，如果不使用工作区，则不会构建此组合应用程序。
上述两种情况的一个转折是存储构建文件夹的位置。我必须更改Xcode首选项以将构建产品放入教程项目组的唯一文件夹中，在其他应用程序设置中使用模块的公共构建文件夹。
在其他情况下，我有很多嵌入式项目的项目。在这些情况下，图书馆项目是稳定的。我不会尝试进一步开发库项目，因此它们只是项目的另一个资源。我发现在我的项目资源的文件系统组织有点反映我的Xcode项目的组织的地方工作更容易。因此，这些库项目将复制到主项目的文件层次结构中。如果我正在开发库并在多个项目中使用它们，那么使用工作空间是有意义的。为方便起见，我经常不打扰。
有时我甚至将工作空间与包含嵌入式项目的项目相结合。
所以我认为组织工具，嵌入式项目和工作空间都有其优点和问题。我根据具体情况选择使用其中一种（或组合）。
答案 1 :(得分：1)
我们将嵌套项目添加到Main项目的框架中，因此我们可以将它们“包含”到.framework产品中。
Main
|-- Main
|-- MainTests
|-- Frameworks
| |-- CommonLibrary.xcodeproj
| |-- AnotherCommonLibrary.xcodeproj
| |-- UIKit.framework
| |-- Foundation.framework
| |-- CoreFoundation.framework
|-- Products
有关将Universal Frameworks添加到项目的信息，请参阅this Great Tutorial by Jeff Verkoeyen。一开始并不容易，但要继续努力，你就能掌握它。