CarthageとCocoaPodsの違いを経験交えて比較する
Table of Contents
CarthageとCocoaPodsの違いは「手軽」か「柔軟」かです。
CarthageとCocoaPodsそれぞれの特徴
共通点
- CocoaPodsならPodfile、CarthageならCartfileと管理ファイルに書かれたライブラリ情報からframeworkを作成します。
CocoaPods
- 作成したframeworkのリンキングの自動設定
- Xcodeワークスペース(.xcworkspace)を自動作成および更新
- 一元管理されたエコシステムでライブラリの発見率を向上させる
- 単一障害点となる
- メンテナンス必要
- Xcode構造仕様に依存する
- ライブラリ側の依存関係や構築方法を指定したpodspecファイルが必要
- 複雑しかし高機能
- Podsプロジェクトと呼ばれるライブラリ集約プロジェクトからframeworkを作成
ライブラリの管理責任を一手に引き受け「使いやすい」をアプローチ
Carthage
- 作成したframeworkのリンキングは手動設定
- Xcodeワークスペース(.xcworkspace)やプロジェクト(.xcodeproj)に手を加えない
- Carthage対応ライブラリは一元管理されておらずGitHubなどのトレンドページや個人の周知活動に依存する
- 一元管理システムがないのでその分のメンテナンス不要
- 単一障害点を回避できる※
- Xcode構造仕様の影響受けない
- ライブラリ側はXcodeプロジェクトが必要
- 手間しかしシンプル
- 事前にframeworkを作成
余計な影響範囲を最小限に抑え「単純かつ柔軟」をアプローチ
※Carthageのシステム自体は単一障害点はないですが、運用において実質スタンダードになっているGitホスティングサービスがGitHub一強となっていることから、GitHubが単一障害点になっていると思います。
CarthageとCocoaPodsの各ライブラリ管理方法
CocoaPods
CocoaPodsは$ pod installでライブラリをインストールすると、
対象プロジェクトに対してワークスペース(.xcworkspace)を作成をしたり、
プロジェクトに対してオプション更新をしたりと、導入が楽になっているかわりに高機能となっています。
作成されたワークスペースには、対象プロジェクトとは別に
Podsプロジェクト(Pods.xcodeproj)が作成されており、
その中にライブラリとなるソースコードが含まれています。
ビルド実行することでPodsプロジェクト内のソースコードも一緒にビルドされて、
対象プロジェクトにはフレームワークとしてリンクされます。
リンク処理も全てCocoaPodsが自動で行ってくれます。
Carthage
Carthageは最低限のライブラリからフレームワークの作成・更新のみとなります。
ワークスペースを作成したり、フレームワークをプロジェクトにリンクはしません。
プロジェクトへのフレームワーク追加は、自分で行う必要があります。
詳しくは「iOSのCarthage導入手順と注意点 」にまとめてあります。
CarthageとCocoaPodsのメリット・デメリット
Carghageのメリットはビルドが早いだけでなく、安定していることだと思います。
CocoaPodsはとにかく楽です。
環境構築速度
Carthage/CocoaPodsそれぞれの導入コストです。
これはずば抜けてCocoaPodsに軍配が上がります。
pod initでPodfileを作成し、内部にライブラリ名を記入後、pod installするだけで終わりです。
あとは生成されたワークスペースを開くだけでライブラリが使える環境になっています。
ビルド時間の短縮
コンパイルとリンクなどビルド時間です。
Carthageの勝ちです。
CocoaPodsと異なり一度frameworkを作成すれば、
以降はXcodeプロジェクト上でReBuildしても、
framework側でコンパイルが走ることはありません。
速度差を測定してみる
それぞれのビルド時間を測定してみました。
- 測定は最初の5回は慣らし、5回目から数回測定。
- 測定ではRebuild(Clean+Build)で測定する。
- インストールライブラリはSwiftJSON。
| 環境 | min | max | avg |
|---|---|---|---|
| CocoaPods | 3.208s | 3.492s | 3.308s |
| Carthage | 1.478s | 1.765s | 1.60725s |
| vanilla | 0.932s | 1.143s | 1.04967s |
効果としては期待どおりで、ビルド時間短縮を目的とするには、十分効果があると見てよいと思います。
Xcodeの内部仕様の変更
Xcodeはバージョンが上がると、プロジェクトやワークスペースを表すxmlの構造が変わるケースがあります。
そしてCocoaPodsはワークスペースやPodsプロジェクトの生成、リンクなど広範囲のXcodeの内部仕様を利用してます。
そのためXcodeバージョンアップ時に仕様と挙動が噛み合わず動かなくなることもあります。
この場合、CocoaPodsが対応してくれるまで待ったあとにバージョンを上げる必要があります。
その点Carthageはフレームワークを作成するだけなので、Xcodeの内部仕様の影響は受けません。
ライブラリ側はXcodeプロジェクトを必要としますが、これはXcodeアプリから弄るもののため、内部仕様が変わってもXcodeアプリも変わるので影響を受けないです。
そのため開発安定性はCocoaPodsより勝っているとも言えます。
CocoaPodsは毎年Xcodeのメジャーバージョンアップで心配になります。
対応ライブラリ数
これは具体的な数値を確かめる方法がCarthage側にはないのですが、体感としてはCocoaPodsの方が多く感じます。 ライブラリを使いたい時にCocoaPodsしか対応していない場面にいくつか出くわしているためです。
CocoaPodsの昔の話
今よりも酷いバグだらけのXcode
私はiOSとは2012年から関わっております。
その頃のXcodeは非常に不安定でバグも多く同じ操作でも正しく動かないとか普通でした。
Subversion登録ウィザードとか横ページングでステップ表現をしていたが、一度戻ってまた進むと、UIが消えるバグがあったり。
CocoaPodsが不安定で肝を冷やした話
CocoaPodsも再構築が失敗するのでソースコードだけでは復元が不可能なケースが稀にあり、
そのため実務ではリリース毎にPodsファイル含めたワークスペース内全てを圧縮したzipファイルを別途バックアップ管理せざる得ない状況でした。
「そんなことはない。大げさだ」と思う方は運が良かっただけだと思います。
Xcodeのバージョン、Rubyバージョン、CocoaPodsバージョン、クラッシュによる過去アプリプロジェクトの復元など色々な条件が重なって私のところでは発生し肝を冷やしました。
その時は昔からメンバーの一人が昔からMacを触ってる人がいて、その人はリリース毎のバージョンをzipでローカルでbackupしていたので助かったのですが。
Carthageの登場
Carthageがよく目にするようになったのはiOS7あたりだったと思います。
Xcodeのバージョンを上げたらCocoaPodsのpod installが失敗するようになり、開発が止まってしまうことがありました。
そのときにCarthageはフレームワークを事前に用意しておき、Xcodeに追加するだけで動くので、
Xcodeの仕様変更に影響をうけることがなく開発ができることが魅力的でした。
当時、私はビルド時間短縮よりも、Xcodeに引きづられるCocoaPodsの不安定から開放されことが、メリットだと感じていました。（全てのライブラリがCarthage対応してないので開放はされないのですが…w）
昔からXcodeやCocoaPodsを使っている人は、過去の経験からXcodeのバージョンアップやCocoaPodsのバージョンアップには慎重な方が多そうな気がします。
CarthageとCocoaPodsどちらがいいか
現時点ではどちらがいいとはいえないです。 Carthage一択でいきたい人がいたとしても、CocoaPodsでしか対応してないライブラリがあるのが事実です。
またケースによっても変わってくると思います。 何かライブラリの調査をしたい場合に新しく調査用プロジェクトを作る場合とかであれば、CocoaPodsのほうが楽だと思います。
現実解は、共存だと思います。
もっと体系的に理解する
この記事では、記事の読みやすいよう導入に絞ってます。
もしCartfileの書き方や個別更新、チーム運用、git管理など使い続けたら必要になる部分は別記事に分けており、
「Carthageの使い方を体系的に理解する
」からまとめて知ることができます。
