preface
IOS developers often use Cocoapods to manage third parties, which is simple, convenient, and efficient. How to integrate Cocoapods is explained in detail on The Cocoapods website and in the Podfile syntax instructions. In this article, I want to introduce the Podfile file that is used to integrate Cocoapods.
What is a Podfile
Podfile is a specification that describes one or more dependencies for a set of engineering goals
A simple way to write this is:
target 'MyApp' do
pod 'AFNetworking'.'~ > 3.0'
end
Copy the code
This is the simplest and most common way to write. For MyApp target, AFNetworking is introduced as a dependency library, which is also the most commonly used method.
Here’s a more complicated example:
The following two lines indicate the source address of the dependent library
source 'https://github.com/CocoaPods/Specs.git'
source 'https://github.com/Artsy/Specs.git'
The platform is ios, version 9.0
platform :ios, '9.0'
# Ignore all warnings that come into the library
inhibit_all_warnings!
# AFNetworking for MyApp Target
# introduce OCMock for MyAppTests target
target 'MyApp' do
pod 'AFNetworking'.'~ > 3.0'
target 'MyAppTests' do
inherit! :search_paths
pod 'OCMock'.'~ > 2.0.1'
end
end
# This is how cocoapods will be configured. There are no details on how to configure cocoapods.
post_install do |installer|
installer.pods_project.targets.each do |target|
puts target.name
end
end
Copy the code
The master configuration
install! This command is a setup command declared by Cocoapods to install dependencies that are imported into Podfile. install! This command also has some personal Settings options, such as:
install! 'cocoapods',
:deterministic_uuids => false,
:integrate_targets => false
Copy the code
Other options are also supported:
Supported Keys:
:clean
:deduplicate_targets
:deterministic_uuids
:integrate_targets
:lock_pod_sources
:share_schemes_for_development_pods
Copy the code
As for the above configuration, there is no exact explanation on the official website, so we only need to use the system default.
Dependencies
Podfile specifies the dependencies for each target
pod
Specify a specific dependency librarypodspec
You can provide an API to create Podspecstarget
Specify the dependency scope by target
Pod – Specifies the project’s dependencies
The dependency specification is a combination of the name of the Pod and an optional version. 1> If you do not specify the version number of the dependent library, cocoapods will select the latest version by default.
pod 'SSZipArchive'
Copy the code
2> If you want a specific version of the dependent library, you need to write the specific version number in the format:
pod 'Objection'.'0.9'
Copy the code
3> Version ranges can also be specified
> 0.1
Any version later than 0.1 (excluding 0.1)> = 0.1
Any version later than 0.1, including 0.1< 0.1
Any lower than version 0.1 (excluding version 0.1)< = 0.1
Any version lower than 0.1 inclusive~ > 0.1.2
Version 0.1.2 to 0.2, excluding 0.2. This is based on the last part of the version number you specified. This example is equivalent to >= 0.1.2 and <0.2.0, and is always the latest version in your specified range.
For details on version form specifications, see the link below: Semantic version
Build Configurations
By default, dependencies are installed in build Configuration for all targets. Dependencies can only be enabled in a given Build Configuration for debugging or other reasons. The following notation indicates that configuration is enabled only in Debug and Beta mode
pod 'PonyDebugger', :configurations => ['Debug'.'Beta']
Copy the code
Alternatively, you can whitelist only one build configurations.
pod 'PonyDebugger', :configuration => 'Debug'
Copy the code
Note: by default, if you do not specify the specific build configuration, it will be included in all configurations. If you want to specify it, you must specify it manually.
Subspecs
Normally we’ll use the name of the dependency library to import it, and cocoapods will install all the content of the dependency library by default. We can also specify to install a submodule of a specific dependent library, for example:
Install only the QueryKit Attribute module
pod 'QueryKit/Attribute'
Copy the code
Install only QueryKit Attribute and QuerySet modules
pod 'QueryKit', :subspecs => ['Attribute'.'QuerySet']
Copy the code
Using the files from a local path
We can also specify the source address of the dependent library. If we wanted to import one of our local libraries, we could write:
pod 'AFNetworking', :path => '~/Documents/AFNetworking'
Copy the code
With this option, Cocoapods treats the given folder as the source of the Pod and references these files directly in the project. This means that your edits can be kept in CocoaPods installation, and if you update your AFNetworking code, CocoaPods will update it automatically.
The referenced folder can come from your favorite SCM, or even a Git submodule of your current repository
Note: Pod podSpec files should also be placed in this folder
From a podspec in the root of a library repository
Sometimes we need to introduce branches or nodes specified by the dependent library, written as follows.
- Importing the Master branch (default)
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git'
Copy the code
- Imports the specified branch
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :branch => 'dev'
Copy the code
- The code that introduces a node
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :tag => '0.7.0'
Copy the code
- Introduce a particular commit node
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :commit => '082f8319af'
Copy the code
It is important to note that the PodSpec must exist at the root of the repository, although this will satisfy any dependencies in Pod through other Pods.
Importing PodSpecs from the outside
Podspecs can be imported from the address of another source library
pod 'JSONKit', :podspec => 'https://example.com/JSONKit.podspec'
Copy the code
podspec
Dependencies that use the code base defined in the given PodSpec file. If no arguments are passed, PodSpec uses the root directory in preference, otherwise you must specify it later. (Generally use the default Settings.) For example:
No podSpec is used in the root directory, which is the default podSpec
podspec
If the podSpec name is different from the library name, you can specify it this way
podspec :name => 'QuickDialog'
If podSpec is not in the root directory, you can specify the path by using :path
podspec :path => '/Documents/PrettyKit/PrettyKit.podspec'
Copy the code
target
Define the pod target (the target in the Xcode project) and specify the scope of dependencies within the given block. A target should be associated with the Target of an Xcode project. By default, target contains dependencies defined outside the block, unless you specify that inherit is not used! To inherit (referring to inheritance in nested blocks)
- Define a simple target
ZipApp
The introduction ofSSZipArchive
library
target 'ZipApp' do
pod 'SSZipArchive'
end
Copy the code
- To define a
ZipApp
Target only introducedSSZipArchive
Library,ZipAppTests
The target is introduced intoNimble
It also inheritsZipApp
The inside of the targetSSZipArchive
library
target 'ZipApp' do
pod 'SSZipArchive'
target 'ZipAppTests' do
inherit! :search_paths
pod 'Nimble'
end
end
Copy the code
- A target block contains multiple nested subblocks
target 'ShowsApp' do
# ShowsApp will only introduce ShowsKit
pod 'ShowsKit'
# Introduce ShowsKit and ShowTVAuth
target 'ShowsTV' do
pod 'ShowTVAuth'
end
Specta and Expecta as well as ShowsKit are introduced
target 'ShowsTests' do
inherit! :search_paths
pod 'Specta'
pod 'Expecta'
end
end
Copy the code
Abstract target
Define a new abstract target that can be easily used for target dependency inheritance.
- Simple notation
abstract_target 'Networking' do
pod 'AlamoFire'
target 'Networking App 1'
target 'Networking App 2'
end
Copy the code
- Define an Abstract_target that contains multiple targets
# Note: This is an abstract target, which means that ShowsKit is not introduced in the project
abstract_target 'Shows' do
pod 'ShowsKit'
# ShowsiOS Target will introduce the ShowWebAuth library and the ShowsKit library inherited from Shows
target 'ShowsiOS' do
pod 'ShowWebAuth'
end
# ShowsTV Target will introduce the ShowTVAuth library and the ShowsKit library inherited from Shows
target 'ShowsTV' do
pod 'ShowTVAuth'
end
# ShowsTests target introduces the Specta and Expecta libraries and specifies the inheritance of Shows, so ShowsKit will also be introduced
target 'ShowsTests' do
inherit! :search_paths
pod 'Specta'
pod 'Expecta'
end
end
Copy the code
abstract! And inherit!
- abstract! Indicates that the current target is abstract and therefore does not link directly to the Xcode target.
- inherit! Sets the inheritance mode for the current target. Such as:
target 'App' do
target 'AppTests' do
inherit! :search_paths
end
end
Copy the code
Target Configuration
Cocoapods uses target configuration to control the generation of project. Start by specifying what platform you are using. Links in the project files that allow you to specify which projects.
platform
Platform Specifies the platform on which static libraries should be built. CocoaPods provides a default platform version configuration:
- IOS – > 4.3
- OS X – > 10.6
- TvOS – > 9.0
- WatchOS – > 2.0
If the deployment goal requires iOS < 4.3, the ARMV6 architecture will be added to the ARCHS. Such as:
# specify platform and version
platform :ios, '4.0'
platform :ios
Copy the code
project
If no project is specified, the project specified by target’s parent target is used as the target by default. If no target is specified, project in the same directory as Podefile is used. It is also possible to specify whether these Settings take effect in release or debug mode. To do this, you must specify a name associated with :release/:debuge
Examples: Specifying the user project
# MyGPSApp This target introduces a library that can only be referenced in the FastGPS project
target 'MyGPSApp' do
project 'FastGPS'. endSame principle as above
target 'MyNotesApp' do
project 'FastNotes'. endCopy the code
Use custom build configurations
project 'TestProject'.'Mac App Store' => :release, 'Test' => :debug
Copy the code
inhibit_all_warnings! (Good news for people with OCD)
inhibit_all_warnings! Mask all warnings from cocoapods dependent libraries. You can define it globally, within a sub-target, or specify a library:
# Hide SSZipArchive warnings without hiding ShowTVAuth warnings
pod 'SSZipArchive', :inhibit_warnings => true
pod 'ShowTVAuth', :inhibit_warnings => false
Copy the code
use_frameworks!
By specifying use_frameworks! Require that you generate a framework rather than a static library. If you use use_frameworks! This command will generate Frameworks that depend on libraries in the Frameworks directory of the Pods project if use_frameworks is not used! The command will generate a static library of.a in the Products directory under the Pods project
Workspace
By default, we don’t need to specify it, just use the same project name as the Podfile directory. If you want to specify a different name than the project name, you can specify it as follows:
workspace 'MyWorkspace'
Copy the code
Source
Source is the source of the specified POD. If you do not specify source, CocoaPods official source is used by default. (Default Settings are recommended)
CocoaPods Master Repository
Use another source address
source 'https://github.com/artsy/Specs.git'
# use the official default address (default)
source 'https://github.com/CocoaPods/Specs.git'
Copy the code
Hooks
Podfile provides the hook mechanism, which is invoked during installation. Hooks are global and are not stored in each target.
Plugin
Specifies the plug-ins that should be used during installation. Use this method to specify the plug-in that should be used during installation and the options that should be passed to the plug-in when it is called. Such as:
# Specify the use of cocoapods-keys and Slather plug-ins during installation
plugin 'cocoapods-keys', :keyring => 'Eidolon'
plugin 'slather'
Copy the code
pre_install
When the download is complete but not yet installed, you can use the hook mechanism to specify changes via pre_install and then proceed to the installation phase. The format is as follows:
pre_install do |installer|
Make some pre-installation changes
end
Copy the code
post_install
When our installation is complete, but the generated project has not been written to disk, we can specify the action to be performed. For example, we can modify the configuration of some projects before writing to disk:
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
Copy the code
def
We can also declare a pod set with the def command:
def 'CustomPods'
pod 'IQKeyboardManagerSwift'Then, we can introduce at the target we want to introduce:Copy the code
target ‘MyTarget’ do CustomPods end
The nice thing about this is that if you have multiple targets and not all of them are included, you can separate them in this way.# # to summarizeThis article mainly introduces some elements of Podfile file, is also a learning record of my own process, because my level is limited, inevitably there will be mistakes, but also hope to point out.Copy the code