Dependencies are at the core of programming. In iOS, we often use Cocoapods to manage dependencies in our projects. But if we are not careful, we can add a dependency that is not free to use, and expose our company to legal issues later. That’s why it’s really important to verify the LICENSE files of each dependency before adding it.
But we all know that humans make mistakes, so in this article, we’ll cover how to automate the process of verifying each dependency.
Note: If you want to know more about the different kinds of licenses, go check https://choosealicense.com/.
Listing the licenses
First of all, if you want to quickly see the state of the licenses in your project, I created a gem called ADLicenselint that lists the licenses for each pod in your Podfile.
To use it, install the gem and run
ad_licenselint in the directory that contains the Podfile.
Note: by default the gem prints the dependencies that have licenses not free to use, but you can print the whole list with the
You can check all the other options on the github page directly.
Under the hood, the gem uses the plists generated by Cocoapods during the
pod install. The plists are located here:
Pods/Target\ Support\ Files/Pods-MyApp/Pods-MyApp-acknowledgements.plist.
Here is an example of one entry in the plist for the pod
The gem simply parses this file and extracts the informations for each pod. By default, the licenses automatically validated are
Apache 2.0 and
BSD. Every license that is not included in this list will be considered unsafe.
Using it with fastlane
Along with the gem, you can find a fastlane plugin that can be used in your Fastfile.
First add the plugin to your Pluginfile:
Then call the
ad_licenselint action with your parameters:
summary is a string and can be printed as is, whereas the
report hash has the following structure:
Once we have access to the license linter in our lanes, we can imagine some nice use cases.
Pull request comment
Let’s say you want to post an automatic message to your pull request if you detect that a pod with a commercial license has been used.
For instance, let’s add
ObjectivePGP (with a commercial license) and update
ADUtils (with a MIT license) in our Podfile.
Once the pull request is pushed to Github, here is an example of an automatically posted message:
With this warning, the developer can check if he really wants to use this dependency or not.
The code to automatically post this message in a pull request can be found here. In this case we use the formatted report summary available in
lane_context[:AD_LICENSE_LINT_SUMMARY] after we called
Note: what is interesting here is to use the gem
cocoapods-core to get the list of updated pods for a branch. This library is useful if you want to manipulate the Podfile and Podfile.lock backing models.
The following snippet shows an example of what you can do with the library:
Pull request review
You could also imagine posting a review directly to the Podfile in the pull request.
For instance if we add the same pod
ObjectivePGP, we can create this automatic review:
The code to automatically post this review in a pull request can be found here. This example uses the report summary hash available in
lane_context[:AD_LICENSE_LINT_REPORT] after we called
Note: to interact with the Github api, we use the
octokit gem that is really simple to use:
The earlier you know a dependency is not compatible with your project, the earlier you can reject it and search for another alternative. The best option is always to go to the Github page of the pod and check the LICENSE file, but ADLicenselint has been developed to act as an extra safeguard.
The fastlane plugin along with the gem should give you all the tools you need to use it in your workflow if you want to automate the linting process.