XCode工程设置

Project设置

针对整个Project的设置，分为Info和BuildSetting两个页签，其中有部分设置会被Target所继承或修改。注意：Project的Building Settings中已有的设置如果在Target中重新设置，那么Project的设置会被覆盖，只有当Targets的设置加入了$(inherited)时才会被继承到Target层的设置。

Info

• Deployment Target
  • iOS Deployment Target
    即项目的minsdkversion(最低可运行的iOS版本)，Target内也有该设置并可以覆盖

Tip: 我们所依赖的lib库的deployment target不应该高于应用的deployment target，否则很可能报错. 在没有技术要求的情况下（如lib库依赖于某个版本的新功能），不要采用默认的deployment target,而是尽可能的把lib库的deployment target设置低一些，这样能够最大程度的保证兼容低版本的设备.

• Configurations
  用来配置iOS项目的xcconfig文件，主要用于在几套不同的开发环境编译, xcconfig文件其实就是xcode里的config文件，本质是一个用来保存 Build Settings 键值对的纯文本文件。在Project设置中可以配置该Project下不同Target不同Scheme的不同Build Settings设置，这种用文本保存配置的形式方便进行复用和版本管理。也可以在该选项下添加自定义Configuration或删除Configuration，Xcode提供了默认的4个Configuration，分别为Debug、Release、ReleaseForProfiling、ReleaseForRunning。其中主要使用Debug和Release两种Configuration，后两种基本可以不用，可以删除(省的还要在xcconfig文件中填充它们的字段)，Debug用来调试和测试，Release用来发布，已经够了。
• Localizations
  配置iOS的本地化功能

BuildSettings

该页签下的所有设置都在Target中有，Project的BuildSettings页签设置只是给该Project下的Target提供默认设置，各选项在Target中介绍。

Target设置

针对单个Target的设置，分为General、Capabilities、Resource Tags、Info、BuildSettings、Build Phases、Build Rules七个页签。

General

• Identity
  标识该app身份的相关设置
  • Display Name
    App应用显示名，安装到设备上之后显示的App名称
  • Bundle Identifier
    包标识符，非常重要，App的唯一ID，用来让操作系统和AppStore识别进行拉起，通信和更新等操作的依据。
  • Version
    外部版本号，向用户展示的版本号字符串，在应用商店和系统设置中所展示的版本号也使用该设置，可以视为Tag
  • Build
    内部版本号，开发者自己看到的版本号，可以使用构建号，区分内部测试版本
• Signing
  进行证书签名管理，在不同的scheme下使用不同的签名证书配置
  • Provision Profile
  • Team
  • Signing Certificate
  • Status
• Deployment Info
  部署设置
  • Deployment Target
    即Target的minsdkversion(最低可运行的iOS版本), 如不设置则使用Project的设置
  • Devices
    用来设置支持的设备，有iPhone、iPad和Universal(iPhone和iPad均支持)三个选项
  • MainInterface
    应用启动时预加载的主界面视图。可以通过Main.storyboard进行启动，但是这样需要我们整个项目的逻辑和跳转都在Main.storyboard中完成不够灵活；一般不直接给MainInterface设置storyboard，而是通过代码的方式运行main.m的方法进行启动，并通过在AppDelegate中指定主界面视图进行启动，更加灵活
  • Device Orientation
    定义应用支持的旋转方向，包含Portrait(竖屏正)、Upside Down(竖屏反)、Landscape Left（横屏左）、Landscape Right(横屏右)几种方向
  • Status Bar Style
    状态栏样式相关设置
• App Icons And Launch Images
  应用图标和启动页面相关设置
  • App Icons Source
    App图标资源，对应Images.xcassets目录中的AppIcon中的图片，iOS系统会读取这些图片并在不同的场景展示不同尺寸的app图标，如Notification(通知)、Spotlight(搜索)、App(桌面上)、App store(应用商店中)。
  • Launch Image Source
    启动图片资源，对应Images.xcassets目录中的LaunchImage中的图片，设定了不同尺寸不同方向下的启动图片
  • Launch Screen File
    启动页面文件，可以指定一个storyboard文件，作用与Launch Image一样，但是优先级高于Launch Image，storyboard是苹果后面推出的一种设定方式，并且要求后续上架的app必须使用storyboard替换Launch Image否则将无法通过审核

