CocoaPods 1.8 switches the CDN to the default Spec repo source and comes with some enhancements!

Note: if you reprint this article, please contact the author and give the source address of the article

CDN is the default value

CDN support was first introduced in version 1.7 and finally completed in 1.7.2. It is designed to greatly speed up initial setup and dependency analysis. With 1.8, CocoaPods no longer needs to clone the now huge master spec REPO to run, and users can integrate their projects with CocoaPods almost immediately.

Here’s a video demonstration of integrating and building iOS projects with newly installed CocoaPods 1.8 in less than a minute:

You can safely remove the master repository using the following steps:

First, edit the Podfile to set the CDN as the primary source:

- source 'https://github.com/CocoaPods/Specs.git'
+ source 'https://cdn.cocoapods.org/'
Copy the code

Then, run the following command to remove it from the managed repository list:

pod repo remove master
Copy the code

Note: If you want to continue using git-based sources, you must make sure you specify it explicitly in your Podfile via the source DSL, or CocoaPods will automatically use CDN for dependency resolution.

That’s it! For more information on CDN, please read the previous blog post!

info_plist Podspec DSL

CocoaPods automatically generates info.plist files for pod, APP, and test specifications when appropriate, such as when Podfile requires dynamic frameworks by specifying use_frameworks! Options.

Podspecs now supports modifying the contents of generated info.plist files via the Info_plist DSL. Although we expect this to be most commonly used to modify the framework’s package identifier, it can include any key-value pair. The specified value will override any default values included in CocoaPods.

Here’s an example:

Pod::Spec.new do |s|
  s.name         = 'NetworkingLib'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.info_plist = {
    'CFBundleIdentifier'= >'com.awesomecompany.networking'.'SERVER_URL'= >'https://example.com/api'
  }
end
Copy the code

With the introduction of the APP specification in 1.7, POD authors are able to describe an application for their POD, such as a demo application. The new Info_plist DSL enhances the functionality of the application specification by allowing Podspecs to customize the generated info.plist, which contains important Settings such as package identifiers, iOS security and privacy Settings, device orientation support, and more.

Pod::Spec.new do |s|
  s.name         = 'ToastLib'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.app_spec 'ToastCatalog' do |app_spec|
    app_spec.info_plist = {
      'CFBundleIdentifier'= >'com.bakery.ToastCatalog'.'UISupportedInterfaceOrientations'= > ['UIInterfaceOrientationPortrait'.'UIInterfaceOrientationLandscapeLeft'.'UIInterfaceOrientationLandscapeRight',].'UILaunchStoryboardName'= >'LaunchScreen'.'UIMainStoryboardFile'= >'AppStoryboard'.'NSLocationWhenInUseUsageDescription'= >'ToastCatalog uses your location to find nearby Toast! '
    }
  end
end
Copy the code

It is important to note that the info_plist property has no effect without generating an info.plist file, such as when integrating pod into a static library. If your library needs to always have the data contained in info.plist, we recommend that you include it as a resource.

For more details on how it works and the rationale behind it, check out RFC here.

project_name Podfile DSL

CocoaPods 1.7 introduces the Generate_multiple_Pod_projects option, which installs each POD into its own Xcode project. CocoaPods 1.8 expands further by introducing the Project_name DSL to allow POD consumers to specify project names to integrate with a given POD.

This opens up a lot of new possibilities for consumers, and grouping certain pods together makes logical sense. Consider the following example:

install! 'cocoapods'.:generate_multiple_pod_projects= >true

target 'MyApp' do
  use_frameworks!

  pod 'Moya'.:project_name= >'Networking'
  pod 'Alamofire'.:project_name= >'Networking'
  pod 'Result'.:project_name= >'Networking'

  target 'MyAppTests' do
    inherit! :search_paths
    pod 'OCMock'.:project_name= >'Testing'
  end
end
Copy the code

The following results will occur:

Consumers can select their own grouping and provide helper methods to automatically apply the item name in their Podfile. For example, another grouping idea is to group pods by their platform, such as iOS or macOS.

Note: The project_name option currently also needs to enable the Generate_multiple_POD_projects installation option for it to work properly. The incremental installation has also been updated to take into account the project name used by each pod and will continue to work as expected.

Test specification enhancements

The testing specification has become part of CocoaPods and some new features have been added.

UI test pack support

The “UI test pack” is now supported, and you can now specify the test_Type to be used for a given test_Spec. The default value is unit, which is used to create unit test packages. Consider the following example of our favorite pod CannonPodder:

Pod::Spec.new do |s|
  s.name         = 'CannonPodder'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.test_spec 'UITests' do |test_spec|
    test_spec.requires_app_host = true
    test_spec.test_type = :ui
    test_spec.source_files = 'UITests/**/*.swift'
  end
end
Copy the code

This will successfully integrate the CannonPodder-UI-Uitests UI test pack at installation time and will automatically create the application host to be used with it.

Note: THE UI test package requires an application host to run, so if you choose to integrate the test specification into the UI test package, you must always specify REQUIRES_APP_host.

Customizable application host

For the most part, the generated test specification application host should be sufficient to perform tests in. However, there are cases where pod authors may wish to further customize the APP host for test_Spec.

For example, a POD author might want to specify additional dependencies for their application host or resource bundle to use during testing. Application specifications are a good candidate because they provide most of the scaffolding and 1.8 app hosts that can now set app_spec to test_spec via the APP_host_name DSL.

Here’s an example:

Pod::Spec.new do |s|
  s.name         = 'CannonPodder'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.app_spec 'DemoApp' do |app_spec|
    app_spec.source_files = 'DemoApp/**/*.swift'
    # Dependency used only by this app spec.
    app_spec.dependency 'Alamofire'
  end

  s.test_spec 'Tests' do |test_spec|
    test_spec.requires_app_host = true
    # Use 'DemoApp' as the app host.
    test_spec.app_host_name = 'CannonPodder/DemoApp'

    # ...rest of attributes here

    # This is required since 'DemoApp' is specified as the app host.
    test_spec.dependency 'CannonPodder/DemoApp'
  end
end
Copy the code

The following results will occur:

This powerful new feature opens up new possibilities for POD authors who want finer control over the APP host used to test specifications.

What’s next?

CocoaPods 1.8 is a very exciting release and we are happy for you to try it out and recommend you upgrade:

$ gem install cocoapods --pre
Copy the code

For future releases, we will continue to explore new ways to allow POD authors and POD consumers to configure integrated PODS into their projects, for example by specifying individual package or link Settings. We have released a proposal that we are exploring and welcome your comments!

As always, we’d like to thank all contributors for making this release a reality!

Check out the change log for a complete list of changes.