✍️

なんとなく使ってしまっているCocoaPodsを今更ながら公式の使い方を読んで理解を改めてみた

2022/06/13に公開

iOS

ドキュメント読まなくてもググってブログ記事読んでしまえばCocoaPodsは使えてしまうため、pod installで実際なにが行われているのかあまり把握していませんでした。公式の使い方のページを一度目を通したところ色々と繋がって理解が進んだので、せっかくだからと順を追って大事なところをそこそこに訳しつつ整理しました。とりあえず読んだ上で簡単にまとめておきます。

まとめ

CocoaPodsによるライブラリの一般的な導入の仕方について記載されている
Podfile.lockはライブラリのバージョン情報を記載しており、git管理には含めるべきとされている
ただしライブラリそのものをgit管理に含めるかはメリット、デメリットあり、その選択は究極的には開発者による
CocoaPodsは実行の裏側でworkspaceのパッケージを作り、プロジェクトの情報、ライブラリの利用に必要な情報を加えている

以下、簡単に意訳しつつ読んでいきます。

Before you begin

ここは使うにはCocoaPodsが必要なので、リポジトリや公式サイトで確認した上でインストールしておいてねということが書かれています。

Adding Pods to an Xcode project

Installation

ここは使い方の要約のようなものなので簡単に流してもよさそう。

Podfileを作り、dependencyを与える

ここでのdependencyは条件くらいの意味で理解しておくといいのかも。

target 'MyApp' do
pod 'AFNetworking', '~> 3.0'
pod 'FBSDKCoreKit', '~> 4.9'
end

プロジェクトのディレクトリで $ pod install を実行する

作られたApp.xcworkspaceを開いてビルドする

Creating a new Xcode project with CocoaPods

まずはPodsの導入の仕方です。ちなみにCocoaPodsという名称自体はライブラリ管理ツール、パッケージマネージャとしての名称であって、プロジェクトで利用する対象としている静的ライブラリ群をPods、個別にはPodと称するのだと思います。ただし、pod installのように、個別のpodを抽象的にライブラリ一般として扱うように感じられる文脈もあるので、そのあたりこうだと明確な理解はできていません。

1.　いつも通りXcodeで新しいプロジェクトを作ります。
2.　ターミナルを開いて、$cdコマンドでプロジェクトのディレクトリに移動しましょう。
3.　$pod initでPodfileを作りましょう。
4.　Podfileを開いて、はじめの行にプラットフォームとバージョンを記載しましょう。

platform :ios, '9.0'

ここでいうプラットフォームとはこの'ios'のことです。プラットフォームはひとつではなくて、androidなどもあります。それら複数のプラットフォームに跨って開発が可能であるFlutterなどはクロスプラットフォームと呼ばれます。Cocoapodsもios専用というわけではないので、こうした指定が必要であるということだと考えます。またiOSのバージョンに合わせて、各種ライブラリが利用できるバージョンも制限されるため、指定が必要なのではないかと思います。対応されているかは、Githubなどのリリースノートなどを確認していくのが良さそうです。

CocoaPodsを実際に利用するには、XcodeのTargetにリンク、結びつけてあげる必要があります。>Targetは通常そのプロジェクトの名前です。doとendに挟まれたtarget sectionを作り、その間に>CocoaPodを加えます。