Tip: 在我们点击应用图标启动应用时，应用启动需要一定的操作时间，再启动期间，为了增强应用程序启动时的用户体验，您应该提供一个启动图像。启动图像与应用程序的首屏幕看起来非常相似。当用户在主屏幕上点击您的应用程序图标时，iOS会立即显示这个启动图像。一旦准备就绪，您的应用程序就会显示它的首屏幕，来替换掉这个启动占位图像。重要！！！>>> 之所以提供启动图像，是为了改善用户体验，并不是为了提供：应用程序进入体验，比如启动动画

• Embedded Binaries
  可植入性二进制文件。该选项用来配置Embedded Framework 动态库，一般只在使用扩展Extension功能时会用到，该动态库只能在应用程序进程和该应用程序扩展的进程之间共享(即只load一份到内存)，不能被其它应用程序进程使用。

Tip：iOS的动态库和静态库一样也包含多种指令集架构，包括i386, x86_64, armv7, armv7s, arm64等，但是Xcode构建时会直接将动态库文件打包进ipa中，不会像静态库一样根据architecture剥离未使用的指令集架构，而苹果又不允许把包含i386, x86_64等模拟器架构的包上传到App Store Connect后台，所以打提审包之前要保证已通过lipo工具移除所有Invalid Architectures，再进行打包。

• Linked Frameworks and Libraries
  链接的框架和库。该选项用来配置用于链接Framework和静态库文件(Library)，framework可以是系统级共享静态库。在Build Phases中也有类似的功能选项

Capabilities

Capabilities是对app进行一些权限和功能设置的开关，如推送通知、云存储、游戏中心、后台模式、地图、苹果账户登陆等等，这些开关和开发者证书是匹配的，调试证书无法打开这些开关。

Resource Tags

Resource Tags主要是为项目中的资源进行添加tag分类，方便控制资源的加载顺序和加载时机，一定程度实现lazyload。使用Unity开发游戏忽略该配置即可，因为游戏开发不需要原生app的资源加载方式，完全使用游戏业务的资源加载策略

Info

• Custom iOS Target Properties
  自定义iOS目标属性,最重要的一项配置，该栏下的内容和工程目录下的Info.plist完全一致，有些键也对应着其它设置项，任何一处的修改都会自动应用到所有地方。例如修改Bundle Diaplay Name键，会自动体现到Info.plist文件和General-Identity-DisplayName中，可以猜测这种类型的设置本质上只是存储在Info.plist文件一处，所有的修改都映射到修改该文件，读取也是映射到读取该文件的键值。具体的所有键的解释略过～
• Document Types
  声明该app支持处理的文档类型，还可以定义在系统中显示的该类型文档的自定义图标，一般工具类app会用到
• Exported UTIs/Imported UTIs
  uti是iOS系统中为类型标识提供的一套公用的规范Uniform Type Identifier(统一类型标识符)。一般游戏类用不到
• URL Types
  用来定义URL以便让应用程序理解应用间交换的数据结构，相当于声明了该app提供给其它app环境的接口，是非常重要的一项设置。用于iOS唤醒其他程序，和程序间相互调用(使用openURL)，如游戏拉取qq或微信授权时，会使用qq或微信的URLTypes，操作完毕后qq或微信又会通过该app的URLTypes设置回传token之类凭证并重新唤醒。

BuildSettings

BuildSettings配置是target的编译选，也可以使用xcconfig文件进行管理, 和Info选项卡类似，BuildSetting下的很多选项也对应着其它地方的设置项，任何一处的修改都会自动应用到所有位置，如iOS Deployment Target对应着General中Deployment Target。BuildSetting下的每一项配置都有四列，包括Resolved、Target、Project、iOS Default，分别代表最终确定配置、Target配置、Project配置、iOS默认配置，Resolved的结果是根据后面三项中优先级最高的列确定的，优先级Target>Project>iOS Default，当有和默认设置不同的项会使用绿色方框标识。默认情况下选择Combined只会显示Resolved最终结果，当选择Level时会展示BuildSetting所有列的详细配置。下面是各个设置项的详细介绍，主要介绍的Unity导出工程的basic配置，后面略过的是All中所有配置，basic下均是project或Target中和上一层级导出值或默认值有修改的项，这些项也会在Xcode中以加粗形式显示。

