Tweaking 3rd Party Libraries with Cocoapods

Posted by Ying Quan Tan on Mar 25, 2016 2:52:23 PM

Thanks to Git and CocoaPods, it’s fairly easy to access the libraries of others. But when you come across a bug or are developing bleeding-edge features for a third-party library it can be difficult to implement changes, which must be made in the library's repository before a new podspec is written to update the library. 

Fortunately, Cocoapods has a feature called development pods, which helps resolve bugs in third-party libraries. Below, I'll outline the workflow of development pods so you can work with and test your application changes right away.  

Let's say you come across a warning that you need to resolve, like the one below. By following the steps you and your teammates can use a new, warning-free library as you wait for the library owner to implement your changes.

 

cocoapods-warning-screenshot.png

Screenshot of a warning

 

Step 1: Clone the repository you want to fix

 cocoapods_antenna_library.png

Matt Thompson’s Antenna library, which has some warnings in XCode 7.

I have my own fork of the library and cloned it to a path like ~/Code/Antenna. If you are unfamiliar with forking github repos this is an excellent guide: https://help.github.com/articles/fork-a-repo/

 

Step 2: Make your podfile use the local path to the project

cocoapods_podfile2.png Podfile before the change

Screen_Shot_2015-11-29_at_8.48.24_PM.png

Podfile after the change

Now do a pod install. Notice that you should have changes in your Podfile.lock that indicate that you are now using a local development pod.

 gitdiffpodfile.png

git diff Podfile.lock

Now, you’re ready to make changes! Simply go into your project (not the library we just cloned), and fix those pesky warnings. In particular, I wanted to hunt down this warning, which turns out to have a pretty easy fix

alarm-nil.png

Cause for alarm - nil arguments.

This method is used to allow nil arguments, but with the advent of Swift and Nullability-type annotations, this method is now required to be nonnull, hence the warning.

So we simply fix it by providing a no-op argument.

pragma_alarm.png

Fixed warning!

Now, your project is clean and without warnings. But only half of the work is done! You still need to

  1. Tell the library author that something needs to be changed, a process that might take a while, and in the meantime...
  2. Allow your teammates to use that change and that they have a shiny, new, bug-free or warning-free library to use!

The amazing thing about local development pods is that you can change files within your project, thereby resolving issues in the context of your project. But at the same time these changes are reported on the fork of the repository you made! If you now go to the directory of the fork, you will see that there are changes to the repository:

 cocoapods_podfile.png

Changes you made in your project repository is in the third party library’s repository. Magic!

This is especially helpful if the fix is not as straightforward– maybe you have to iron out a bug and do rigorous testing before you make this change.

The good news is you’re ready to push your changes up at this point. Simply make a new branch off master, commit your changes, push it up to your local fork, and make a pull request.

library_owners.png

Library owners are often happy to have people resolving issues in their projects - who doesn’t like free code? 

Now that that’s resolved, you need to make the code work for your team members. Remember, we are still using a development pod, and therefore, all your changes local on your machine. Fortunately, at this stage, we can just point our podfile to our repository instead of to the main library repo. Again, this is the change to the podspec:

 cocoapods_podspec.png

Change the podspec to point to your repository’s fork

This simply says use the library at this repo, rather than the one specified in the podspec. The branch argument allows CocoaPods to use a specific version of the repository.

For a full list of options, see: https://guides.CocoaPods.org/using/the-podfile.html

And you’re done! Make sure you commit the changes to the Podfile so that your team can start using your changes. When the library owner accepts your pull request and updates the pod you can change your Podfile back to what it was before (and run pod update).

A little note about troubleshooting

If you run into issues where CocoaPods does not pick up changes when you try to update your pods, try removing what is in your ‘Pods/Local Podspecs’ directory. This directory is cached and causes pods not to update correctly.

Topics: Mobile, Cocoapods

Download the PDF