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.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 and options to be used when CocoaPods installs this Podfile.
The first parameter indicates the installation method to use; next parameters indicate installation options.
For now the only accepted installation method is 'cocoapods'
, so
you'll always use this value for the first parameter; but more
installation methods might be available in future versions.
Examples:
Specifying custom CocoaPods installation options
install! 'cocoapods',
:deterministic_uuids => false,
:integrate_targets => false
Supported Keys:
:clean
Whether to clean the sources of the pods during installation
Cleaning removes any files not used by the pod as specified by the podspec and the platforms that the project supports
this option defaults to true.
:deduplicate_targets
Whether to deduplicate pod targets
Target deduplication adds suffixes to pod targets for the cases where a pod is included in multiple targets that have different requirements. For example, a pod named 'MyPod' with a subspec 'SubA' that is included in two targets as follows:
target 'MyTargetA' do
pod 'MyPod/SubA'
end
target 'MyTargetB' do
pod 'MyPod'
end
will result in two Pod targets: MyPod
and MyPod-SubA
this option defaults to true.
:deterministic_uuids
Whether to generate deterministic UUIDs when creating the Pods project
this option defaults to true.
:integrate_targets
Whether to integrate the installed pods into the user project
If set to false, Pods will be downloaded and installed to the Pods/
directory
but they will not be integrated into your project.
this option defaults to true.
:lock_pod_sources
Whether to lock the source files of pods. Xcode will prompt to unlock the files when attempting to modify their contents
There is a performance penalty to locking the pods during installation. If this is significantly
impacting the duration of pod install
for your project, you can try setting this to false
this option defaults to true.
:warn_for_multiple_pod_sources
Whether to emit a warning when multiple sources contain a Pod with the same name and version
this option defaults to true.
:warn_for_unused_master_specs_repo
Whether to emit a warning if a project is not explicitly specifying the git based master specs repo and can instead use CDN which is the default.
this option defaults to true.
:share_schemes_for_development_pods
Whether to share Xcode schemes for development pods.
Schemes for development pods are created automatically but are not shared by default.
this option defaults to false.
:disable_input_output_paths
Whether to disable the input & output paths of the CocoaPods script phases (Copy Frameworks & Copy Resources)
this option defaults to false.
:preserve_pod_file_structure
Whether to preserve the file structure of all Pods, including externally sourced pods.
By default, the file structure of Pod sources is preserved only for development pods. Setting
:preserve_pod_file_structure
to true
will always preserve the file structure.
this option defaults to false.
:generate_multiple_pod_projects
Whether to generate a project per pod target. Instead of creating 1 Pods.xcodeproj
, this option will generate
a project for every pod target that will be nested under the Pods.xcodeproj
.
this option defaults to false.
:incremental_installation
Whether to enable only regenerating targets and their associate projects that have changed since the previous installation.
this option defaults to false.
:skip_pods_project_generation
Whether to skip generating the Pods.xcodeproj
and perform only dependency resolution and downloading.
this option defaults to false.
:parallel_pod_downloads
Whether to download pods in parallel before beginning the installation process
this option defaults to false.
:parallel_pod_download_thread_pool_size
The size of the thread pool to use when downloading pods in parallel. Only takes effect when
parallel_pod_downloads
is true
.
Default: 40
this option defaults to 40.
ensure_bundler!
Raises a warning when CocoaPods is run using the Global Gemset. A Semantic version can be supplied to warn if the bundler version does not match the required version.
Parameters
versionString
The required bundler version, in semantic version format.
Examples:
ensure_bundler!
ensure_bundler! '~> 2.0.0'
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
Version 0.1.> 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.~> 0
Version 0 and the versions up to 1, not including 1.~> 0.1.3-beta.0
Beta and release versions for 0.1.3, release versions up to 0.2 excluding 0.2. Components separated by a dash (-) will not be considered for the version requirement.
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 can specify to have it included on a single build configuration.
pod 'PonyDebugger', :configuration => 'Debug'
Note that transitive dependencies are included in all configurations and you have to manually specify build configurations for them as well in case this is not desired.
Modular Headers
If you would like to use modular headers per Pod you can use the following syntax:
pod 'SSZipArchive', :modular_headers => true
Additionally, when you use the use_modular_headers!
attribute,
you can exclude a particular Pod from modular headers using the following:
pod 'SSZipArchive', :modular_headers => false
Source
By default the sources specified at the global level are searched in the order they are specified for a dependency match. This behaviour can be altered for a specific dependency by specifying the source with the dependency:
pod 'PonyDebugger', :source => 'https://cdn.cocoapods.org/'
In this case only the specified source will be searched for the dependency and any global sources ignored.
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']
Test Specs
Test specs can be optionally included via the :testspecs
option. By default,
none of a Pod's test specs are included.
You may specify a list of test spec names to install using the following:
pod 'AFNetworking', :testspecs => ['UnitTests', 'SomeOtherTests']
The values provided to :testspecs
correspond to the name provided to the
test_spec
DSL attribute in a Podspec.
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.
Parameters
optionsHash {Symbol=>String}
The path where to load the {Specification}. If not provided the first podspec in the directory of the Podfile is used.
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.
Parameters
nameSymbol, String
The name of the target.
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
script_phase
Adds a script phase to be integrated with this target. A script phase can be used to execute an arbitrary script that can use all Xcode environment variables during execution. A target may include multiple script phases which they will be added in the order they were declared. Deleting a script phase will effectively remove it from the target if it has been added previously.
Parameters
optionsHash
The options for this script phase.
Examples:
script_phase :name => 'HelloWorldScript', :script => 'echo "Hello World"'
script_phase :name => 'HelloWorldScript', :script => 'puts "Hello World"', :shell_path => '/usr/bin/ruby'
abstract_target
Defines a new abstract target that can be used for convenient target dependency inheritance.
Parameters
nameSymbol, String
The name of the target.
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.
Parameters
inheritanceSymbol
The inheritance mode to set.
Available Modes:
+ :complete
The target inherits all
behaviour from the parent.
+ :none
The target inherits none of
the behaviour from the parent.
+ :search_paths
The target inherits
the search paths of the parent only.
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,
1.0
for visionOS and 2.0
for watchOS.
If the deployment target requires it (iOS < 4.3
), armv6
architecture will be added to ARCHS
.
Parameters
nameSymbol
The name of platform, can be either :osx
for OS X, :ios
for iOS, :tvos
for tvOS, :visionos
for visionOS, or :watchos
for watchOS.
targetString, Version
The optional deployment. If not provided a default value according to the platform name will be assigned.
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
.
Parameters
pathString
The path of the project to link with
build_configurationsHash{String => symbol}
A hash where the keys are the name of the build
configurations in your Xcode project and the values are
Symbols that specify if the configuration should be based on
the :debug
or :release
configuration. If no explicit
mapping is specified for a configuration in your project, it
will default to :release
.
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
.
link_with
link_with
is deprecated in 1.0 in
favour of abstract_target
and target inheritance instead.
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_modular_headers!
Use modular headers for all CocoaPods static libraries.
This attribute is inherited by child target definitions.
If you would like to use modular headers per Pod you can use the following syntax:
pod 'SSZipArchive', :modular_headers => true
Additionally, when you use the use_modular_headers!
attribute,
you can exclude a particular Pod from modular headers using the following:
pod 'SSZipArchive', :modular_headers => false
use_frameworks!
Use frameworks instead of static libraries for Pods. When using frameworks, you may also specify the :linkage
style to use, either :static
or :dynamic
.
This attribute is inherited by child target definitions.
Parameters
optionBoolean, Hash
The option to use for configuring packaging and linkage style.
Examples:
target 'MyApp' do
use_frameworks!
pod 'AFNetworking', '~> 1.0'
end
target 'MyApp' do
use_frameworks! :linkage => :dynamic
pod 'AFNetworking', '~> 1.0'
end
target 'ZipApp' do
use_frameworks! :linkage => :static
pod 'SSZipArchive'
end
supports_swift_versions
Specifies the Swift version requirements this target definition supports.
Note These requirements are inherited from the parent, if specified and if none are specified at the root level then all versions are considered to be supported.
Parameters
requirementsString, Version, Array, Array
The set of requirements this target supports.
Examples:
target 'MyApp' do
supports_swift_versions '>= 3.0', '< 4.0'
pod 'AFNetworking', '~> 1.0'
end
supports_swift_versions '>= 3.0', '< 4.0'
target 'MyApp' do
pod 'AFNetworking', '~> 1.0'
end
target 'ZipApp' do
pod 'SSZipArchive'
end
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.
Parameters
pathString
Path of the workspace.
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.
Parameters
sourceString
The URL of a specs repository.
Examples:
Specifying to first use the Artsy repository and then the CocoaPods Master Repository
source 'https://github.com/artsy/Specs.git'
source 'https://cdn.cocoapods.org/'
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.
Parameters
nameString
The name of the plugin.
optionsHash
The optional options that should be passed to the plugin when its hooks are 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
pre_integrate
This hook allows you to make changes before the project is written to disk.
It receives the [Pod::Installer] as its only argument.
Examples:
Customizing the dependencies before integration
pre_integrate do |installer|
# perform some changes on dependencies
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:
Customizing 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
post_integrate
This hook allows you to make changes after the project is written to disk.
It receives the [Pod::Installer] as its only argument.
Examples:
Customizing the build settings of all targets
post_integrate do |installer|
# some change after project write to disk
end