• Architectures
  指定该Target所支持的指令集架构相关设置

  • Architectures
    指定工程被编译成可支持哪些指令集类型，而支持的指令集越多，就会编译出包含多个指令集代码的数据包，对应生成二进制包就越大，也就是ipa包会变大
  • Valid Architectures
    限制可能被支持的指令集的范围，也就是Xcode编译出来的二进制包类型最终从这些类型产生，而编译出哪种指令集的包，将由Architectures与Valid Architectures（因此这个不能为空）的交集来确定，一般包含arm64 arm64e armv7 armv7s
  • Build Active Architecture Only
    指定是否只对当前连接设备所支持的指令集编译，当其值设置为YES，这个属性设置为yes，是为了debug的时候编译速度更快，它只编译当前的architecture版本，而设置为no时，会编译所有的版本。 所以，一般debug的时候可以选择设置为yes，release的时候要改为no，以适应不同设备
  • Supported platforms
    该app支持的平台，可选iphoneos(旧)\iOS(新)、macOS、tvOS、watchOS这些选项.
  • BaseSDK
    指当前编译使用的sdk版本，默认是当前最新的sdk版本
  • Additional SDKs
    在编译的时候需要附加的sdk，一般为空

• Build Options

  • Debug Formation Format
    该选项决定了记录Debug信息的文件格式，包含DWARF with dYSM File和DWARF两个选项。DWARF是一种文件格式，如果仅选择DWARF，debug information会被保存在executable文件中(即Mach-O文件，可以使用dsymutil从executable中提取dSYM文件)；如果选择第一个，调试信息会被保存在一个独立的dYSM文件中。所以一般情况下Debug模式选择DWARF；Release模式选择DWARF with dYSM File，调试文件不会打包进发布的ipa中。
  • Enable Bitcode
    是否开启Bitcode，非常重要的一个选项，默认为Yes，开启后可以在不提交新版本App的情况下，允许Apple在将来的时候再次优化你的App二进制文件。如果打开的话则项目引用的所有静态库.a和.Framework都必须支持Bitcode，鉴于目前很多三方库不支持Bitcode或开启后有问题，所以常常需要手动设为No

  Tip: Bitcode 是 LLVM 编译器的中间代码的一种编码,LLVM的前端可以理解为C/C++/OC/Swift等编程语言,LLVM的后端可以理解为各个芯片平台上的汇编指令或者可执行机器指令数据,那么,BitCode就是位于这两者直接的中间码，类似java的字节码和C#的IL码。LLVM的编译工作原理是前端负责把项目程序源代码翻译成Bitcode中间码,然后再根据不同目标机器芯片平台转换为相应的汇编指令以及翻译为机器码.这样设计就可以让LLVM成为了一个编译器架构,可以轻而易举的在LLVM架构之上发明新的语言(前端),以及在LLVM架构下面支持新的CPU(后端)指令输出,虽然Bitcode仅仅只是一个中间码不能在任何平台上运行,但是它可以转化为任何被支持的CPU架构,包括现在还没被发明的CPU架构，所以现在打开Bitcode功能提交一个App到应用商店,以后如果苹果新出了一款手机并CPU也是全新设计的,在苹果后台服务器一样可以从这个App的Bitcode开始编译转化为新CPU上的可执行程序,可供新手机用户下载运行这个App。类比的话，假设推出了一个新的操作系统(CPU指令集架构)，只需要在该操作系统上实现.Net运行时(使LLVM支持输出该指令集架构的指令)，原有的托管dll程序集就可以迁移到该操作系统(原有的bitcode就可以使用该新指令集架构重新编译并运行)。

