我不明白使用Xcode工作区来组织彼此依赖关系的项目。比如我看到了很多的开发人员创建看起来像这样的工作空间结构：Xcode工作区vs嵌套项目
Workspace |-- App |-- A Common Library |-- Another Common Library
什么好处这是否提供？如果有人直接打开“应用程序”项目，他们不会无法真正建立应用程序？他们必须认识到工作区存在必要的依赖关系。
在我看来，像更好的方法是使用嵌套的项目是这样的：
App |-- Libraries | |-- A Common Library | |-- Another Common Library
然后没有项目存在不能建立。它也似乎更符合Git关于子模块的想法。
我看到的工作空间的唯一用途是将常见项目彼此不依赖。我想听听其他人的想法，因为我可能会错过一些东西。
我想在合并项目的同时保持项目独立性时使用工作空间。
我使用工作区的例子是一系列从简单到复杂的教程项目。每个项目都可以作为一个独立的项目，但将它们分组在一起可以帮助我组织整个项目。
在另一个例子中，我有一个为客户开发的应用程序。该应用程序既可以作为独立应用程序，也可以作为整个项目中的模块。独立项目可以构建独立应用程序。另一个应用程序使用包含两个项目的工作区。该应用程序的模块版本是从一个特殊的方案构建的，并且这个组合的应用程序不会在不使用工作区的情况下构建。
上述两种情况的一种扭曲是构建文件夹的存储位置。我必须更改Xcode首选项以将构建产品放入该组教程项目的唯一文件夹中，并在其他应用程序设置中为该模块使用常见的构建文件夹。
在其他情况下，我有大量的项目与嵌入式项目。在这些情况下，图书馆项目是稳定的。我不会试图进一步开发图书馆项目，所以它们只是项目的另一个资源。我发现在我的文件系统组织项目资源的地方有点反映了我的Xcode项目的组织。所以这些库项目被复制到主项目的文件层次结构中。如果我正在开发这些库并在多个项目中使用它们，那么使用工作区是有意义的。为了方便，我经常不打扰。
有时我甚至会将工作区与包含嵌入式项目的项目组合在一起。
所以我认为组织工具，嵌入式项目和工作空间都有它们的优点和问题。我根据具体情况选择使用一种或另一种（或组合）。
感谢您的洞察力。我同意你的大部分观点，但是即使图书馆处于流动中，我也没有看到使用工作区的好处。如果您的库是在Git存储库中维护的，则应该能够将其作为子模块添加到项目中，然后根据需要更新子模块。 – mark 2012-07-23 19:59:04
是的，git子模块是管理库开发的替代方法（也可能更好）。子模块是一种先进的git功能，许多iOS开发人员由于缺乏知识而需要使用其他版本控制系统，因此无法使用这些功能。在这种情况下，工作空间可能是比嵌入式项目更好的选择。 – 2012-07-23 20:50:51
@ Mr.Berna - 抱歉，在xcode中使用git是一件痛苦的事......你无法控制什么版本/分支/分支你在任何项目中使用什么，除非你使用终端手动使用目录目录，手动注释。 – SpaceDog 2013-10-24 10:20:21
我们在主项目的框架中添加了嵌套项目，所以我们可以将它们“包含”到框架产品中。
Main
|-- Main
|-- MainTests
|-- Frameworks
| |-- CommonLibrary.xcodeproj
| |-- AnotherCommonLibrary.xcodeproj
| |-- UIKit.framework
| |-- Foundation.framework
| |-- CoreFoundation.framework
|-- Products
查看this Great Tutorial by Jeff Verkoeyen用于将Universal Frameworks添加到项目中。起初，这并不容易，但要继续努力，你会得到它的窍门。
通过在每个.xcodeproj上放置CocoaPods可以实现这种结构吗？ – user023 2016-03-10 14:56:24
哇！Xcode标记的问题实际上是关于Xcode的！ :) – Almo 2012-07-23 18:42:59
@Almo：它每隔几天发生一次。但它们通常有相反的问题：当它不适用时标记[objc]。 :) – 2012-07-23 18:46:20
这里提到了使用工作区的一些原因：https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Workspace.html – pi3 2013-10-27 15:49:38