CocoaPodsの概要と登場前のiOS開発環境
こんにちは、OSSのレキシラジオです。
このポッドキャストは、現役エンジニアであり、最近マリオテニスフィーバーを買ってしまった私、hentekoは、毎週一つのOSSプロジェクトを取り上げて、そのプロジェクトにまつわる歴史やドラマを紹介していく番組です。
最近発売したマリオテニスフィーバー、これめちゃくちゃ面白いんですよね。今ハマってるんですけど、オンラインランキングで言うと全世界でだいたい2000円前後くらいを売ろうとしている感じです。
ただですね、ここからなかなか買ってなくて、もっと練習しないとダメだなぁと思っております。
さて、そんなお話は置いておいて、今週のテーマに行きましょう。
今週がiOSエンジニアなら誰もがお世話になったであろうCocoapodsの歴史についてです。それでは見ていきましょう。
まずはCocoapodsの概要からおさらいしましょう。
Cocoapodsは、iOS開発において外部ライブラリを共有管理するためのツールです。
2011年にリリースされて以来、iOSアプリを開発する際には絶対に利用するツールと一つと言えるほどの自由を確立しました。
実装言語はRubyで書かれていて、podfileという設定ファイルを用意して、terminatepodinstallというコマンドを実行する。
たったこれだけで、様々なiOS向けの外部ライブラリを手軽にプロジェクトへ導入することができました。
現在ではApple公式のSuite Package Managerが普及したことによって利用数は落ち着いてきており、
ついに2026年12月には更新が停止される予定となっています。
今日はそんな一時代を築いたCocoapodsの成り立ちから振り返っていきます。
まずはCocoapodsが開発される前の2010年後のiOS開発環境について見ていきましょう。
当時のiOSアプリ開発環境は正直言ってかなり過酷でした。
外部ライブラリを導入しようと思ったら、まずはライブラリ作者のウェブサイトやGitHubリポジチャリに行って、
ソースコードのZIPファイルをダウンロードするか、Gitのサブモジュールとしてプロジェクトにクローンする必要がありました。
しかもZIPファイルをダウンロードした後も大変です。
開発者はXコード上に手動でファイルをドラッグ&ドロップするなど決まった手順でインポートしなきゃいけない。
これ、手順を一つで間違えると導入すらできないんですよね。
さらにライブラリのバージョン発表があるたびに、また手動で同じ手順を繰り返す必要があって本当に困難な状況でした。
問題をさらにややこしくしていたのが、ビルド設定の複雑さです。
外部ライブラリを利用するためには、コンパイラがヘッダーファイルを見つけられるように手動でパスを設定する必要がありました。
これはiOS開発初心者にとっては高すぎるハードルでした。
こうした導入障壁の高さが原因で、当時のiOS開発者コミュニティではできる限り外部ライブラリへの依存を避けるという文化が定着していました。
その結果、みんなが同じような機能を自分でゼロから作るシャリの再発明が頻発し、非常に非効率な構造を生んでいきました。
この状況を打破したのが、エロイ・デュランさんらが中心となる開発チームによって生み出されたCocoapodsでした。
CocoaPodsの誕生と普及
Cocoapodsの設計思想は、RubyのパッケージマネージャーであるRubyGemsと、依存関係管理ツールであるBundlerから強い影響を受けています。
というか、それらの概念をObjective-Cの世界に移植しようとしたというのが正確な表現です。
というのも、デュランさんたちが元々Rubyコミュニティで活動していて、Rubyのエコシステムがいかに効率的にライブラリを管理・共有しているかを熟知していたからなんですよね。
具体的には、プロジェクトの依存関係を記述するPodファイルは、BundlerでいうGemファイルに相当します。
そして、インストールされたライブラリの正確なバージョンを固定するためのpodfile.loc、これはBundlerのgemfile.locの概念をそのまま利用しています。
このロックファイルの存在によって、チーム開発において全員が同一バージョンのライブラリを利用できることが保証されるようになりました。
ちなみにですね、Cocoapods自体もRubyで実装されているんですけど、Rubyについては過去のエピソード8、Rubyの歴史で詳しく紹介しているので、興味がある方はぜひそちらも聞いてみてください。
こうしてCocoapodsの登場により、ライブラリを公開する際はpodspecというファイルをGitHubなどで公開し、Cocoapodsに登録するだけで良くなりました。
これで検索性と共有が一気に進み、2011年9月にリリースされた最初のバージョン以降、iOS開発者の必須ツールとして不動の地を確立していきました。
Swiftの登場とCocoaPodsの対応
そして順調に成長していたCocoapodsでしたが、2014年、存亡の危機ともいえる事態が訪れます。
AppleによるSwiftの発表です。
それまでのCocoapodsは全てのライブラリを静的ライブラリとしてビルドし、アプリにリンクするという前提で設計されていました。
しかしですね、初期のSwiftでは静的ライブラリとしての配布がサポートされていなかったんです。
ここでCocoapodsチームは驚異的なスピードで対応を見せます。
2015年初頭にリリースされたバージョンで、Cocoapodsは動的フレームワークのサポートを行いました。
Podファイルに対してUseFrameworksという一行を追加する、これだけで依存ライブラリはそれぞれの個別の動的フレームワークとしてビルドされ、アプリのバンドル内にコピーされて実行されるようになりました。
SwiftとObjective-Cが混在するプロジェクトでも、Swiftのモジュールシステムが正しく機能するように設計されており、
この変更は単なる機能追加ではなく、Cocoapods内部のアーキテクチャを基盤から書き直すような大規模な改修でした。
この成功のおかげで、Almofiaなどの現在でも有名なSwift製ライブラリが爆発的に普及することが可能になったわけです。
ちなみに、このSwiftの発表時期に合わせて、新しいパッケージ管理ツールCartagoもリリースされました。
このCartagoはCocoapodsとは対照的で、Xcodeのビルド設定などを勝手に変更する機能はなく、開発者が自分でビルド設定を行う必要がありました。
面倒だなぁと思う反面、Cocoapodsに比べてCartagoの方がビルド時間が短いという大きなメリットもありました。
CocoapodsがXcodeの設定を勝手にいじるブラックボックス感を嫌い、
自分で全てコントロールしたいiOS開発の上級者はCartagoを選ぶことも多くなっていきました。
それでも依然としてCocoapodsのシェアは高いままでした。
CocoaPods 1.0とSwift Package Managerの登場
そして2016年5月、ついにCocoapodsのバージョンが1.0に到達します。
バージョン1.0ではPodファイルの記述がより厳格化され、
それまではターゲットバージョンの指定が曖昧でもツール側がいい感じに推測してくれていたのを明示的な記述を否出としました。
こうすることで複雑なプロジェクトでもエラーが出ないようにしたんですね。
また複数のターゲットで同一のライブラリ群を共有するための仕組みなども導入され、
大規模なアプリ開発における設定の重複を排除できるようになりました。
そんな絶対的な王者として君臨していたCocoapodsにもついに絶対的な敵が現れます。
2015年末、Appleが公式にSwift Package Manager SPMを発表しました。
Swift Package ManagerはApple公式のソフトライブラリ共有管理ツールです。
現在ではXコードに完全統合されていて、
Xコード上で使いたいライブラリのGitHub URLなどを指定するだけでプロジェクトに依存関係を定義することができます。
Cocoapodsなどと違い、中央集権的なサーバーがあるわけではないため、
ツール自体でライブラリの検索はできませんが、ライブラリの公開自体はとても簡単で、
GitHubの公開リポジトリなどにパッケージ.swiftを作成しておいておくだけ。非常に手軽です。
ただですね、初期のSwift Package Managerは機能が限定的で、
画像やストーリーボードを含むリソースファイルが入ったBinary5をサポートしていませんでした。
そのため、現実のiOSアプリ開発においては、まだCocoapodsの優越性が長く続きました。
しかしですね、毎年のアップデートによってSPMの機能は強化されていき、
徐々にCocoapodsとの機能差は埋まっていきます。
CocoaPodsのクロスプラットフォームでの生き残り
特に大きな転換点となったのが、2019年9月にリリースされたXcode11です。
ここでGUIによるSwift Package Managerのサポートが入り、
純粋なSwiftプロジェクトにおいては、SPMを使う流れに大きくシフトしていきました。
ただそんな中、Cocoapodsは意外な形で生き残り続けます。
それがクロスプラットフォーム対応です。
ネイティブ開発では徐々にSPMへ移行していきましたが、
React NativeやFlutterなどのクロスプラットフォームフレームワークでは、
ネイティブモジュールの管理に依然としてCocoapodsに依存していました。
このため、Cocoapodsの利用数は高い水準を保ち続けていたというような形です。
しかし、そんなCocoapodsにもついに終わりの時が来ます。
CocoaPodsの終焉と功績
8月、Cocoapodsの開発チームはプロジェクトの終了に向けたロードマップを発表しました。
公式にメンテナンスモードに入ることが宣言されたのです。
具体的には、セキュリティ対応や最新のXコードへの追従、インフラの維持は行いますが、
新機能の開発はもう行わないということが決定されました。
これに伴って開発者に対しては、新プロジェクトではSwift Package Managerを使うことということが明示的に推奨されました。
さらに、Cocoapodsのライブラリを管理・共有していた中央リポジトリも、
2026年12月に読み取り専用になると発表されました。
これによって、2026年12月以降は、新しいライブラリの公開や既存ライブラリのバージョンアップはCocoapods上では不可能になります。
ちなみに、ライバルだったCartagoに関しては、2年前の2024年に最後のコミットがあって以降、更新がされていないのが現状です。
特に開発終了などのアナウンスもないまま静かに止まっているというような状況です。
しかし、そんなCocoapodsなんですけど、Cocoapodsが残したものは偉大です。
Cocoapodsは、iOS開発においてライブラリの共有という一大地獄から僕たちを救ってくれた救世主であることには変わりはありません。
Appleがなかなか手をつけなかった部分を保管する形でCocoapodsは流行し、そしてその役目を終えようとしています。
さて、いかがだったでしょうか。
Ruby開発コミュニティから生まれたiOS開発の救世主Cocoapods、Safe PackageManagerという公式ツールの登場後も
クラス・プラットフォームフレームワークの基盤となり続け、最終的には2026年年末にその役割を終えます。
しかし、その功績は初期のiOS開発を知る僕たちの記憶にずっと留まり続けるでしょう。
さて、今回のお話は以上となります。
もし少しでも今回のお話がためになったなと思ったらお聞きのプラットフォームでの高評価とフォローの方をお願いします。
また、XなどでハッシュタグOSSの歴史ラジオをつけて感想を呟いてもらえると僕のモチベーションになりますので、ぜひよろしくお願いします。
次回はJavaScriptをバックエンドで使う場合の第一候補となり得るnode.jsの歴史について見ていけたらなと思います。
それではまた次回お会いしましょう。バイバイ。
