Podfile Syntax Reference

Podfile A Podfile describes the dependencies of one or more Xcode project targets. A Podfile can be very simple: Or more complex: Global Settings Global configuration for the Podfile: Specifies the installation method and options to use when CocoaPods installs this Podfile (i.e., when running or ). The first parameter specifies the installation method to use; subsequent parameters are installation options. The only currently available installation method is , so it must always be the first argument. However, additional methods may be provided in future versions. Example: Specify custom CocoaPods installation options Supported keys: Dependencies The Podfile specifies the dependencies for each target. specifies a project dependency, typically defined by a Pod library name and an optional version. In early stages of a project, if you need the latest version of a Pod, simply omit the version: As the project stabilizes, you may want to lock to a specific version: In addition to the above two cases: - — version 0.1 exactly. - — any version higher than 0.1. - — version 0.1 and higher. - — any version lower than 0.1. - — version 0.1 and lower. - — versions from 0.1.2 (inclusive) up to but not including 0.2, selecting the highest version that satisfies the constraint. Equivalent to and . For more information, see: - - Build Configurations By default, dependencies are installed for all build configurations of a target. Sometimes, for debugging or other purposes, you only want a dependency installed in certain build configurations. Or you can specify it for a single build configuration: Note that dependencies are transitive. Sometimes you may need to manually specify build configurations depending on your situation. Subspecs When installing a Pod by name, the default subspecs specified in its podspec are installed. You can install a specific subspec like this: Or specify multiple subspecs: Dependencies can also be specified from external sources. Dependencies Using a Local Path If you are developing a project and a Pod library simultaneously, you can use the option. With this option, CocoaPods treats the given directory as the root of the Pod and links its files into the Pods project. This way, every edit immediately affects CocoaPods. Note that the directory must contain the Pod's file. Dependencies from a Specific Git Address Sometimes you may need to use the latest version or a specially modified version of a Pod. In that case, you can specify the pod's Git address. Use the branch of the dependency: Use a different branch: Use a specific tag: Use a specific commit: Note that this must also satisfy the dependencies of other Pod libraries. The is generally located in the root of the repository. If the repository does not contain a file, you must use the method below. Fetching from an External Source You can fetch the podspec from an external source, such as via HTTP: podspec If no podspec argument is specified, the first podspec found in the Podfile's root directory is used. Parameters options The path from which to load the podspec. If not provided, the first podspec in the Podfile directory is used. Examples: target Corresponds to an Xcode target and allows scoping of dependencies. By default, a target inherits externally defined dependencies, unless is set to opt out. Parameters name The name of the target. Examples: Define a target Define a test target that accesses SSZipArchive via the parent Apply parent target's Pods to multiple child targets primarily affects the setting in in the project configuration. abstracttarget Defines a new abstract target, which is useful for conveniently sharing dependency inheritance across targets. Parameters name The name of the target. Examples: Define an abstract target Define an abstracttarget containing multiple targets abstract! Indicates that the current target is abstract and therefore will not be directly linked to an Xcode target. inherit! Sets the current target's inheritance mode. Parameters inheritance The inheritance mode to set. Available modes: — the target inherits all behaviors from the parent. — the target does not inherit any behaviors from the parent. — the target inherits only the parent's search paths. Examples: Inherit only search paths Target Configuration These settings control the projects generated by CocoaPods. The the project targets must be described. The file allows you to explicitly specify which project to link. platform Specifies the platform for which the static library should be built. If not specified, the default configuration is used: iOS , OS X , tvOS , watchOS . For iOS < , needs to be added to . Parameters name The platform name: , , , or . target Optional. If not set, the default configuration is used. Examples: Specify a platform project Specifies the Xcode project for a target. If no project is explicitly specified for a target, and there is only one project in the same directory as the Podfile, that project will be used. You can also specify whether settings take effect in release or debug mode using or . Parameters Path The path to link the project. buildconfigurations Key-value pairs. Keys are build configuration names in the Xcode project; values are symbols based on or configurations. Defaults to if not set. Examples: Specify a user project Use custom build configurations xcodeproj was deprecated in version 1.0 and renamed to . linkwith was deprecated in version 1.0. Use and target inheritance instead. inhibitallwarnings! Inhibits all warnings from CocoaPods libraries. This attribute is inherited by child target definitions. To disable warnings for an individual Pod library, use: Additionally, when is used, you can exempt a specific library from warning suppression: useframeworks! Use frameworks instead of static libraries. This attribute is inherited by child target definitions. Workspace Lists options for configuring the workspace and setting global settings. workspace Specifies the Xcode workspace that contains all projects. If no explicit Xcode workspace is specified and there is only one project in the same directory as the Podfile, that project's name is used as the workspace name. Parameters path The path to the workspace. Examples: Specify a workspace generatebridgesupport! Specifies that BridgeSupport metadata documents should be generated from the headers of all installed Pod libraries. This feature is used by scripting languages (such as , , or ) to bridge types and methods. setarccompatibilityflag! Specifies that should be added to . Sources Used to specify sources for Pod libraries. Sources are global and are not defined by individual targets. Sources are order-dependent. CocoaPods uses the highest version of a Pod from the first source that contains it (regardless of whether other sources have a higher version). The official CocoaPods source is implicitly included. Once another source is specified, it will be included as well. Parameters source The source URL. Examples: Use the Artsy library first, then fall back to the CocoaPods Master repository: Hooks The Podfile provides hooks that can be called during the installation process. Hooks are global and are not defined by individual targets. plugin Specifies the plugins that should be used during installation, along with any options that should be passed when they are invoked. Parameters name The name of the plugin. options Optional options to pass to the plugin when the hook is invoked. Examples: Specify the use of the and plugins. preinstall This hook allows modifications to Pods after they are downloaded but before installation. Accepts a as the sole parameter. Examples: Define a pre-install hook in the Podfile postinstall Allows final modifications to the generated Xcode project before it is written to disk, or performs other tasks. Accepts a as the sole parameter. Examples: Customize the build settings of all targets: