前言
相信大家在开发项目中，难免会遇到一些多项目管理的困扰，如马甲项目、BC端项目等，功能大有雷同，或者说想用同一个项目框架，多项目管理就显得格外重要。
下面提供两种方法来管理：
一、Target
相信大家也都知道，大部分都选择会用这种方法，我简单整理出添加步骤和添加时常出现的问题：
1、添加target
2、拷贝原有的Info.plist替换新的后，进行修改BundleID、App名称、URL Schemes等相关信息
3、build settings 中设置prefix.Pch路径
4、兼容资源，在目录里添加资源，常有的资源后缀有: .m、.c、.a 、 frameword 、.tdb 、.xib 、.storyboard、.xcassets 、.bundle 、.txt 和 .string，
5、修改Podfile内容后，更新Pods
6、代码中辨别不同Target的处理方法：
build settings 中设置other C Flags 添加-D****=1
7、如不兼容Bitcode 记得改为 NO
8、有用到JsonKit等一些非ARC资源 需添加 -fno-objc-arc
9、RAC报错：cannot create weak reference in file using：
解决办法：https://blog.csdn.net/u010545480/article/details/52995908
13、支付宝报错 ’openssl/asn1.h' file not found
解决办法：https://blog.csdn.net/Mouse_Wang/article/details/50373798
二、xcconfig
xcconfig是用来保存build setting键值对的文件，里面是一些纯文本；
//:configuration
= DebugPRODUCT_BUNDLE_IDENTIFIER = com.loyinglin.devDISPLAY_NAME =
测试标题PRODUCT_NAME = LearningGCC_TREAT_WARNINGS_AS_ERRORS =
YES//:configuration = DebugGCC_PREPROCESSOR_DEFINITIONS = $(inherited)
COCOAPODS=1SSDEBUG=1
比如这里配置是一份debug的xcconfig，其中PRODUCT_BUNDLE_IDENTIFIER = com.loyinglin.dev的键值会在编译的时候生效。
一个Xcode工程，一定会有Debug的开发环境和Release的发布环境，可能会有Testflight的灰度环境、DailyBuild的持续集成环境、XXLanguage的多语言环境、TestCoverage的覆盖率测试环境、IAP的内购测试环境等；每个环境所用的证书不同，APP安装后显示的名字不同，provision file也不同等等。
此情况是可以使用Target来解决，公用的部分设置在project，每个环境根据各自特点自定义某些设置；这样带来的后果是target数量增多明显，而target增多带来的后果是当需要新增extension的时候会工作量巨大，并且多环境的管理难度加剧。
另外一种方案是使用Configuration来区分环境，而xcconfig就是用来管理Configuration的文件。
如何创建和使用xcconfig？
1、在Xcode中新建文件，输入config，选择configuration settings file；这一步是创建xcconfig的文件。
2、在Xcode中选中工程，在configurations中选择需要配置的选项，这里以debug为例，点击后选择刚刚已经创建的xcconfig，则可以把xcconfig和debug的编译选项绑定在一起。
如果你用了cocoaPod，你会发现这一项已经有了CocoaPod创建xcconfig，如果选择了自己新建的xcconfig，则会编译失败；
此时可以在自己新建的xcconfig头文件中加入以下代码：
#include"Pods/Target Support Files/Pods-YourName/Pods-YourName.debug.xcconfig"
注意需要修改成自己的工程名。
3、在build setting选中某个配置项，cmd+c复制然后到xcconfig的文件中，cmd+v就可以复制配置项到xcconfig中。
注意如果这个配置项在build setting已经有自定义值，需要将其删除，原因下面解释。
image.png
xcconifg的配置和工程默认配置、手动在build setting配置有什么区别？
配置的结果优先级不同，我的理解是：
a、project默认配置是最低优先级，因为是最基础的配置；
b、target配置基于project，但target默认会添加一些配置，优先级比上面高；
c、xcconfig的配置是target某个config的配置，优先级比上面高；
d、target的build setting中直接添加的配置项，优先级比上面高；
手动配置项
知道上面的关系后，我们可以解决使用xcconifg时，CI 打包xcconifg配置项不生效的问题：
检查是否对应配置项是否在target的build setting中直接添加；
如果需要新增某个configuration，可以直接duplicate已有的configuration，但是如果使用Pods需要重新pod install，以生成对应的pod工程的配置项，否则会出现下图的报错：
找不到对应库，因为新的configuration没有设置对应的file