• Deployment
  指定该Target部署相关的设置

  • Deployment Postprocessing
    指定二进制文件是否接受部署后处理，这里的部署后处理涉及二进制文件剥离、设置文件模式/拥有者/组。这是整个后处理的 总开关 ，如果该设置为No则很多在Deployment内的其它具体后处理选项设置也会无效(如strip xxxx等剥离设置)。这里建议Release模式下应当设置为Yes，Debug设置为No，因为Debug模式下需要很多调试信息和符号化，尽可能不做剥离操作。
  • Strip Debug Symbols During Copy & Strip Linked Product
    还有一些其它的Srtip设置，都是剥离符号和调试信息的，同时也受Deployment Postprocessing总开关影响，一般Release为Yes，Debug为No
  • Target Devices Family
    是以逗号分隔的数字标识符列表。指定产品必须能够在其上运行的设备系列。1表示iPhone/iPod touch；2表示iPad，一般设置为1，2表示既支持iphone也支持ipad。该选项映射了General中的Devices选项(1,2对应Universal)
  • iOS Deployment Target
    该选项映射了General中的Deployment Target选项，表示项目最低可运行的iOS版本

• Linking
  指定该Target链接相关设置

  • Other Linker Flags
    该设置中的内容会直接传给链接器作为参数，常见的如-ObjC(把静态库中所有的Objective-C类和类别都加载到最后的可执行文件中)、-all_load(强制链接器加载所有包含非ObjC的目标文件到可执行文件中)、-force_load(强制链接器加载指定路径的库文件的所有目标文件)
  • Write Link Map File
    该设置决定是否生成链接映射文件，该文件记录了链接过程的信息文件，用于描述可执行文件的构造部分，包括了代码段和数据段的分布情况、可执行文件的路径、CPU架构、目标文件、符号等信息，可以用作静态分析。默认为No，可以设为Yes

• Packaging
  指定该Target打包相关设置

  • Info.plist File
    指定Info.plist文件的路径，一般都指定为同一个根目录下的Info.plist文件
  • Product Bundle Identifier
    产品的唯一标识符，该选项也映射了General中的Bundle Identifier
  • Product Name
    指定的产品名称，独立存在并没有意义，主要用于在其它配置文件中引用该字段，如Info.plist中的Bundle name、Bundle display name默认值均为${PRODUCT_NAME}，其中Bundle name是App安装到iOS机子里的App文件夹名；Bundle display name是显示给用户的App名字。所以一般建议Product Name使用app的产品英文代号，Bundle name保持默认值引用Product Name，Bundle display name专门设为中文的产品名

• Search Paths
  指定该Target构建时各种头文件或者库的搜索路径，要注意$SRCROOT和${PROJECT_DIR}在实际使用中大部分情况下等价的，都是指向project.xcodeproj所在的文件夹的路径，可交换使用。

  • Framework Search Paths
    Xcode用来搜索Framework的路径
  • Header Search Paths
    Xcode用来搜索头文件的路径
  • Library Search Paths
    Xcode用来搜索库文件的路径

• Signing
  该Target签名相关设置

  • Code Signing Entitlements
    指定签名的entitlements文件，该文件可以添加不公开的系统(私有)权限，如com.apple.coretelephony.Identity.get可用于获取IMSI，但是要注意提审时需要向苹果说明使用该权限的用途，并且使用私有权限时无法使用调试证书对app签名，必须去除后才能成功部署
  • Code Signing Identity
    设置为代码签名的证书
  • Code Signing Style
    选择Automatic可以自动使用调试证书(xcode自动配置Signing的其它选项)，选择Manual时则要手动选择开发者证书
  • Development Team
    选择Team
  • Provisioning Profile
    选择Provisioning Profile文件

