pod installを実行すると、RestKitの現在のバージョンがインストールされ、インストールされた正確なバージョンを示すPodfile.lockが生成されます（例：RestKit 0.10.3など）。 Podfile.lockのおかげで、別のマシンで後の時点でこの仮想プロジェクトでpod installを実行すると、新しいバージョンが利用可能であっても、RestKit 0.10.3がインストールされます。 CocoaPodsは、依存関係がPodfileで更新されるか、pod updateが呼び出されない限り、Podfile.lockのPodバージョンを尊重します（これにより、新しいPodfile.lockが生成されます）。 この方法で CocoaPods は、依存関係に対する予期しない変更によって引き起こされる頭痛の種を回避します。
Google から、これがどのように機能するかについての素晴らしいビデオがあります。 「CocoaPods and Lockfiles (Route 85)」です。
<舞台裏で何が起こっているのか。
Xcode では、ruby ソースからの直接参照により、次のことが行われます：
- ワークスペースを作成または更新します。
- 必要に応じてプロジェクトをワークスペースに追加します。
- 必要に応じて CocoaPods スタティック ライブラリ プロジェクトをワークスペースに追加します。a to: targets => build phases => link with libraries.
- Adds the CocoaPods Xcode configuration file to your app’s project.
- Changes your app’s target configurations to be based on CocoaPods.aを次のように設定します：CocoaPods.
- インストールした任意の Pod からアプリ バンドルにリソースをコピーするビルド フェーズを追加します。つまり、他のすべてのビルド フェーズの後に、次のように ‘Script build phase’ を追加します。
/bin/sh - Script:
${SRCROOT}/Pods/PodsResources.sh
なお、CocoaPods スタティック ライブラリがすでにプロジェクトにある場合、ステップ 3 以降はスキップされます。
<Pods and Submodules
CocoaPods と git submodules は非常によく似た問題を解決しようとしています。 どちらも、サードパーティのコードをプロジェクトに含めるプロセスを簡略化するために努力しています。 サブモジュールはそのプロジェクトの特定のコミットにリンクしますが、CocoaPod はバージョン管理された開発者リリースに結びつきます。
<Switching from submodules to CocoaPods
CocoaPods に完全に切り替えることを決める前に、現在使っているライブラリがすべて利用可能であることを確認します。 また、現在使用しているライブラリのバージョンを記録しておくと、同じものを使用するように CocoaPods を設定することができます。 また、これを一度に大きく動かすのではなく、依存関係ごとに少しずつ行うのも良いアイデアです
。