Podfile Syntax Reference

Podfile

The Podfile is a specification that describes the dependencies of the targets of one or more Xcode projects.

A Podfile can be very simple:

target 'MyApp'
pod 'AFNetworking', '~> 1.0'

An example of a more complex Podfile can be:

platform :ios, '9.0'
inhibit_all_warnings!

target 'MyApp' do
  pod 'ObjectiveSugar', '~> 0.5'

  target "MyAppTests" do
    inherit! :search_paths
    pod 'OCMock', '~> 2.0.1'
  end
end

post_install do |installer|
  installer.pods_project.pod_targets.each do |target|
    puts "#{target.name}"
  end
end

Root Options

Configuration that applies to the Podfile as a whole.

  • install! declares the installation method and options to be used during installation.

install!

Specifies the installation method to be used when CocoaPods installs this Podfile.

Examples:

Specifying custom CocoaPods installation options
install! 'cocoapods',
         :deterministic_uuids => false,
         :integrate_targets => false

Supported Keys:

:clean

:deduplicate_targets

:deterministic_uuids

:integrate_targets

:lock_pod_sources

:share_schemes_for_development_pods

Dependencies

The Podfile specifies the dependencies of each user target.

  • pod is the way to declare a specific dependency.
  • podspec provides an easy API for the creation of podspecs.
  • target is how you scope your dependencies to specific targets in your Xcode projects.

pod

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.

pod 'SSZipArchive'

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.1 Any version higher than 0.1.
  • >= 0.1 Version 0.1 and any higher version.
  • < 0.1 Any version lower than 0.1.
  • <= 0.1 Version 0.1 and any lower version.
  • ~> 0.1.2 Version 0.1.2 and the versions up to 0.2, not including 0.2. This operator works based on the last component that you specify in your version requirement. The example is equal to >= 0.1.2 combined with < 0.2.0 and will always match the latest known version matching your requirements.

A list of version requirements can be specified for even more fine grained control.

For more information, regarding versioning policy, see:


Build configurations

By default dependencies are installed in all the build configurations of the target. For debug purposes or for other reasons, they can be only enabled on a list of build configurations.

pod 'PonyDebugger', :configurations => ['Debug', 'Beta']

Alternatively, you specify to have it included on a single build configuration.

pod 'PonyDebugger', :configuration => 'Debug'

Note that transitive dependencies are included in all configurations, you have to manually specify build configurations for them as well in case this is not desired.


Subspecs

When installing a Pod via its name, it will install all of the default subspecs defined in the podspec.

You may install a specific subspec using the following:

pod 'QueryKit/Attribute'

You may specify a collection of subspecs to be installed as follows:

pod 'QueryKit', :subspecs => ['Attribute', 'QuerySet']

Dependencies can be obtained also from external sources.

Using the files from a local path.

If you would like to use develop a Pod in tandem with its client project you can use the path option.

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 favourite SCM or even a git submodule of the current repository.

Note that the podspec of the Pod file is expected to be in the folder.

From a podspec in the root of a library repository.

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 repository:

pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git'

To use a different branch of the repository:

pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :branch => 'dev'

To use a tag of the repository:

pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :tag => '0.7.0'

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.

The podspec file is expected to be in the root of the repository, if this library does not have a podspec file in its repository yet, you will have to use one of the approaches outlined in the sections below.

From a podspec outside a spec repository, for a library without podspec.

If a podspec is available from another source outside of the library’s repository. Consider, for instance, a podspec available via HTTP:

pod 'JSONKit', :podspec => 'https://example.com/JSONKit.podspec'

podspec

Use just 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. Note: this does not include the sources derived from the podspec just the CocoaPods infrastructure.

Examples:

podspec
podspec :name => 'QuickDialog'
podspec :path => '/Documents/PrettyKit/PrettyKit.podspec'

target

Defines a CocoaPods target and scopes dependencies defined within the given block. A target should correspond to an Xcode target. By default the target includes the dependencies defined outside of the block, unless instructed not to inherit! them.

Examples:

Defining a target
target 'ZipApp' do
  pod 'SSZipArchive'
end
Defining a test target accessing SSZipArchive pod from its parent
target 'ZipApp' do
  pod 'SSZipArchive'

  target 'ZipAppTests' do
    inherit! :search_paths
    pod 'Nimble'
  end
end
Defining a target applies Pods to multiple targets via its parent target
target 'ShowsApp' do
  pod 'ShowsKit'

  # Has its own copy of ShowsKit + ShowTVAuth
  target 'ShowsTV' do
    pod 'ShowTVAuth'
  end

  # Has its own copy of Specta + Expecta
  # and has access to ShowsKit via the app
  # that the test target is bundled into

  target 'ShowsTests' do
    inherit! :search_paths
    pod 'Specta'
    pod 'Expecta'
  end
end

