The Podfile is a specification that describes the dependencies of the
targets of one or more Xcode projects. The Podfile always creates an
implicit target, named
default, which links to the first target of the
A podfile can be very simple:
pod 'AFNetworking', '~> 1.0'
An example of a more complex podfile can be:
platform :ios, '6.0' inhibit_all_warnings! xcodeproj `MyProject` pod 'ObjectiveSugar', '~> 0.5' target :test do pod 'OCMock', '~> 2.0.1' end post_install do |installer| installer.project.targets.each do |target| puts "#
target.name" end end
The Podfile specifies the dependencies of each user target.
podis the way to declare a specific dependency.
podspecprovides an easy creation API for local podspecs.
targetallows you to scope your dependencies to specific targets in your Xcode projects.
These settings are used to control the CocoaPods generated project.
This starts out simply with stating what
platform you are working
xcodeproj allows you to state specifically which project to
This group list the options to configure workspace and to set global settings.
The Podfile provides hooks that will be called during the installation process.
Hooks are global and not stored per target definition.
Specifies a dependency of the project.
A dependency requirement is defined by the name of the Pod and optionally a list of version requirements.
When starting out with a project it is likely that you will want to use the latest version of a Pod. If this is the case, simply omit the version requirements.
Later on in the project you may want to freeze to a specific version of a Pod, in which case you can specify that version number.
pod 'Objection', '0.9'
Besides no version, or a specific one, it is also possible to use operators:
> 0.1Any version higher than 0.1
>= 0.1Version 0.1 and any higher version
< 0.1Any version lower than 0.1
<= 0.1Version 0.1 and any lower version
~> 0.1.2Version 0.1.2 and the versions up to 0.2, not including 0.2
A list of version requirements can be specified for even more fine grained control.
For more information, regarding versioning policy, see:
Finally, instead of a version, you can specify the
:head flag. This
will use the spec of the newest available version in your spec repo(s),
but force the download of the ‘bleeding edge’ version (HEAD). Use this
with caution, as the spec might not be compatible anymore.
pod 'Objection', :head
Dependencies can be obtained also from external sources.
Using the files from a local path.
If you wold like to use develop a Pod in tandem with its client
project you can use the
pod 'AFNetworking', :path => '~/Documents/AFNetworking'
Using this option CocoaPods will assume the given folder to be the root of the Pod and will link the files directly from there in the Pods project. This means that your edits will persist to CocoaPods installations.
The referenced folder can be a checkout of your your favorite SCM or even a git submodule of the current repo.
Note that the
podspec of the Pod file is expected to be in the
From a podspec in the root of a library repo.
Sometimes you may want to use the bleeding edge version of a Pod. Or a specific revision. If this is the case, you can specify that with your pod declaration.
To use the
master branch of the repo:
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git'
Or specify a commit:
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :commit => '082f8319af'
It is important to note, though, that this means that the version will have to satisfy any other dependencies on the Pod by other Pods.
podspec file is expected to be in the root of the repo, if this
library does not have a
podspec file in its repo yet, you will have
to use one of the approaches outlined in the sections below.
From a podspec outside a spec repo, for a library without podspec.
If a podspec is available from another source outside of the library’s repo. Consider, for instance, a podspec available via HTTP:
pod 'JSONKit', :podspec => 'https://raw.github.com/gist/1346394/1d26570f68ca27377a27430c65841a0880395d72/JSONKit.podspec'
Use the dependencies of a Pod defined in the given podspec file. If no arguments are passed the first podspec in the root of the Podfile is used. It is intended to be used by the project of a library.
podspec :name => 'QuickDialog'
podspec :path => '/Documents/PrettyKit/PrettyKit.podspec'
Defines a new static library target and scopes dependencies defined
from the given block. The target will by default include the
dependencies defined outside of the block, unless the
true option is
The Podfile creates a global target named
:default which produces the
libPods.a file. This target is linked with the first target of user
project if not value is specified for the
Defining a target
target :ZipApp do pod 'SSZipArchive' end
Defining an exclusive target
target :ZipApp do pod 'SSZipArchive' target :test, :exclusive => true do pod 'JSONKit' end end
Specifies the platform for which a static library should be build.
CocoaPods provides a default deployment target if one is not specified.
The current default values are
4.3 for iOS and
10.6 for OS X.
If the deployment target requires it (iOS <
architecture will be added to
Specifying the platform
platform :ios, "4.0" platform :ios
Specifies the Xcode project that contains the target that the Pods library should be linked with.
If no explicit project is specified, it will use the Xcode project of the parent target. If none of the target definitions specify an explicit project and there is only one project in the same directory as the Podfile then that project will be used.
It is possible also to specify whether the build settings of your
custom build configurations should be modeled after the release or
the debug presets. To do so you need to specify a hash where the name
of each build configuration is associated to either
Specifying the user project
# Look for target to link with in an Xcode project called # `MyProject.xcodeproj`. xcodeproj `MyProject` target :test do # This Pods library links with a target in another project. xcodeproj `TestProject` end
Using custom build configurations
xcodeproj `TestProject`, 'Mac App Store' => :release, 'Test' => :debug
Inhibits all the warnings from the CocoaPods libraries.
This attribute is inherited by child target definitions.
If you would like to inhibit warnings per Pod you can use the following syntax:
pod 'SSZipArchive', :inhibit_warnings => true
Specifies the Xcode workspace that should contain all the projects.
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.
Specifying a workspace
Specifies that a BridgeSupport metadata document should be generated from the headers of all installed Pods.
Specifies that the -fobjc-arc flag should be added to the
This is used as a workaround for a compiler bug with non-ARC projects
(see #142). This was originally done automatically but libtool as of
Xcode 4.3.2 no longer seems to support the
-fobjc-arc flag. Therefore
it now has to be enabled explicitly using this method.
Support for this method might be dropped in CocoaPods
This hook allows you to make any changes to the Pods after they have been downloaded but before they are installed.
It receives the
as its only argument.
Defining a pre install hook in a Podfile.
pre_install do |installer_representation| # Do something fancy! end
This hook allows you to make any last changes to the generated Xcode project before it is written to disk, or any other tasks you might want to perform.
It receives the
as its only argument.
Customizing the `OTHER_LDFLAGS` of all targets
post_install do |installer_representation| installer_representation.project.targets.each do |target| target.build_configurations.each do |config| config.build_settings['GCC_ENABLE_OBJC_GC'] = 'supported' end end end