• Apple Clang
  Clang编译器相关配置

  • Generate Position-Dependent Code
    是否创建位置独立的可执行文件，一般设为No
  • Optimization Level
    编译器的优化级别，该选项指定了Clang编译器的整体优化级别，它决定了被编译代码的执行速度和二进制文件大小的优化程度，可以在该优化级别之上使用额外的C(C++) Flags指定特定优化参数的开关进行细微的调整。通常Debug模式默认为None[-O0]，Release模式默认为Fastest, Smallest[-Os]，下面对所有优化级别详解
    • None[-O0]
      不进行任何优化，在这种设置下，编译器的目标是降低编译消耗和调试方便，运行时会得到和源码完全一致的运行结果，是Debug模式下的默认优化选项。{无优化}
    • Fast[-O1]
      进行等级1的优化，编译器会优化代码性能和文件大小并且最小限度影响编译时间, 即执行不需要大量编译时间的优化。{编译速度最快}
    • Faster[-O2]
      进行等级2的优化，编译器执行所有不涉及时间空间交换的所有的支持的优化选项，在这种设置下，编译器不会进行循环展开、函数内联或寄存器重命名，和O1相比进一步增加编译时间和生成代码的性能。{执行效率和空间各自尽可能优化}
    • Fastest[-O3]
      进行等级3的优化，编译器会开启所有的优化选项来提升代码执行效率，即在开启所有O2优化项的同时，增加了许多空间换时间的优化，有可能会导致二进制文件变大。{执行效率最快}
    • Fastest,Smallest[-Os]
      编译器会开启除了会明显增加包大小以外的所有优化选项，该选项极小限度会影响到包大小，而且也保证了代码的执行效率，是最佳的发布选项，是Release模式下的默认优化选项。 {空间最小时的执行效率最快}
    • Fastest, Aggressive Optimizations[-Ofast]
      启动O3中的所有优化，另外会开启一些违反语言标准的一些优化选项，一般不推荐。 {执行效率极致}
  • Other C Flags
    指定针对基于C编译器的额外编译选项，是在确定优化级别Optimization Level后的用于控制某个单独编译选项参数(覆盖相应的优化级别中的该选项设置)
  • Other C++ Flags
    同Other C Flags，区别在于该项是针对基于C++编译器的额外编译选项
  • Precompile Prefix Header
    是否预编译PCH文件，如果项目配置了Prefix Header，则应当把此项设为Yes，这样的话pch会被预编译，预编译后的pch文件会被缓存起来，从而提高后续的编译速度。

  PCH(precompiled header)文件是一个标准的预编译头文件,该文件会在任意源文件编译的时候都自动包含进去，而不用每次都Include。主要用于存放一些全局的宏(整个项目中都用得上的宏)、包含一些头文件(整个项目中都用得上的头文件)、自动打开或者关闭日志输出功能。不过苹果现在不建议使用PCH文件了，因为它有时会造成编译时间增加，增加了隐式依赖不利于移植。

  • Prefix Header
    设置使用的PCH文件路径
  • C++ Language Dialect
    选择使用的C++方言类型，包括C++98、C++11、C++14、C++17等，该选项决定了项目传给Clang++编译器的C++语法版本的参数，也决定了项目中可使用的C++语法特性集合。.mm和.cpp后缀的源文件会使用该选项的-std=编译参数
  • C Language Dialect
    选择使用的C方言类型，包括C89、C99、C11等选项。.m和.c后缀的源文件会使用该选项的-std=编译参数
  • C++ Standard Library
    选择链接的C++标准库，该选项也会影响头文件的搜索路径，主要是libstdc++(C++98的标准库)和libc++(C++11的标准库)，前者链接的动态库是libstdc++.dylib，后者链接的动态库是libc++.dylib，最后会体现在编译选项-libstd=上。另外Language Dialect和Standard Library要尽量匹配相同的版本，否则可能会因为新老版本的数据结构和内部实现的差异而造成运行时的崩溃。
  • Enabled C++ Exceptions
    是否开启c++的异常捕获，在C++代码中使用try catch的必要条件，一般情况下为Yes
  • Enabled Objective-C Exceptions
    是否开启OC的异常捕获，在OC代码中使用try catch的必要条件，默认为Yes，Unity导出的工程是No，开了只会有限程度影响代码效率和体积。
  • Enabled C++ Runtime Types
    是否开启使用C++动态特性，即是否使用了dynamic_cast关键字，默认为Yes，如果没有使用则可以设为No
  • Objective-C Automatic Reference Counting
    是否使用OC的自动引用计数(ARC)，与之对应的是手动引用计数(MRC)，引用计数的方式类似却不同于传统垃圾回收，ARC是编译器在编译时自动将内存管理代码在合适的位置插入到我们的代码中，所以ARC并不会有性能损失, 一般开启该选项，但是xcode默认是关闭的有点迷。
  • MisMatched Return Type
    是否开启编译警告，针对没有显示返回类型的函数和那些包含return语句但是返回类型是void的方法，影响不大，Unity导出工程设为Yes，Xcode默认为No
  • Unused Variable
    是否开启编译警告，针对没有使用的局部变量或全局变量，影响不大，Unity导出工程设为Yes，Xcode默认为No
  • Overriding Deprecated Objective-C Methods
    是否自动重写弃用的OC方法为新版本方法，一般设为Yes，Xcode默认是No

