How should a dependency manager work?

A dependency manager (like Cocoapods) should work like a package manager (homebrew). I might be opinionated. But read on.

In my opinion, Cocoapods (or any dependency manager) should install a dependency in a way that one should not be able to tell whether the dependency was installed using Cocoapods or by manually editing the project file.

Example 1

I open the project’s root directory in terminal and type

pod install MKNetworkKit

Expected Behaviour:

Cocoapods updates the project and (optionally) creates a git commit.

These pods can (optionally) be scripted (much like how you script pacman/yum/homebrew installs)

Example 2

Another alternative is a Cocoapods Xcode plugin, much like Alcatraz. But instead of installing tweaks, this plugin installs dependencies right into the active project.

How does Cocoapods work now?

Cocoapods expect that you to create a pod spec and run this script to install dependencies. Now, everytime you want to add a new dependent framework (or update an existing framework), you have to update the spec and re-run the script.

This scripting language is not XML/JSON/YAML/Bash. It’s a Ruby script.

It all sounds great on paper till you encounter your first bizzare dependency related error. As such, it doesn’t really solve the problem of managing dependencies. Instead of solving the problem, it just takes the complexity to a different domain (which some people might find easier). So instead of learning the Xcode’s way of doing things, you have to learn the Cocoapods way of doing things (which I find is annoying).

Lastly, Yes, call me a sucker, but I hate when Cocoapods creates a workspace and “pollutes” my project directory. This makes it extremely complicated to add a dependent library manually. Yes, I can add these libraries through Cocoapods, but what about libraries that don’t have a pod spec file yet?

Advantages of the proposed method

The advantage of the proposed method (Example 1 and 2) over the current method is, if a new developer takes over a project, and if he prefers Xcode way of adding dependencies, he can still do it. Right now, because of all those workspace overload, adding a dependency to a project normally is more complicated. Cocoapods, kind of thrusts “their way of doing things” onto everyone. It’s more like “my way or the highway” with a “But it’s easy once you learn” teaser.

Once you go Cocoapods, it’s almost like, there is no other choice except removing the cr*p out of the project. (Sorry for the expletive)

Would you have used Mac App Store, if the rule set by Apple was, once you get your first app from Mac App Store, every other app you install on your Mac should be through Mac App Store? (See it’s easy. Just one click!)

Would you have even bothered to use homebrew or pacman if the rule is, once you install your first package, every other package/installation should be done using homebrew?

When these installation managers can work nicely with “legacy” systems, why can’t Cocoapods?

Cocoapods might make it easy to get you started with a new project. Writing your boilerplate project files might be easier. But creating a separate workspace, polluting my project directory is too much to yield from a “power developer”‘s perspective for the limited benefit you get by using Cocoapods.

Again, how often do you start a new project? I take client work and I probably do about 2-3 new projects a year. Even if you do like 10-15 projects a year, is Cocoapods worth it?

— Mugunth

