CocoaPods 1.5.0 comes with native support for building Swift pods as static libraries.
Just a few months after the release of CocoaPods 1.4.0, we're releasing a new version that focuses on enabling everyone to adopt Swift.
Swift Static Libraries
Up until Xcode 9, support for building Swift into static libraries was non-existent and use of dynamic frameworks was required. This was a deal-breaker for some developers, particularly those worried about the launch performance implications of linked many dynamic binaries.
With CocoaPods 1.5.0, developers are no longer restricted into specifying
use_frameworks! in their
Podfile in order to install pods that use Swift.
Interop with Objective-C should just work.
However, if your Swift pod depends on an Objective-C, pod you will need to enable "modular headers" (see below) for that Objective-C pod.
When CocoaPods first came out many years ago, it focused on enabling as many existing libraries as possible to be packaged as pods. That meant making a few tradeoffs, and one of those has to do with the way CocoaPods sets up header search paths. CocoaPods allowed any pod to import any other pod with un-namespaced quote imports.
For example, pod B could have code that had a
#import "A.h" statement, and CocoaPods will create build settings that will allow such an import to succeed. Imports such as these, however, will not work if you try to add module maps to these pods. We tried to automatically generate module maps for static libraries many years ago, and it broke some pods, so we had to revert.
In this release, you will be able to opt into stricter header search paths (and module map generation for Objective-C pods). As a pod author, you can add
'DEFINES_MODULE' => 'YES' to your
pod_target_xcconfig. Alternatively, in your Podfile you can add
use_modular_headers! to enable the stricter search paths and module map generation for all of your pods, or you can add
:modular_headers => true to a single
pod declaration to enable for only that pod.
Tracking Installation Sources
This change happens behind-the-scenes, and opens up some exciting possibilities. CocoaPods will now store the specs repo that a Pod has been sourced from:
SPEC REPOS: https://github.com/CocoaPods/Specs.git: - Alamofire - Moya https://github.com/Private/Internal.git: - InteralPod
This will enable CocoaPods to be able to tell you when the source for a pod has changed, and will also force a noticeable
git diff in the
Podfile.lock, making sure you're aware when a Pod comes from a different source. This makes it possible to audit that your private forks are being used, instead of public specs, for example. We consider this a helpful security enhancement, especially for those teams with Security Engineers peering over their shoulders.
- CocoaPods will no longer add all header search paths for each
xcconfiggenerated and instead, it only adds the header search paths for the dependencies of the pod
- Static frameworks allow mixing Objective-C and Swift
- During pod validation, any output from
xcodebuildis now streamed when using
pod installperformance is improved both for pods with many subspecs, as well as pods which specify exact file paths rather than globs
- Script phases used by CocoaPods will now assert that all expected build settings (and environment variables) are set
- Integrating static library pods into static library targets will not cause copy script phases to be run
CocoaPods 1.5.0 is an exciting release. We're very excited for you to try it out, and recommend you upgrade:
$ gem install cocoapods
After all of this excitement, here's a taste to whet your appetite for the next CocoaPods version. For 1.6.0, we're focusing on redesigning core parts of the library to improve CocoaPods performance for very large applications.
So, if you're feeling like
pod install is taking a tad longer than you'd like, stay tuned 😉
As always, we would like to thank all of our contributors for making CocoaPods 1.5.0 a reality!
Checkout the changelog to get the full list of changes.