CocoaPods 1.7.0 “Coming!

CocoaPods 1.7.0 Release has recently been released and you can quickly follow the official documentation. I will not simply translate official documents, but mainly follow the documents to talk about my own views.

CocoaPods 1.7.0 Beta official documentation

Another translation of an official document

This update brings a lot of content and addresses a lot of pain points. The official line is that a lot of refinement has been done at the bottom as well.

Supports multiple Swift versions

This syntax can be used to describe a developer’s own Pod that ADAPTS to multiple versions of 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
Copy the code

When installing CoconutLib, Pod will select the latest version based on the current Xcode support.

Pod is also supported if you want a Target to use the specified swift version:

target 'MyApp' do
  supports_swift_versions '> = 3.0'.'< 4.0'
  pod 'CoconutLib'.'~ > 1.0'
end
Copy the code

Pod’s support for multiple versions of Swift has certainly been a boon to development. Pod determines the final Swift version to use based on the version specified in Target and the Swift version supported by CoconutLiub Spec itself.

Supports_swift_versions This DSL can be written in a Podfile and is assumed to be used by all targets.

Linting And Validation

This is mainly for service with CI/CD. Many superprojects are one projecet + multiple target compilations. If a Pod problem can be detected by Lint before compiling multiple targets, it will avoid wasting a lot of CI time compiling multiple targets simultaneously and failing with the same problem.

App Specs

In the past, to see how a Pod works, we had to compile its Example project separately. Pod now has the APP_Spec DSL built in.

 Pod::Spec.new do |s|
  s.name         = 'CoconutLib'
  s.version      = '1.0'
  s.authors      = 'Coconut Corp', { 'Monkey Boy'= >'[email protected]' }
  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
Copy the code

If you want to integrate SampleApp, just look like this:

target 'MyApp' do
   use_frameworks!
   pod 'CoconutLib'.'~ > 1.0', :appspecs => ['SampleApp']
 end
Copy the code

Generate multiple Pods Projects

Compared to previous new features, this feature definitely brings more convenience to the super App. When the App Project became super large, hundreds of pods were integrated into the same POD Project. The increasing size of pod.proj files can be a significant performance drain.

Using the Generate_multiple_Pod_projects option, you can have PODS generate a separate pod.proj project for each Pod.

The overall build structure is that the main project depends on the Pod Project, and then the Pod project depends on the individual Pod.

The first is the compilation cache that comes with it. For example, if you update files in Moya Pod separately, reinstall will be faster.

Another benefit is that I don’t have to open the full project when I just want to see the code in Moya.

However, CocoaPods cache can cause some puzzling bugs, and this feature is too radical for a formal Project, so try it now in a Side Project. After 1.7.0 release, you can try it slowly.

Typically, today’s apps are developed using Development Pods to split up individual business components, which separates the components one step at a time and prevents subordinates from referring to superiors in the code. Ensure that each individual component is truly independent.

Pod incremental installation

This feature is based on Multi Project because only with Multi Project can each Pod be separated separately from each other during compilation, enabling incremental installation.

The time consumption of Pod Install not only consumes a lot of time in the development process, but also creates a time bottleneck for CI. At present, the industry basically uses Pod Binary to reduce the compilation time of Pod. However, there are still many problems in the development process of Pod Binary. For example, Assert is ignored and problems cannot be discovered in advance.

I believe this feature can be a boon for developers.

scheme DSL

Each Pod will generate a corresponding Xcode WorkSpace Scheme, which is not usually used and configured by developers. However, this Scheme feature is easier to use as an official support.

Specifying environment variables and startup parameters is currently supported and will be expanded.

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   
Copy the code

Multi-platform support

Scheme DSL also supports platform, that is, it supports different schemes for iOS, macOS, Watch OS and tvOS.

For now, it’s probably only available on Test Spec and App Spec.

.xcfilelist Support

The.xcfilelist file is unused and Cocoapod now supports using.xcfilelist in Script Phase.

Equivalent to script execution of the file input and output path can also use variables, to facilitate can reduce the footprint of duplicate files. On the other hand, variables also support different values for different configurations such as Debug, Release, Alpha, etc., which is an extensibility enhancement.

Other features

CDN support for Master Specs Repo.

This feature doesn’t seem to work for larger apps either. For one thing, companies may maintain a Master or place podsepc directly on the company platform.

It is rare to use Master directly, especially after Binary of a third party library.

review

Cocoapod is currently the de facto standard for iOS development. Thanks to its open source features and convenient extensibility, many companies will customize it. Cocoapods has many disadvantages stepped on by developers, and many large companies have special teams for Pod development.

While Pod is somewhat awkward, as a de facto standard, developers still have to learn and use it properly.

It is a pity that the big domestic manufacturers are using it and developing many private extensions for the project, but have not submitted PR to support the open source project.