target 'MyApp' do
pod 'AFNetworking', '~> 3.0'
pod 'FBSDKCoreKit', '~> 4.9'
end
$ pod install
in your project directory.App.xcworkspace
and build.To create a new project with CocoaPods, follow these simple steps:
$ cd
into your project directory.$ pod init
.target '$TARGET_NAME' do
and an end
a few lines after.pod '$PODNAME'
on a single line inside your target block.target 'MyApp' do
pod 'ObjectiveSugar'
end
$ pod install
MyApp.xcworkspace
that was created. This should be the file you use everyday to create your app.Integrating CocoaPods with an existing workspace requires one extra line in your Podfile. Simply specify the .xcworkspace
filename in outside your target blocks like so:
pod install
vs pod update
?
Many people are confused about when to use pod install
and when to use pod update
. Especially, they often use pod update
where they should instead use pod install
.
You can find a detailed explanation about when to use each and what are the intended usage of each command in this dedicated guide.
<Should I check the Pods directory into source control?Whether or not you check in your Pods
folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore
. But ultimately this decision is up to you:
pod install
, and no Internet connection is necessary.pod install
will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.)Whether or not you check in the Pods
directory, the Podfile
and Podfile.lock
should always be kept under version control.
Podfile.lock
?
This file is generated after the first run of pod install
, and tracks the version of each Pod that was installed. For example, imagine the following dependency specified in the Podfile:
Running pod install
will install the current version of RestKit, causing a Podfile.lock
to be generated that indicates the exact version installed (e.g. RestKit 0.10.3
). Thanks to the Podfile.lock
, running pod install
on this hypothetical project at a later point in time on a different machine will still install RestKit 0.10.3 even if a newer version is available. CocoaPods will honour the Pod version in Podfile.lock
unless the dependency is updated in the Podfile or pod update
is called (which will cause a new Podfile.lock
to be generated). In this way CocoaPods avoids headaches caused by unexpected changes to dependencies.
There's a great video from Google about how this works: "CocoaPods and Lockfiles (Route 85)".
<What is happening behind the scenes?In Xcode, with references directly from the ruby source, it:
/bin/sh
${SRCROOT}/Pods/PodsResources.sh
Note that steps 3 onwards are skipped if the CocoaPods static library is already in your project. This is largely based on Jonah Williams' work on Static Libraries.
<Pods and SubmodulesCocoaPods and git submodules attempt to solve very similar problems. Both strive to simplify the process of including 3rd party code in your project. Submodules link to a specific commit of that project, while a CocoaPod is tied to a versioned developer release.
<Switching from submodules to CocoaPodsBefore you decide to make the full switch to CocoaPods, make sure that the libraries you are currently using are all available. It is also a good idea to record the versions of the libraries you are currently using, so that you can setup CocoaPods to use the same ones. It's also a good idea to do this incrementally, going dependency by dependency instead of one big move.
pod install
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4