CocoaPods/CocoaPods — Issue #125: Proposal that changes some of the fundamental workings of CP
Author: lukeredpath
Created: 2012-02-17 12:46:57+00:00
State: open

I've been thinking lately about whether or not we could transition away from the `Pods` directory and even the need for a workspace.

The basic idea is something like this (I haven't thought this through in a lot of detail yet):

* Pods are compiled into static libraries, one per Pod and are stored on a per-version process in a central location (this could be ~/.cocoapods, or it could be something like `~/Library/Developer/CocoaPods/Libraries`. So you would have, for instance, `POD_ROOT/libPusher/1.1/libPusher.a` and `POD_ROOT/JSONKit/1.0/JSONKit.a`.

* Headers would also be stored alongside these.

* CocoaPods would still generate xcconfig files as before, but it would link to the above libraries directly.

From what I can tell, the advantages are:

* Libraries only have to be compiled once per version and stored in a central location
* Users wouldn't be forced to use a workspace and change their workflow - this has a minimal impact on their project as they just need to add the xcconfig files.
* Pods can be managed distinctly from projects - this essentially makes Pods work like RubyGems and Bundler but separately. RubyGems-style for installing and managing your installed dependencies, Bundler-style for managing your project dependencies.

Disadvantages? Please chime in. None immediately spring to mind.

Other considerations:

* How do we handle dependent pods that are using HEAD instead of a specific version
* Do we create separate device/simulator binaries, a fat binary using lipo or both?

I'm just dumping this here to start some discussion; I'd like to hear what others think.