1行の間に`pod '$PODNAME'という形でCocoaPodを加えます。

target 'MyApp' do
pod 'ObjectiveSugar'
end

自分はなんとなく使ってきてしまったのですぐにピンとこなかったのですが、ここでCocoaPodが差しているのは外部ライブラリと読んでも差し支えないだろうし、だから名称としてはPodと同一と言ってもいいと思います。CocoaPods（Pods）はCocoaPod（Pod）という形をとった外部ライブラリの集まりだということですね。

7.　Podfileを保存しましょう。
8.　$ pod installで実行しましょう。
9.　作られた.xcworkspaceを開きましょう。これは毎日使うフォルダになるはずです。

Integration with an existing workspace

すでにあるworkspaceファイルにCocoapodsを入れて統合したい場合にはどうするか。その場合はファイルを.xcworkspaceファイルとして特定できるように、Podfileのtarget blocks外に一行加える必要がある。

workspace 'MyWorkspace'

正直、この辺りの理解ができていないです。

When to use pod install vs pod update?

多くの人がpod installとpod updateをいつ使うべきなのかで混乱しているらしい。らしいというのも、自分は混乱するほど使えた試しがないからだが...

でも、それは別記事での紹介となっているため、今回は省略。
ただ、実際に直面する問題としてはこちらの記事の内容ではありそう。

Should I check the Pods directory into source control?

プロジェクト全般のソースを管理をする上で、Podsのディレクトリをチェックするべきかどうかという問題です。チェックというのは、Gitなどで管理に含める対象とするかどうかくらいに考えても問題ないと思います。要するに.gitignoreに含めるかどうかです。ただ結論としてははっきりとあなた次第だと書かれていて、これは管理することでメリットとデメリットがあるからですね。

Benefits of checking in the Pods directory（管理に含めるメリット）

・必要なリポジトリのファイルが含まれているので、プロジェクトを直接起動できます。これはCocoaPodsがインストールされていなくても行える、つまりpods installを改めてする必要がないので、ネット環境も不要です。
・Githubのようなところにあるソースがダメになったとしても、ライブラリやコードが直接プロジェクトにある以上、利用することができます。

The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.

この部分だけどう理解すればいいかがわからなかった。

Benefits of ignoring the Pods directory　（管理に含めないメリット）

・ライブラリ等が含まれないのでリポジトリが小さく、スペースを取らない
・Github等でのソースが利用できる限り、一般的にはほぼ同一のインストールが行える（ただし、技術的にはその保証があるわけではなく、特にPodfileにzipファイルが利用されている場合は当てはまる）
・異なるPodsのバージョンを利用している際にマージなどのソース管理をする場合でも、コンフリクトが起こらない（だろう）

Podsディレクトリを管理に含める含めないのいずれにしても、PodfileとPodfile.lockは管理に含めるべきと書かれています。

What is Podfile.lock?

実は、いままでPodfile.lockがなんのためにあるのかよくわかっていませんでした。

これはpod installを行うと真っ先に作られるファイルだそうです。なにをしているかといえば、インストールされているPods、つまりライブラリ群のバージョンを記録しています。逆に存在していれば、pod install時には記載されているバージョンに沿ってPodsがインストールされるわけで、インストール時に作る必要がありません。Podfile.lockが存在していないということは、はじめてPodsがインストールされるわけで、その時点でのバージョンを管理しておく必要があるからインストール時に作られる、ということですね。

What is happening behind the scenes?

CocoaPodsが実行の裏側でなにをしているか。

1.　workspaceファイルを生成する、もしくは更新している
2.　必要があれば、プロジェクトをそのworkspaceに加えている
3.　必要があればCocoaPodsの静的ライブラリをそのworkspaceに加えている
4.　libPods.aというファイルを次のディレクトリに加えている。

targets => build phases => link with libraries.

プロジェクトにCocoaPods　Xcode　configurationsを加えている

アプリのターゲット設定をCocoaPodsベースに変更している

インストールしたPodsからアプリバンドルへと、リソースをコピーするビルドフェイズを加えている。例えば、次のようなビルドフェイズの後にある「スクリプトビルドフェイズ」が該当する。

Shell：/ bin / sh
Script：$ {SRCROOT} /Pods/PodsResources.sh

**ちなみに、3番目はすでに静的ライブラリが導入されているのであればスキップされます。

ここでの要点は、元々のプロジェクトを利用するためのファイルや設定を、CocoaPodsを通して新しく作ったworkspaceでも開けるように、移していくということだと思います。最後のフェイズに関しては難しく見えてしまいますが、おそらく変わりありません。

静的ライブラリに関しては下記参照のこと（理解できなさそうでまだ未読）

Pods and Submodules

CocoaPodsもgit管理のサブモジュールも、どちらも目的は似ていてサードパーティのライブラリを利用しやすくするということです。サブモジュールの場合はプロジェクトの特定のコミットに結びついていて、CocoaPodの場合はバージョン管理されたリリースのプロダクトに結びついている。

正直この辺りの言わんとしていることをよくわかっていません。たぶんgit管理されたサブモジュールというのは直接プロジェクト内にライブラリ群を加えた状態を指すのだと思います。そのように理解すると次の説明も飲み込めます。

Switching from submodules to CocoaPods

サブモジュールからCocoaPodsに移行する場合の注意として、まずサブモジュールで利用されているバージョンが現在も利用可能であるかを確認しておきましょう。記録しておくのも良い考えです。移行する際は、一息に大きく動かすのではなく、インクリメント、徐々に行っていくのが良いです。

まだ導入されていなければCocoaPodsを導入しましょう。

次いで、Podfileを作ります。

サブモジュールの参照を取り除きます。

今度はPodfile内にある、その除かれた同じライブラリに参照を与えます。

最後に$pod installを実行しましょう。

自分の見ている範囲だと、初心者でもわりと早い段階でCocoaPodsを利用することが多いのではないかと思います。（というよりサブモジュールとしての利用の仕方がよくわかっていません）