At its core, CocoaPods is a dependency manager. Because using Xcode has historically been the obvious way to build Objective-C applications, Xcode integration was made an integral part of the code base.

However, now that we have plugin support, and the fact that some prefer to do integration in their own way, and there are even other build tools on the horizon that can replace Xcode, it’s time to bring back CocoaPods to its core: a dependency manager.

This is what I imagine:

• When activating the resolver plugin, CocoaPods will only:
  • Resolve all the requested dependencies and provide a full graph.
  • Print out a manifest of what code to download (source, revision, etc), what build settings to apply (search paths, extra linker options such as frameworks, ARC, etc), and which source files to use. (This would probably be a plugin as well, but it would be implicitly activated if no other plugins are activated.)
• When activating the download plugin in the Podfile, CocoaPods will in addition:
  • Download all the sources into a destination dir (e.g. Pods)
  • Clean all files, except those that are required for any activated dependencies.
• When activating the xcode plugin in the Podfile, CocoaPods will in addition:
  • Create a Pods.xcodeproj
• When activating the xcode-integration plugin in the Podfile, CocoaPods will in addition:
  • Inflect certain required settings from the user's project (e.g. deployment target).
  • Integrate the Pods.xcodeproj into the user's project and generate a workspace.

Without activating any other plugins in the Podfile, the default remains the current default, which is to activate the integration plugin.

(NOTE: each subsequent plugin implicitly activates those above it.)

Besides catering to many more workflows, this will also ensure we have a far more full featured plugin infrastructure for v1. This also relates to #2640.