16 December 2019
Follow @_amordeCocoaPods 1.9 adds support for XCFrameworks, configuration-based dependencies for pod authors, code coverage in generated schemes, and other enhancements and bug fixes!
This release includes several quality-of-life enhancements in addition to important bug fixes.
XCFramework Support
With the release of Xcode 11, Apple introduced a new bundle format using the .xcframework
file extension. This format allows multiple copies of a framework compiled for different architectures and platforms to be combined into a single structure. XCFrameworks are also required for binary dependencies to support the new Catalyst platform introduced in macOS Catalina.
This release introduces support for Pod authors to ship vendored XCFrameworks using the existing vendored_framework DSL. Example:
Pod::Spec.new do |s|
s.name = 'ToastLib'
s.version = '1.0.0'
# ...rest of attributes here
s.vendored_frameworks = 'ButterLib.xcframework'
end
For apps that include Pods which vendor dynamic frameworks, a new script phase with the name [CP] Prepare Artifacts
will be added to the project to facilitate including the .xcframework
into the app bundle.
For additional details on how to create an XCFramework, check out Apple's WWDC talk Binary Frameworks in Swift which introduced the format.
Configuration-based dependencies for Podspecs
CocoaPods has long supported excluding dependencies from configurations in which they are not needed. For example, debug-only dependencies used during development can be included using the :configurations
option on the pod
Podfile DSL:
target 'BananaApp' do
pod 'Toast', :configurations => ['Debug']
end
This release extends this functionality to Pod authors. The same :configurations
option may now be used with the dependency
Podspec DSL:
Pod::Spec.new do |s|
s.name = 'ToastLib'
s.version = '1.0.0'
# ...rest of attributes here
s.dependency 'ButterDebugging', :configurations => ['Debug']
s.dependency 'ErrorReportingTool', :configurations => ['Release']
end
Note: Only Debug
and Release
configurations are currently supported. Support for specifying a custom configuration name might be added in the future.
Code Coverage in Test Specs
CocoaPods first introduced the ability to configure the generated Xcode schemes for Podspecs in version 1.7. This release adds support for enabling code coverage for tests by specifying the code_coverage
option within the scheme
DSL:
Pod::Spec.new do |s|
s.name = 'Networking'
s.version = '1.0.0'
# ...rest of attributes here
s.test_spec 'Tests' do |test_spec|
test_spec.scheme = {
:code_coverage => true, :environment_variables => {'FOO' => 'BAR' }
}
end
end
Swift Version Variants
As new Swift versions are released, Pod authors have added support for compiling their source with multiple Swift versions by using the swift_versions
Podspec DSL.
To better support this, the Podfile DSL was updated in 1.7 to allow users to specify what versions of Swift their apps support, using the supports_swift_version
DSL.
If two different targets include the same dependency but require different Swift versions, CocoaPods will now create multiple different targets for the same Pod to accommodate the different Swift versions used.
Given the following Pod:
Pod::Spec.new do |s|
s.name = 'CannonPodder'
s.version = '1.0.0'
# ...rest of attributes here
s.swift_versions = ['4.0', '5.0']
end
and the following Podfile:
target 'SampleApp' do
supports_swift_version '< 5.0'
pod 'CannonPodder'
end
target 'SecondApp' do
supports_swift_version '>= 5.0'
pod 'CannonPodder'
end
Two different versions of the CannonPodder
target will be created.
This ensures the correct Swift version is used for each target that depends on the Pod.
use_frameworks!
Linkage Customization
iOS 8.0 introduced the ability for apps to ship dynamically linked frameworks. To support this, CocoaPods introduced the use_frameworks!
DSL which made all Pods be compiled as dynamically-linked frameworks. Frameworks do not have any inherent linkage, but Swift initially required dynamic linking to be used in iOS apps. It is possible to wrap a statically-linked library in a .framework
bundle.
Now that Swift supports static linking, CocoaPods has expanded this DSL to allow specifying the type of linkage preferred.
use_frameworks! :linkage => :static
This is the first step in providing more control to CocoaPods users over how Pods are packaged and linked into their dependent binaries. For more details, check out the RFC.
What's Next
In future versions, we will continue to expand the customization points for how pods are integrated into projects.
Thanks to all of our contributors who helped make this release happen!
Checkout the changelog to see the full list of changes.