当我们新建一个 Cocoa 项目时，Xcode 会提供一系列的模板，类似前端的脚手架工具，只需要简单的几个选项，就可以配置好一个项目所需的基本环境。
这些基本环境配置一般包括：
- 编译选项、证书链选项
- 项目 Target、单元测试 Target
- 基于 git 的版本控制管理
- 默认的源文件
当然我们也可以新建一个空白的 Project，然后手动去组装这些东西。
由于苹果的封闭性，对 Cocoa 项目的管理基本上都在 Xcode 中进行，这个 All-in-One 的强大工具提供了从文档、编码、调试、测试，再到签名、打包、上线的全流程支持。
随着开发的深入，我们的项目变得越来越复杂，各种链接库、子工程相互引用，不同 Target、Scheme 配置混杂，还会遇到多人协作开发时诡异的冲突。即使是老鸟有时候也会一筹莫展，这时候就需要对 Xcode 工程结构以及管理机制有更加清晰的认识。
Scheme、Target、Project 和 Workspace
Schema、Target、Project 和 Workspace 是组成一个 Xcode 工程最核心的单元，也是我们首先需要理解的部分。
Target
Target 是我们工程中的最小可编译单元，每一个 target 对应一个编译输出，这个输出可以是一个链接库，一个可执行文件或者一个资源包。它定义了这个输出怎样被 build 的所有细节，包括：
- 编译选项，比如使用的编译器，目标平台，flag，头文件搜索路径等等。
- 哪些源码或者资源文件会被编译打包，哪些静态库、动态库会被链接。
- build 时的前置依赖、执行的脚本文件。
- build 生成目标的签名、Capabilities 等属性。
我们平时在 Build Settings，Build Phases 中配置的各种选项，大部分都是对应到指定的 target 的。
每次我们在 Xcode 中 run/test/profile/analyze/archive 时，都必须指定一个 target。
工程中的 targets 有时候会共享很多代码、资源，这些相似的 targets 可能对应同一个应用的不同版本，比如 iPad 版和 iPhone 版，或者针对不同市场的版本。
Project
Project 很好理解，就是一个 Xcode 工程，它管理这个工程下的 targets 集合以及它们的源码，引用的资源，framework 等等。
Project 是管理资源的容器，本身是无法被编译的，所以每个 project 至少应该有一个可编译的 target，否则就是一个空壳。一个 target 编译时引用的资源是它所在 project 所有管理资源的子集。
我们也可以对 project 进行配置，包括基本信息和编译选项（Build Settings）等，这些配置会应用到它管理的所有 targets 中，但是如果 target 有自己的配置，则会覆盖 project 中对应的配置。
在很多情况下，我们的工程中只有一个 project。可以在 finder 中双击后缀名为.xcodeproj 的文件，就可以直接打开单个 project 了。
如果我们需要从源码编译一个依赖库，可以把这些源码所在的工程作为主工程的subProject 添加到目录结构中去：
然后将这个子工程的某个 target 作为主工程 target 的依赖，从而在 build 主工程 target 的时候，顺便也会编译子工程对应的 target。
这样做的好处是你可以在一个窗口中同时修改主工程和子工程的源码，并且一起进行编译。
Workspace
上面所说的添加子工程的方法，已经很好的解决了不同项目中 target 依赖的问题了，那么什么时候需要用到 Workspace 呢？
当一个 target 被多个不同的项目依赖，或者 project 之间互相引用，那么我们就需要把这些 projects 放到相同的层级上来。管理相同层级 projects 的容器就是 Workspace。
和 projects，target 不同，workspace 是纯粹的容器，不参与任何编译链接过程，它主要管理：
- Xcode 中的 projects，记录它们在 Finder 中的引用位置。
- 一些用户界面的自定义信息（窗口的位置，顺序，偏好等等）。
注意到，当你把不同的 projects 放到一个 workspace 中管理后，你仍然可以用 Xcode 单独打开其中的某一个 project，但是如果它涉及到对其它 project target 的依赖，这时候你无法在这个单独的窗口中编译成功。
在 iOS 开发中，我们常常使用 Cocoapods 来管理三方库，它会把这些三方库的源码组装成一个 project，和主工程一起放入到 workspace 中，自动配置好主工程与 pods 库之间的依赖。所以如果引入了 Cocoapods，我们必须打开这个新的 workspace 才能正常 build 原来的项目。关于 Cocoapods，我们在后面的文章中再详细介绍
Scheme
日常开发中我们常常点击 Xcode 左上角的 Run 箭头来运行调试代码，这其实就是执行了 Scheme 定义的一个任务。
针对一个指定的 target，scheme 定义了 build 这个 target 时使用的配置选项，执行的任务，环境参数等等。Scheme 可以理解为一个工作流，或者蓝图，当我们点击 debug，test 按钮时，Xcode 会按照 scheme 中的定义，去执行对应的工作流。
Scheme 中预设了六个主要的工作流： Build, Run, Test, Profile, Analyze, Archive。包括了我们对某个 target 的所有操作，每一个工作流都可以单独配置。
Scheme 中最重要的一个配置是选择 target 的 build configuration，对每一个 project，会有两个默认的 build configuration：debug 和 release。
每个 configuration 对应了 build target 时不同的参数集，比如宏，编译器选项，bundle name 等等。我们可以在 target 的配置页中更改这些选择项，也可以自己创建新的 build configuration，比如为 App 创建免费和付费版本的配置。
除了 build configuration 外，scheme 还可以配置：
- 运行时的环境变量（Environment Variables）
- 启动时设置给 UserDefaults 的参数（Arguments Passed on Launch）
- App 执行时的系统语言、模拟的定位坐标、国家等环境参数
- runtime，内存管理，日志，帧率检测等调试选项
另外有一些 debug 时十分有用的选项，也可以在 scheme 配置中找到。
一个 scheme 对应一个 target，同一个 target 可以有多个 scheme，通过灵活地配置 scheme，我们可以方便地管理不同环境下 App 的测试，调试，打包流程。
下表列举了我们在 Scheme 中的常见配置选项：
选项说明Pre(Post)-actions指定在进行工作流之前（之后）执行的脚本，发送邮件通知等任务。Launch编译完成后是否立即运行Arguments Passed On Launch指定一些运行时的参数，比如本地化语言的选项，Core Data 调试选项等Environment Variables指定环境变量，比如开启僵尸内存，Malloc选项，I/O buffer大小等。Application Language/RegionApp 运行使用的语言和国家XPC Services打开调试 XPC (应用间通信)Queue Debugging打开线程调试，会自动记录运行时的线程信息。Runtime Sanitization是否打开运行时的一些调试选项，包括内存检测、多线程检测等等，在 debug 一些棘手的异常时十分有用Memory Management开启一些内存管理相关的服务，包括内存涂抹，边缘保护，动态内存分配保护，僵尸对象等等Logging配置调试过程中终端输出的日志Runtime Sanitization是否打开运行时的一些调试选项，包括内存检测、多线程检测等等，在 debug 棘手的异常时十分有用
本文参考：
- Xcode Concepts
- Xcode and git: bridging the gap
- Xcode Project vs. Xcode Workspace - Differences
- limit run script build phase to release configuration
- Xcode - xcworkspace and xcodeproj
- Launch Arguments & Environment Variables