abstract_target

Defines a new abstract target that can be used for convenient target dependency inheritance.

Examples:

Defining an abstract target
abstract_target 'Networking' do
  pod 'AlamoFire'

  target 'Networking App 1'
  target 'Networking App 2'
end
Defining an abstract_target wrapping Pods to multiple targets
# Note: There are no targets called "Shows" in any of this workspace's Xcode projects
abstract_target 'Shows' do
  pod 'ShowsKit'

  # The target ShowsiOS has its own copy of ShowsKit (inherited) + ShowWebAuth (added here)
  target 'ShowsiOS' do
    pod 'ShowWebAuth'
  end

  # The target ShowsTV has its own copy of ShowsKit (inherited) + ShowTVAuth (added here)
  target 'ShowsTV' do
    pod 'ShowTVAuth'
  end

  # Our tests target has its own copy of
  # our testing frameworks, and has access
  # to ShowsKit as well because it is
  # a child of the abstract target 'Shows'

  target 'ShowsTests' do
    inherit! :search_paths
    pod 'Specta'
    pod 'Expecta'
  end
end

abstract!

Denotes that the current target is abstract, and thus will not directly link against an Xcode target.

inherit!

Sets the inheritance mode for the current target.

Examples:

Inheriting only search paths
target 'App' do
  target 'AppTests' do
    inherit! :search_paths
  end
end

Target configuration

These settings are used to control the CocoaPods generated project.

This starts out simply with stating what platform you are working on. xcodeproj allows you to state specifically which project to link with.

platform

Specifies the platform for which a static library should be built.

CocoaPods provides a default deployment target if one is not specified. The current default values are 4.3 for iOS, 10.6 for OS X, 9.0 for tvOS and 2.0 for watchOS.

If the deployment target requires it (iOS < 4.3), armv6 architecture will be added to ARCHS.

Examples:

Specifying the platform
platform :ios, '4.0'
platform :ios

project

Specifies the Xcode project that contains the target that the Pods library should be linked with.


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 modelled 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 :release or :debug.

Examples:

Specifying the user project
# This Target can be found in a Xcode project called `FastGPS`
target 'MyGPSApp' do
  project 'FastGPS'
  ...
end

# Same Podfile, multiple Xcodeprojects
target 'MyNotesApp' do
  project 'FastNotes'
  ...
end
Using custom build configurations
project 'TestProject', 'Mac App Store' => :release, 'Test' => :debug

xcodeproj

xcodeproj is deprecated in 1.0 and has been renamed to project. For pre-1.0 versions use xcodeproj.

inhibit_all_warnings!

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

Additionally, when you use inhibit_all_warnings! attribute, you can exclude a particular Pod from being inhibited using the following:

pod 'SSZipArchive', :inhibit_warnings => false

use_frameworks!

Use frameworks instead of static libraries for Pods.


This attribute is inherited by child target definitions.

Workspace

This group list the options to configure workspace and to set global settings.

workspace

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.

Examples:

Specifying a workspace
workspace 'MyWorkspace'

generate_bridge_support!

Specifies that a BridgeSupport metadata document should be generated from the headers of all installed Pods.


This is for scripting languages such as MacRuby, Nu, and JSCocoa, which use it to bridge types, functions, etc.

set_arc_compatibility_flag!

Specifies that the -fobjc-arc flag should be added to the OTHER_LD_FLAGS.


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 1.0.

Sources

The Podfile retrieves specs from a given list of sources (repositories).

Sources are global and they are not stored per target definition.

source

Specifies the location of specs


Use this method to specify sources. The order of the sources is relevant. CocoaPods will use the highest version of a Pod of the first source which includes the Pod (regardless whether other sources have a higher version).

The official CocoaPods source is implicit. Once you specify another source, then it will need to be included.

Examples:

Specifying to first use the Artsy repository and then the
CocoaPods Master Repository

source 'https://github.com/artsy/Specs.git'
source 'https://github.com/CocoaPods/Specs.git'

Hooks

The Podfile provides hooks that will be called during the installation process.

Hooks are global and not stored per target definition.

plugin

Specifies the plugins that should be used during installation.


Use this method to specify a plugin that should be used during installation, along with the options that should be passed to the plugin when it is invoked.

Examples:

Specifying to use the `slather` and `cocoapods-keys` plugins.
plugin 'cocoapods-keys', :keyring => 'Eidolon'
plugin 'slather'

pre_install

This hook allows you to make any changes to the Pods after they have been downloaded but before they are installed.

It receives the Pod::Installer as its only argument.

Examples:

Defining a pre-install hook in a Podfile.
pre_install do |installer|
  # Do something fancy!
end

post_install

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 Pod::Installer as its only argument.

Examples:

Customising the build settings of all targets
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['GCC_ENABLE_OBJC_GC'] = 'supported'
    end
  end
end