Carthage

Open source code is legacy, buggy code. Closed source code is often worse, having had fewer eyes inspecting it. Including it in my projects would be a really bad idea if it wasn’t for that (1) they have spent time thinking about how to solve problems I have and (2) my code is at least as buggy and is going to be legacy code in just a few hours, with few people probably ever reading it again. With these odds, it’s no wonder that 80% of my time as a developer is debugging code.

With this in mind, let’s have a look at Carthage, the new dependancy manager for Cocoa. It takes the open source projects you want to use, and compiles them into a binary framework that you can then include in your project.

Cocoapods, on the other hand, will wrap your project in a workspace where it will provide another project with all the source code for the open source stuff, and the compiled frameworks if you choose to include closed source projects.

While Carthage is a more clean approach, there is one very big drawback: when I am debugging my project, I’ll meet assembly code as soon as I start using the open source projects. As a developer in Apples ecosystem, this is of course nothing new, as you meet assembly code as soon as you hit Apples frameworks.

Is this a problem? Do I really want to debug the projects I’m importing? Aren’t they too complex and don’t I have enough work debugging my own code?

Yes, I think it’s absolutely a problem. I have identified and patched countless bugs in open source projects. Some have resulted in my patch being accepted, some have resulted in me keeping a branch with my fix so I don’t have to deal with that bug again myself until the maintainer of the project will either accept my patch, fix it themselves, or a patched fork will take over in its place.

More often, though, going through the code, following the execution path along, will tell me something about how that project expects its surroundings to be, and in doing so, shows me what I’ve done wrong when I was using it. So this is a great tool for solving my bugs. And lastly, it will show me what opinions it has of how the world should be. If I don’t share those opinions, I can either write changes that enforce my view, or use this to find an alternative that is closer to what I want.

High up on my wish list is for Apple to open source its Cocoa libraries. Then I could have the benefits listed above through my entire project. That is actually the only really good thing about Java projects: whenever I want to, I can follow the execution path all the way through the libraries.

I have learned many good practices and coding skills by reading good code while debugging. I have deep respect for Apples work, and expect there to be much good code that I can learn from. Then again, they are only people as well, and they will have written bugs. I will want to write around them, and by having the code I will save ages learning how to work either with or around that code. And I will probably submit patches - and Apple will probably reject most of them becuase I either misunderstood, wrote errors myself, or am going down a different path than what they would prefer. That’ ok. Please, Apple, set your code free.

But brining it back to Carthage, I really don’t want to close down the open source code into a compiled binary. I want the source all the way until I compile and send it to the device, and even there I want the source to see what’s going on. Only when I ship would I like it to be in binary form. And honestly, that’s only because I want it to be as efficient as possible. I’m sure I could reap big benefits of my source being available in my production code, so that I could have crashes well documented right away, instead of re-symbolicating a binary. But for now at least, compiled and compiler-optimized code outweighs these benefits.

So I’ll stick with CocoaPods, where I can see the open source code the entire while. Those are real, important benefits to me, and I can deal with project wrapping and other odd artefacts they may introduce. CocoaPods is well maintained, and they know very well what they do to my projects today, and work hard to do less to it tomorrow and the day after.

Having said that, I appreciate Carthage being there. I do like there being competition, and I’m sure having an alternative out there will improve the exchange of ideas, making both Carthage and CocoaPods even better than if either of them was alone out there.