CocoaPods 1.5.0 — Swift Static Libraries

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.

Modular Headers

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:

    - Alamofire
    - Moya
    - 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.

Further Improvements

  • CocoaPods will no longer add all header search paths for each xcconfig generated 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 xcodebuild is now streamed when using --verbose
  • pod install performance 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.