You should be using CocoaPods
There are four key disadvantages to not using CocoaPods, arguably the best dependency manager for your iOS projects.
- Libraries take up space.
- Updating libraries can be time consuming.
- Updating a library will only take effect within that single project.
- Finding other libraries to use can be difficult
Simply placing your project dependencies in a folder titled ‘Lib’ can make the project become bloated. Each library consists of several classes, some of which may never be used in your project, however they are still there claiming MBs of data. It is true that third-party libraries are often small, only providing a few methods of functionality so that another developer does not have to spend the time doing it themselves. However, there is no need to unnecessarily increase the size of your project. By using CocoaPods, the dependency manager will place all libraries in a folder named Pods.
This is no different to putting them in a Lib folder, but the advantage of CocoaPods is that you have a file that holds a reference to all of the third-party libraries being used in the project. These are kept in the CocoaPods central repository which will make it easy for any developer to find the library they require.
The presence of the Podfile allows developers to push the project source code to a hosted central repository such as GitHub or Bitbucket, whilst ignoring the Pods directory. Other developers working on the same project can then simply install all of the required dependencies using one of CocoaPods commands. CocoaPods is able to do this by cross-referencing the libraries referenced in the Podfile with the CocoaPods central repository of libraries. This keeps the Pods folder local, and does not take up extra space on the hosted repository.
Without a dependency manager, updating libraries to their latest versions could take considerable time, depending on the number of third-party libraries that are housed in the projects `Lib` folder. This is because each individual project must first be checked to see if there is a new version available, and then that new version will have to be downloaded and placed into the project, replacing the now deprecated version. It is clear to see how this three stage task could take a while to be completed.
This is where CocoaPods becomes useful again. Simply running the update command will check the Podfile for the list of dependencies and then check the central repository for new versions. If there are new versions, the libraries will be updated. The once time consuming, three stage process, becomes a single command and CocoaPods handles the rest.
By using a third-party library, you are relying on the developer(s) of the library to maintain that code and keep it available for others to use.
When the time comes to update the library, or implement again in a different project, the source code may no longer be publicly available. This would likely mean that you would have to find a new library to use, as with each iteration of iOS, the library is likely to have some features deprecated or in the case of UI libraries, the interface may no longer be consistent with the rest of the UI or conform to the new standards.
Any developer of a third-party library can turn their project into a Pod which makes it easily distributed via CocoaPods. The CocoaPods team will then host these Pods on their website, and keep an archive of them. This means that by using a library from the CocoaPods repository, you can be sure you will not lose a reference for that library in the future.
Using open-source, third-party libraries allows some flexibility with development. Implementing a library and then tweaking some of the aspects and functionality of it is a quick way of customising native elements and behaviours because most of the work was done by the third-party developer. However, those changes will only be local to that one project where the library has been edited. To get these changes in another project, the edited library would have to be copied into the other project(s).
Each Pod is open-source which means, if you were to make your changes in the central repository where the library is hosted, every other developer instantly has access to your changes. This could be a big advantage if you are making improvements to the library that will be beneficial to many others, and not just small changes.