NOTE: As you can see it can take either one target name, or an array of names.

If no explicit Xcode workspace is specified and only one project exists in
the same directory as the Podfile, then the name of that project is used as the
workspace’s name.

If no explicit Xcode project is specified for a target, it will use the Xcode
project of the parent target. If no target specifies an expicit Xcode project
and there is only one project in the same directory as the Podfile then that
project will be used.

If no explicit target is specified, then the Pods target will be linked with
the first target in your project. So if you only have one target you do not
need to specify the target to link with.

Finally, CocoaPods will add build configurations to the Pods project for all
configurations in the other projects in the workspace. By default the
configurations are based on the Release configuration, to base them on the
Debug configuration you will have to explicitely specify them as can be seen
above in the following line:

xcodeproj 'TestProject', 'Test' => :debug

Documentation

CocoaPods will now generate documentation for every library with the
appledoc tool and install it into Xcode’s documentation viewer.

Licenses & Documentation

CocoaPods will now generate two 'Acknowledgements' files for each target specified
in your Podfile which contain the License details for each Pod used in that target
(assuming details have been specified in the Pod spec).

There is a markdown file, for general consumption, as well as a property list file
that can be added to a settings bundle for an iOS application.

You don't need to do anything for this to happen, it should just work.

If you're not happy with the default boilerplate text generated for the title, header
and footnotes in the files, it's possible to customise these by overriding the methods
that generate the text in your Podfile like this:

Added a new Github-specific downloader that can download repositories as a
gzipped tarball.

No more global state is kept during resolving of dependencies.

Updated Xcodeproj to have a friendlier API.

Fixes

#142: Xcode 4.3.2 no longer
supports passing the -fobj-arc flag to the linker and will fail to build. The
addition of this flag was a workaround for a compiler bug in previous versions.
This flag is no longer included by default - to keep using this flag, you need to
add set_arc_compatibility_flag! to your Podfile.

0.5.0

0.4.0

Oops, accidentally skipped this version.

0.3.0

Multiple targets

Add support for multiple static library targets in the Pods Xcode project with
different sets of depedencies. This means that you can create a separate
library which contains all dependencies, including extra ones that you only use
in, for instance, a debug or test build. [docs]

# This Podfile will build three static libraries:# * libPods.a# * libPods-debug.a# * libPods-test.a# This dependency is included in the `default` target, which generates the# `libPods.a` library, and all non-exclusive targets.
dependency 'SSCatalog'
target :debugdo# This dependency is only included in the `debug` target, which generates# the `libPods-debug.a` library.
dependency 'CocoaLumberjack'end
target :test, :exclusive => truedo# This dependency is *only* included in the `test` target, which generates# the `libPods-test.a` library.
dependency 'Kiwi'end

Install libraries from anywhere

A dependency can take a git url if the repo contains a podspec file in its
root, or a podspec can be loaded from a file or HTTP location. If no podspec is
available, a specification can be defined inline in the Podfile. [docs]