vendorkit/cocoapods

[Stewart Gleadow]

Hi Kieth,

I haven't looked at Vendor in a little while, but I was just ranting on a Thoughtworks mailing list about iOS dependency management. Thought it may be relevant to Vendor folks - let me know if it's incorrect:

"

If it comes to a fight, I'd go for CocoaPods purely because the author, Eloy Duran's twitter profile picture has him holding a massive machete. The one written by a local Aus guy is called VendorKit, and is fairly similar in approach. http://vendorkit.com/. I haven't used either in anger so I can't really comment on which is better. Keith Pitt, who wrote VendorKit is also a Rails dev and wanted something like bundler.

Cocoapods at one stage (maybe still does?) required using MacRuby and mgem, and was a pain to get installed. Eloy was talking about resolving this recently.

The thing I don't really like about either of these approaches is that they concentrate on incorporating source code to be compiled into your project. This is _not_ what you want for Objective C code. In fact, I have so many compiler warnings/errors enabled that most people's code wont compile once I link it in anyway - and with some codebases using ARC and some not, it's a real pain.

The tried and tested way of incorporating multiple dependencies for Objective C is through static libraries (Or dynamic, but they're still not available for iOS). I would like a version of CocoaPods or VendorKit that manages two types of dependencies:

1) a static library with associated public headers. I use a convention of having all static libraries in a single 'lib' directory, with public headers in a directory with the same name as the lib. eg libocmock.a and an OCMock directory next to it. That way, you #import <OCMock/OCMock.h> and you don't have to change any header/library search paths for each new library. The code used in Cocoapods/VendorKit already has the ability to tweak the only settings needed, which would be to link the library by adding '-locmock' to the appropriate targets.

2) an xcode project that builds the static library from 1). This is because you inevitably end up tweaking third party code. As well as linking the library like in 1), it would also need to tweak the workspace to add this project as a target dependency, so that when you tweak the code, it will rebuild the static lib when you build your app.

Or perhaps I haven't looked closely enough at the existing solutions, maybe they do this already? It's been a few months since I've looked.

"

cheers,

Stew

[Jasper Blues]

Hi Stew!

I've addressed some of your concerns with regards to CocoaPods. 

1. ARC 

It's pretty easy to mix ARC and non-ARC modules in a CocoaPods project - CocoaPods uses workspaces to link modules.

Because the Pods are in a separate project, it does not matter wether or not you application uses ARC. Second, the Pods project does not enable ARC by default, but any Pod that specifies that it needs ARC in its podspec will get an extra compile option on its source files: -fobjc-arc. This will compile that specific file only with ARC support.

2. Installing

CocoaPods can now be installed easily: 

[sudo] gem install cocoapods
$ pod setup

3.  Warnings

Because the modules are in a separate project and linked through a workspace they will have different warnings settings. 

4. Linking

If you run pod install in CocoaPods you'll see that the Pods.xcodeproj includes a static library target - with all dependencies in one. Then libPods.a is added to your target in the main project. It also updates the header search path. The idea is that since you're using a dependency manager, it's not really necessary to compile them as separate modules. 

5. Tweaking

If you wanted to make quick tweaks and test them before deciding on a fork vs pull request you can open the Pods.xcodeproj and edit code in there. It will still be linked as a static library. 

I've CC'd Eloy so that he can correct me or add any clarifications. I still haven't played with VendorKit yet, so I couldn't say how it works. One thing I do know is that it avoids the workspaces approach and goes for directly editing a single project. In any case I think it's great to have some competition to drive innovation forwards. Alternatively it would be nice to see some collaboration as between the two projects also. 

Regards, 

Jasper

[Stewart Gleadow]

Thanks Jasper, that's awesome... addresses most of my initial thoughts about CocoaPods.