Follow me on Twitter

  • Victor Ilyukevich

    > Yes, I can add these libraries through Cocoapods, but what about libraries that don’t have a pod spec file yet?

    You could always create a missing podspec. It’s not hard.

    > Would you have even bothered to use homebrew or pacman if the rule is, once you install your first package, every other package/installation should be done using homebrew?

    Nothing stops you from adding some libraries using CocoaPods and others in manual way. I don’t get your point here.

    > Even if you do like 10-15 projects a year, is Cocoapods worth it?

    Of course! It’s a time saver. If some work can be automated why not? 😉

    Also please note, the correct spelling is CocoaPods – 😉

    • MugunthKumar

      ApproveSent from my iPhone
      Mugunth Kumar
      Author | Developer | Trainer
      iOS 7 Programming Pushing the Limits

    • MugunthKumar

      Do you think it is still a time saver if I create podspecs for all the libraries I use?

      • Victor Ilyukevich

        It’s hard to remind when I saw last time a library which doesn’t have a podspec yet. I suppose almost all popular libraries these days have podscpec files. Maybe not always in theirs repos, but at least in CocoaPods/Spec repo. Could you please be more specific what libraries do you use which don’t have podspec files? Thanks.

      • Barrett Jacobsen

        Yes. I even create ones for my own private libraries that are then hosted in a private podspec repo. I also keep a text expander snippet for a “default podfile” that contains the libraries I’m likely to want by default (and I can just comment out the ones I don’t need for that project).

  • Taylor Marks

    I concur with this blog post 100%. I thought that CocoaPods was going to be some kind of solution like Python’s Pip, where it’s just a handy tool that automatically adds frameworks for you so that you don’t have through the tedious process of finding the dependencies. Instead it takes control of your entire project, tears it to shred, then glues it together with the libraries you wanted. Good luck undoing the chaos it creates.

    Trying to get CocoaPods to install RestKit is a big part of why I threw RestKit out and swapped to MKNetworkKit.

    • eunoiacc

      $ touch Podfile
      $ echo “pod ‘Restkit'” >> Podfile
      $ pod install
      $ open *.xcworkspace

      Is it really that tough?

      I have to ask, did you ever have to deal with managing the dependencies of a large project before cocoa pods? Because if you think cocoapods creates chaos you would be amazed what the average dev can do set loose on Xcode’s build settings screen

      • See my recent comment above. On first use of Cocoapods, it has *never* ever “just worked”.

        If you don’t use it for a few months, then try and use it again, there is a similar level of pain to the last/first time you had to use it.

  • My project uses CocoaPods along with other projects as submodules since they didn’t have any podspecs without any issues. I’m a little confused as to your proposal. Is it only different in that dependencies are simply added into the project instead of into a workspace with a pod project? How then would you tell which dependencies were managed by your tool and which were custom? Things like updating and removing dependencies seem like they would be much more complex.
    I’m also confused about the pollution point. It’s only 4 files/folders that get added into the root directory.

  • After spending far more time dealing with CocoaPods-related build errors and dependencies, the net time saving is negative for me so far.
    CocoaPods is solving a problem I didn’t have and causing me more problems than it is worth.
    I’ll be using static libraries in new projects, and manually updating them on the rare occasions when that is actually needed.
    And I’ll get fast build times back to boot.

  • twizell

    I’ve struggled with CocoaPods for the last couple of years, trying them a couple of times then dumping them when I’ve hit a problem that is complex to resolve, and where I can’t find any help online to resolve it. Its heartening to find someone else who shares my view on CocoaPods, I just feel that 95% of the time they are a time saver, but 5% of the time there is a non-linear complexity that can eat days of productivity fixing exotic problems with builds. I’m going to strip this out of my latest project. I’ve been having a hellish time with a project with a mix of Obj-C and a new dynamic framework I’m trying to create with Cocoapods figuring out what is a CocoaPods ‘feature’ and actual problems with project configuration that I may have introduced, for example CocoPods giving me warnings that I have conflicting base configurations I don’t, this is a bug that has been around now since at least October 2014 – . My initial research suggests that Carthage delivers some of the benefits I need while not the ‘crap all over my workspace’ behaviour of CocoaPods so I’m going to give it a try. I would note that the bulk of my problems seem to have come from using CocoaPods with the iOS framework, so possibly only users of this and related frameworks would hit these problems, but whatever, it’s created a problem for me that a more manual dependency management process never caused.

    • MugunthKumar


  • I am just starting a new project, and I want to add RestKit.

    Their instructions tell me to just add “pod restkit” to the Podfile, as usual, and this is where the fun begins, after I run:

    pod install

    CocoaPods 0.37.2 is available.
    To update use: `sudo gem install cocoapods`

    So, I do as I am told:

    ERROR: Error installing cocoapods:
    cocoapods-trunk requires Ruby version >= 2.0.0.

    So I dutifully try:

    rvm get stable
    rvm install 2.0.0

    Installing requirements for osx.
    Updating system…….
    Error running ‘requirements_osx_brew_update_system ruby-2.0.0-p643’,
    showing last 15 lines of /Users/mike/.rvm/log/1435063057_ruby-2.0.0-p643/update_system.log

    And it just goes on and on, and I start regretting it, I really do.

    • So it’s 2 years later and now of course I have been using CocoaPods all the time, the app made it simpler and reliable, and I stopped fighting it pretty quickly :)

      But, I stand by what I said at the time.

  • Louis Mingüey

    CocoaPods sucks the sweat off the dead man’s balls.

    I went there. I really went there.

    • Kemgadi Nwachukwu

      lol.. totally!!

  • Apple’s native Swift Package Manager will hopefully make CocoaPods and Carthage obsolete (except for Objective-C legacy libraries). We just have to wait for Swift 3…..

  • I feel the most problematic part is that cocoapods attempts to solve the problem by modyfing the IDE settings. None package managers i’ve dealed with does this way. Xcode project file spec is not public and there is no official way of programatically change it. Hence the base of cocoapods is superfragile specially for NON SIMPLE PROJECTS THAT DIDNT HAVE Cocoapods FROM THE START.

    Probably it was the only way but the approach risks is a high price we have to pay once in a while. And IMO it does not worth it

    In my case it is been the cause of several hours of unnecesary debbuging and googling and I am tired

    I want to change to the swift package manager ASAP.

  • Tarrasque

    I hate it too.