• Asset Catalog Compiler
  资源目录编译器相关设置

  • Asset Catalog App Icon Set Name
    App Icon在资源目录下的名字，可以为Debug或Release设置不同的图标资源

• User-Defined
  可以在User-Defined添加自定义的键值，可以根据不同的环境配置不同的字符串，不过这对业务的侵入性较大，我觉得不应该添加业务相关的字符串

• Assets

• Build Locations

• Headers

• Kernel Module

• Localizations

• Testing

• Test-Based API

• Versioning

• Apple Clang

• Compress PNG File

• Interface Builder XIB Compiler

• OSACompile

• Static Analyzer

Build Phases

Xcode构建不同阶段的设置

• Target Dependencies
  编译依赖关系，相当于该Target依赖的其它Target，这样执行构建之前会先构建其依赖的Target
• Copy Bundle Resources
  指定需要拷贝哪些文件作为资源打包进最后的输出文件(安装包)里
• Copy Files
• Compile Sources
  编译所有的源文件.默认情况下,该编译列表会自动添加所有工程中的源文件，也可以在该选项中为任意源文件指定额外的编译参数Compiler Flags。
• Link Binary With Libraries
  编译之后链接静态库中的目标文件
• Run Script
  完成上述所有阶段后执行的后处理脚本

Build Rules

Build Rule定义了对于某一个类型的文件，需要进行的特殊处理。比如，当需要对于.c文件用自定义的编译器编译时，那么就可以通过Build Rule来达到；如果一种文件类型需要转换成另一种文件类型，也可以使用Build Rule。Build Rule分位系统定义的Build Rule和自定义的Build Rule，自定义的Build Rule优先级总是大于系统定义的Build Rule。

Scheme设置

Xcode默认有6个Scheme模版，对应不同的场景，分别为Build、Run、Test、Profile、Analyze、Archive。其中最常用的是Run

• Run
  构建当前版本并在当前连接的真机或虚拟机上运行，可以通过设置Configuration为Debug或者release进行切换。
• Archive
  打包上传AppStore的安装包时一般使用Archive

关于支付审核

关于支付相关审核需要注意，当使用了虚拟物品支付，这种情况按苹果政策只能使用iap支付，需要给苹果分成30%。如果项目打包了微信和支付宝的支付模块，但界面上又没有使用微信、支付宝进行支付的界面。苹果就会认为你可能在上线后远程开启微信和支付宝支付，绕开虚拟物品支付只能用iap的政策，影响苹果的收益。

一点想法

• 全部梳理一遍之后，可以发现xcode中很多设置其实是脱离iOS系统而完全的业务层的内容，苹果也提供了相关选项(例如Resource Tags、User-Defined等)，或者有很多应当在运行时才能作出决策的设置苹果也会要求在build阶段设置好，这些对业务的侵入性较强的不建议使用苹果的方式设置，尽量在业务中自己控制更加灵活，苹果这样做的考量可能是希望能在审核阶段把控尽可能多的内容。
• 几乎所有的配置都可以归结到Info.plist文件和xcconfig文件中，这两个文件中的所有键值对都映射到分散在Xcode各处的设置中，所以对于以iOS为目标平台输出Xcode工程的游戏引擎(如Unity、Unreal)，最好不用对应引擎中的后处理工作流，导致每次构建都重新设置这些设置项，而是将Info.plist文件和xcconfig文件作为游戏资源统一进行版本管理，在构建时覆盖到输出工程并应用即可。

参考链接: https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html