What does pod install do?

1. The program pod goes to the source listed at the top of your Podfile. If you don’t provide a source, pod will default to https://github.com/CocoaPods/Specs.
2. Pod traverses the source for .podspecs that match its Dependency list

pod 'Dependency1' 
pod 'Dependency2'
pod 'Dependency3'

and if there are different versions, it chooses the podspec that matches the version, and throws and error if it can’t find it. If no version is specified, it defaults to one. If there are mulitple sources listed, then pod searches the first one for its list of required frameworks, and if any of them could not be found, it checks the next listed source, and so forth until they are all found or there are no more sources left to check at which point the pod install would fail.

3. Once at a podspec, Pod identifies the soure. and goes there.

4. Once at the source, it traverses the source until it finds the project that matches the name.

5. Once at the source it figures out what files to include and bring into your project by checking the source files.

6. Then it checks the dependencies listed.

(Doesn’t require an =)

7. pod then it goes to that project’s Podfile,and repeats steps 1–7 until there are no more dependencies to get.

This is the minimum under-the-hood knowledge needed to work effectively with and be able to create cocoapods.

More details

1. pod also visits the source location to get the pod’s dependencies…

When you have a podfile in your project and you run pod install. The program pod goes to the repos specified in your Podfile from the source variable. Once at those CocoaPod repos, the program pod attempts to find .podspecs (ignoring its Podfile which may or may not exist).

pod reads the .podspecs document, and checks the s.dependency value and attempts to find dependencies listed there. It resolves conflicts, for example, lets say your podfile lists two dependencies: A and B. A has a dependency on C version 1.1.0, and B has a dependency on C version 1.2.0. The program doesn’t simply install dependency C twice. It resolves the conflicting version of dependency C choosing 1.1.0 or 1.2.0 and installs dependency C only once.

Here is an interesting article on pod install.

Here are my notes from that article.

Running Pod Install

1. Read the podfile
2. Versioning and conflicts
3. Loading sources.
4. generating pods.xcodeproj
5. Installing libraries
6. Writing to click
7. Create Podfile.lock
8. Manifest.lock
9. xcproj

A little Pneumonic: Revolt: give world class mixes

Reading the Podfile

Cocoapods makes a list of explicitly and implicitly defined pods by loading podspecs which are remotely stored on, git or locally stored in ~/cocoapods

Versioning and Conflicts

Chooses the versions of frameworks to use while assuming semantic versioning. If two podspecs reference two very different versions of the same dependency then the end user must set an explicit version.

Loading Sources

Each podspec contains references to files with git remote and tag source files which resolve to a commit SHA. Source files are downloaded to the pods directory using the information from Podfile, podspec and caches.

Generating the pods.xcodeproj

Pods.xcodeproj is updated using xcodeproj gem. If the file doesn’t exist, its created with some default settings otherwise from memory.

Install Libraries

When cocoapods adds a library to a project, it addds a .xconfig w/build settings, a private .xcconfig that merges these build settings with the defautl CocoaPods configuration and a prefix.pch and dummy.m which are required for building. After this is done for each target the overall Pods target is created, this adds the same files, with a few more. If any source contains a resource bundle instructions on adding that bundle to your app’s target will be added to Pods-Resources.sh .

Pods-environment.h is created to provide macros to help you know if something came from a pod.

plist and markdown to help confirm end users confirm with libc.m

Writing to Disk

All prior work was using objects in memory. Pods.xcodeproj is written to disk with Podfile.lock and Manifest.lock

Podfile.lock

Keeps track fo all resolved versions of pods that need to be installed helped teams when this is checked in source control.

Manifest.lock

copy of Podfile.lock when you run pod install

note- if you ever get a “The sandbox is not in sync with the podfile.lock its because the manifest.lock != podfile.lock.

??Since the pods directory is not always unders version control, this is a way of making sure that developers update their pods before running as otherwise the app would crash or the build would fail in another less visible way.

XcProj

if you have a xcproj on your system it will convert Pods.xcodeproj into old ASCII plist format. because the writing of those files is no longer supported and hasn’t been for a while, yet Xcode still relies on it without xcproj your Pods.xcodeproj is written as an XMC plist and when you open it in Xcode it will be rewritten causing large file diffs.