CocoaPods 1.7.0 Coming!

CocoaPods 1.7.0 release 最近已经发布，能够跟着官方的文档快速一览。不会简单的翻译官方文档，主要是跟着文档谈谈本身的见解。

CocoaPods 1.7.0 Beta 官方文档

另外一篇对官方文档的翻译

此次更新带来不少内容，解决了很多痛点。 官方的说法是底层也作了不少优化。

支持 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 去支持这个开源项目。