I’ve written before about how CocoaPods isn’t a dependency manager, but rather that CocoaPods makes a dependency manager.

CocoaPods is a dependency manager only in the sense that Apple is a cell phone manufacturer – it’s just one of their many projects.

It raises the question: if CocoaPods isn’t a dependency manager, what is it? And with an increasing variety of dependency managers for iOS, what will CocoaPods become?

I can’t speak to what CocoaPods is, but I believe that CocoaPods’ lasting impact on the iOS developer community won’t be a tool, but rather an idea: that iOS developers can build their own developer tools and improve their own ecosystem.

It can be hard to remember what iOS development was like before CocoaPods. I remember because it sucked and as soon as a friend introduced me to CocoaPods, I was hooked. Your options were basically downloading zip files from GitHub, or using git submodules (still not convinced about which one is worse). CocoaPods was the first time I had seen someone other than Apple make my job as an iOS developer easier.

CocoaPods was controversial – it still is, depending on who you ask – but the community has largely accepted the idea of non-Apple dependencies. CocoaPods won because it saved untold numbers of hours of tedious work. And now, I think in part because CocoaPods was a success, we have lots of different third-party tools. We’ve got Reveal and Dash, we’ve got Xcode plugins and Quick&Nimble, we’ve got the belief that we can solve our own problems.

CocoaPods’ message is really that while the Cocoa Core Competencies are a necessary foundation, they aren’t sufficient to be a good iOS developer.

I wrote this last year and I still think it’s true. But it’s not complete. I’m more and more convinced that being a good developer has less to do with what you know and more to do with your attitude. Good developers look both ways before crossing one-way streets, good developers don’t easily give up, and good developers look for ways to improve their workflows.