CocoaPods 1.7.0 release 最近已经发布，可以跟着官方的文档快速一览。不会简单的翻译官方文档，主要是跟着文档谈谈自己的看法。
这次更新带来很多内容，解决了不少痛点。 官方的说法是底层也做了很多优化。
支持 Swift 多版本
对于开发者自己的 Pod，如果对多个版本的 swift 做了适配，可以使用该语法描述：
Pod::Spec.new do |spec|
spec.name = 'CoconutLib'
spec.version = '1.0'
# ... rest of root spec entries go here
spec.swift_versions = ['3.2', '4.0', '4.2']
end
Pod 在安装 CoconutLib 时，会根据当前 Xcode 支持，选择最新的版本。
如果希望某个 Target 使用指定的 swift 版本，Pod 也是支持的：
target 'MyApp' do
supports_swift_versions '>= 3.0', '< 4.0'
pod 'CoconutLib', '~> 1.0'
end
Pod 对 Swift 多版本的支持，无疑给开发这带来了福利。Pod 会根据 target 中指定的版本以及 CoconutLiub spec 本身所支持的 swift 版本，一起决策出最终使用的 swift 版本。
supports_swift_versions 这个 DSL 可以写在 Podfile 中，会被认为所有的 target 都使用。
Linting And Validation
这个主要是为了服务与 CI/CD 。 很多超级工程都是一个 projecet + 多个 target 编译。 如果在编译多个 target 之前就能通过 Lint 检查出 Pod 的问题，那么就避免同时编译多个 target ，又同时因为同一个问题失败，浪费大量 CI 时间。
App Specs
在原来，如果想要了解某个 Pod 怎么使用，我们需要去单独编译它的 Example 工程。 现在 Pod 内置了 app_spec DSL。
Pod::Spec.new do |s|
s.name = 'CoconutLib'
s.version = '1.0'
s.authors = 'Coconut Corp', { 'Monkey Boy' => 'monkey@coconut-corp.local' }
s.homepage = 'http://coconut-corp.local/coconut-lib.html'
s.summary = 'Coconuts For the Win.'
s.description = 'All the Coconuts'
s.source = { :git => 'http://coconut-corp.local/coconut-lib.git', :tag => 'v1.0' }
s.license = {
:type => 'MIT',
:file => 'LICENSE',
:text => 'Permission is hereby granted ...'
}
s.source_files = 'Sources/*.swift'
s.app_spec 'SampleApp' do |app_spec|
app_spec.source_files = 'Sample/*.swift'
end
end
如果想要集成 SampleApp 进来，只需如下这般：
target 'MyApp' do
use_frameworks!
pod 'CoconutLib', '~> 1.0', :appspecs => ['SampleApp']
end
生成多个 Pods Project
相比较之前的新特性，这个特性无疑给超级 App 带来了更多的方便。 当 App 工程变得超级庞大时，上百个 pod 都集成在同一个 Pod Project 中。pod.proj 文件越来越大，会带来极大的性能消耗。
使用 generate_multiple_pod_projects 选项，可以让 Pod 为每一个 Pod 单独生成一个 pod.proj 工程。
整体的编译结构，是 main project 依赖 Pod Project ，然后 Pod Project 依赖于单独的 Pod。
首先是带来的编译缓存，比如单独更新了 Moya Pod 中的文件，重新 install 会比较快一些。
另一个好处，我只想要看 Moya 中的代码时，可以不用打开完整的工程。
不过 CocoaPods 的缓存会带来一些莫名其妙的 Bug，这个特性用于正式的工程还是太激进，可以现在 Side Project 中尝试。等 1.7.0 release 之后，可以慢慢尝试。
一般而言，现在的 App 都是用 Development Pods 拆分单独的业务组件进行开发，这种将组件进行一步独立，也便于在代码中防止下级引用上级。能保证每一个单独的组件真正的 独立 起来。
Pod 增量安装
这个特性是基于 multi project 的，因为只有使用 multi project，才能将每个 Pod 单独分开，在编译过程中不相互依赖，从而实现增量安装。
Pod Install 的时间消耗，不仅是在开发过程中消费大量时间，同时也是 CI 的时间瓶颈，目前业内基本是通过 Pod Binary 的方式，减少 Pod 的编译时间，不过 Pod Binary 在开发过程中，仍有不少问题存在，比如 Assert 被忽略，无法提前发现问题。
相信这个特性可以给开发者带来福音。
scheme DSL
每个 Pod 都会生成对应的 Xcode WorkSpace Scheme，虽然开发者一般不会去使用和配置，不过这个 scheme 特性，作为官方的支持还是要方便一些。
目前支持指定环境变量和启动参数，之后会继续拓展。
Example：
Pod::Spec.new do |spec|
spec.name = 'CoconutLib'
spec.version = '1.0'
# ... rest of root spec entries go here
spec.test_spec 'Tests' do |test_spec|
test_spec.source_files = 'Tests/**/*.swift'
test_spec.scheme = {
:launch_arguments => ['Arg1', 'Arg2'],
:environment_variables => { 'Key1' => 'Val1'}
}
end
end
多平台支持
scheme DSL 也是支持 platform 的，也就是支持为 iOS、macOS、watch OS、tvOS 设置不同的 scheme。
目前看来，可能只有在 Test Spec 和 App Spec 上才能用得到。
.xcfilelist Support
.xcfilelist 文件没有用过，cocoapod 现在支持在 Script Phase 阶段使用 .xcfilelist。
相当于是脚本执行的文件输入输出路径也可以使用变量，以方便可以减少重复文件的占用。 另一方面，变量自然也支持 Debug、Release、Alpha 等不同配置下用不同的值，也算是拓展性增强吧。
其他特性
为 Master Specs Repo 提供 CDN 支持。
这个特性对于大一点的 App 貌似也没什么用，一方面，公司内部会维护一个对应的 Master，或者直接将使用到的第三方库的 podsepc 放在公司平台上。
尤其是在对第三方库进行 Binary 后，一般很少直接去使用 Master 了。
回顾
Cocoapod 作为 iOS 开发目前的事实标准，得益于其开源特性和方便的可拓展性，很多公司都会对其进行定制，Cocoapods 有很多坑被开发者踩到，很多大公司内部也是对 Pod 有专门的团队去负责开发拓展。
虽然 Pod 有些地方挺坑的，但作为事实标准，开发者还是不得不去学习并正确使用它。
很可惜的是，国内的大厂都去使用它，并且开发了很多私有的拓展用于工程中，却没有提交 PR 去支持这个开源项目。
