CocoaPods has been magical dependency managers for iOS developer so far. Very few developers understand what happens under the hood when they run pod install command. However, CocoaPods has been proved to be painless dependency manager in the iOS ecosystem. Personally, I had love/hate relationship with CocoaPods so I wrote a blog post CocoaPods Or Carthage- That’s the question comparing two very popular iOS dependency management system. CocoaPods has just announced the version 1.7.0 beta with lots of great features which make me happy. You can read all the announcements on the CocoaPods blog here. There are some killer feature announced which can significantly reduce your build time as well as gives you better control over the iOS project. Let’s explore these five upcoming features briefly.
How to Get New CocoaPods
Before we jump into the shiny new feature of the CocoaPods 1.7.0 beta, we need to upgrade the version of CocoaPods. You can get the pre-release version using the Ruby gem by running following command.
1 2 3 |
$ gem install cocoapods -v 1.7.0.beta.1 OR $ gem install cocoapods --pre |
You will get the latest CocoaPods feature when the installation is successful. You might need to use sudo if you are not using Ruby version manager. Now that, you have all the features of the Cocoapods with the latest version. I have created a sample Github repository to play with this new shiny features. Check PodNews on Github.
CocoaPods 1.7.0
Let’s explore all the shiny features of CocoaPods 1.7.0.
1] Incremental Installation
One of the reason, I hate CocoaPods a lot because it builds all the dependent framework from scratch for the clean build. This takes a lot of time and builds time increases a lot especially if you are not doing incremental builds. On the cloud CI services, they usually create fresh VM for each build and CocoaPods build all the frameworks from scratch unless you cached it.
This killer feature of incremental_installtion solved this problem, with incremental installation, CocoaPods only regenerate the targets that have been changed since last pod install command. We can enable this feature by adding this code to the Podfile
1 2 |
install! 'cocoapods', :incremental_installation => true |
Now, every time you run pod install only changed frameworks will be built. On CI, we still need to cache the dependencies but it’s a great improvement and will save loads of developer time.
Benefits: Faster builds and Developer productivity.
2] Support Multiple Swift Versions & Pod Projects
Swift is an evolving programming language. The new version of the Swift lands every now and then and library author has to keep their projects up to date with latest Swift version. You might have often seen this error
1 |
Module compiled with swift 4.0 cannot be imported in swift 4.2 |
This error usually causes when the dependency module is not up to date with the latest Swift. Now you don’t have to worry about it, as a library author, you can specify the multiple Swift versions in the Podspec file.
1 2 3 4 5 6 |
Pod::Spec.new do |s| s.name = 'PodNews' s.version = '0.1.0' # NEW ====================== s.swift_versions = ['3.2', '4.0', '4.2'] end |
Now, PodNews library can be supported with Swift 3.2, 4.0 and 4.2. All the user of this library can also mention supported Swift versions in the target.
1 2 3 4 |
target 'PodNews_Example' do supports_swift_versions '>= 3.0', '< 4.2' pod 'PodNews' end |
The supports_swift_versions DSL can also be declared at the root level of the Podfile.
Now that, author of the library and user of the libraries doesn’t need to rush to support the latest Swift versions. Another feature is Cocoapods now generate multiple pod projects. We can enable that feature from Podfile
1 2 |
install! 'cocoapods', :generate_multiple_pod_projects => true, |
Benefits: Multiple Swift version support makes the life of library developers painless.
3] Define App Specs for Example Apps
CocoaPods has already announced the support for the test specs but now it’s been expanded to the app specs. App specs will be a great way to demonstrate to users how the library works using the example app. Authors can define the App specs in the Podspec file as
1 2 3 4 |
# NEW ====================== s.app_spec 'Example' do |app_spec| app_spec.source_files = 'Example/PodNews/*.swift' end |
The user of this library can optionally use the App Specs by defining the target library wit App specs as follows:
1 2 3 4 |
target 'PodNews_Example' do # NEW ====================== pod 'PodNews', :path => '../', :appspecs => ['Example'] end |
BenefitL App specs can make your library much lightweight.
4] Dynamic Scheme Launch Arguments/Environments
CocoaPods will give you an option to pass the launch arguments and launch environments to the test specs. The scheme will automatically take this variable for run action in the scheme. In the Podspec, the author can define it as
1 2 3 4 5 6 7 |
s.test_spec 'Tests' do |test_spec| test_spec.source_files = 'Example/Tests/**/*.swift' test_spec.scheme = { :launch_arguments => ['Quick', 'XCTest'], :environment_variables => { 'XCTest' => 'false'} } end |
We can define this variable applicable to specific platforms e.g iOS the only scheme can be defined as test_spec.ios.scheme in the Podspec.
Benefit: This feature can be used for running tests with different configurations.
5] Automatic Generation of .xcfilelist
Apple announced the support for the .xcfilelist file when the input and output paths in the Run Script phase increases. We can create a separate file and add it there. CocoaPods will automatically detect if the file creation is needed or not and generate the Run Script phase accordingly.
Benefit: This can be used for easy duplication the build configuration
Source Code
Sample Source code on Github: PodNews
Conclusion
CocoaPods has come back very strong with these amazing features. This new features will dramatically reduce the build time and library authors will have lots of freedom while creating new libraries or SDKs. Hope you will try these features as soon as a stable release is published! Well Done CocoaPods team!