ハクソク

世界を動かす技術を、日本語で。

CocoaPods トランクの読み取り専用プラン

2025年9月1日原文(blog.cocoapods.org)

概要

  • CocoaPods trunkは 2年後に読み取り専用 へ移行予定
  • 以降は 新規Podやバージョン追加不可
  • 既存ビルドは 影響なし、セキュリティ強化が目的
  • prepare_command 利用Podspecの新規追加は 2025年5月で終了
  • 詳細な スケジュールと問い合わせ先 も公開

CocoaPods trunkの読み取り専用化計画

  • CocoaPods trunk を 2年後 に 読み取り専用 へ移行予定
  • 移行後は 新規Podやバージョンの追加不可
  • Specsリポジトリ や CDN は、 GitHub と jsDelivr が存続する限り運用継続
  • 既存のビルドやプロジェクトには 影響なし
  • 新規Podspecの提出は サーバーレベルで拒否 される仕様
  • CocoaPods/Specsリポジトリ は GitHub上でアーカイブ状態 に変更
  • 依存関係のアップデートは trunk経由では今後不可
  • 独自Specsリポジトリ や vendored依存 を使うユーザーには影響なし
    • 例：npm由来の依存管理

セキュリティ強化とprepare_command制限

  • セキュリティ研究者による悪用増加 により、 prepare_command 利用Podspecの新規追加を 2025年5月で停止
  • 既存の prepare_command使用Pod は 例外的に許可 してバイパス
  • セキュリティ上の簡素化が主な目的

スケジュールと通知方法

  • 2025年5月: prepare_command利用Podspecの新規追加を停止
  • 2025年中～後半: すべてのPodspec貢献者へ メール通知、本記事へのリンクを案内
  • 2026年9～10月: 再度、全Podspec貢献者へ メール通知、1か月前に テスト運用 予告
  • 2026年11月1～7日: 読み取り専用化のテスト運用 を実施、問題発生の早期発見を狙う
  • 2026年12月2日: trunkを完全に読み取り専用化、新規Podspecの受付を永久停止
    • アメリカのサンクスギビング後の水曜日を選定、対応の余裕を確保

注意事項・問い合わせ先

  • スケジュールは 変更の可能性あり、前倒しは不可だが後ろ倒しは相談可能
  • 質問や要望は [email protected] （チーム宛）、 [email protected] （個人宛）、または Bluesky: @orta.io まで

Hackerたちの意見

こんなに大きな歴史的な出来事で、Appleプラットフォームの依存関係管理の事実上のスタンダードになってるんだね。メンテナンスしてくれてる皆さん、本当にありがとう！エコシステムが変わる瞬間を認識して、ライブラリを永遠に維持するんじゃなくて、勇気を持って非推奨にするっていうのは、素晴らしいことだと思う。新しい、より優れたソリューションに移行するためのスペースを残してくれてるんだね。

└

優れた解決策。優れたとは、実際により良い状態を含む。違いはただの違いかもしれない。もしかしたら、ただの同質的かも。

これって古いニュースじゃない？新しいものに関してはSwift Package Managerのことを考えてるんだけど。

└

自分の経験から言うと、パッケージの20〜30%はswiftpmと動かないんだよね。Package.swiftファイルがないか、最新の開発ツールと互換性がないから。多くのプロジェクトで、swiftpmの統合を追加したり修正するためにいくつかのリポジトリをフォークしなきゃいけなかった…でも、彼らのPod統合はずっとうまくいってた。

これ、ほんと悲しいよね。代わりのSwift Package Managerがマジでクソだから。役に立つ機能が欠けてるし（「古い」コマンドとか、意味のあるコマンドライン出力とか）、Xcodeではバグだらけ。依存関係を追加・削除すると大体Xcodeがクラッシュするし、リポジトリを取得する時のエラーメッセージも理解できないし、見えないことも多い。多くのリポジトリには古いPackage.swiftがあって、現在の開発ツールじゃ読めないし…。最悪なのは、全ての依存関係の完全なリポジトリをマシンに保存して、CIをちゃんとやるたびに毎回ダウンロードすること。これって、しばしばGB単位のデータになるよ。

└

Tuist

└

わからないな、そんな問題に遭遇したことないし、俺のコードベースは60万行以上あるけど。CocoaPodsや古いフレームワークでのエラーはたくさんあったけど、そのプロジェクトはだいたいMediumで注目されるサードパーティのライブラリをほとんど使ってるからね。ローカルのSwiftパッケージでXcodeプロジェクトをモジュール化するのが、俺の経験では最高の生産性向上だったよ。CocoaPodsで似たようなことをやるのは頭が痛いけど。

└

うん、SwiftPMでは何度も痛い目にあったよ。コンパイラフラグに関する制限も問題だしね。

└

SwiftPMはちょっとトラブルがあったけど、最も複雑なプロジェクトではいくつかの外部パッケージとローカルのものを使ってた。クラッシュとかは全然なかったよ。数年前に切り替えた時のCocoaPodsより、ずっと楽だった。CocoaPodsは自分を壊すのが得意で、依存関係をビルド状態でチェックインして、絶対に必要な時以外はアップグレードを避けてた。アップデートやプロジェクトの解決をするたびに、必ず何かのエッジケースに引っかかって爆発することが多かったからね。SwiftPMに関しては、ほとんどの依存関係を最新に保てるから、全然苦痛じゃない。実際、SwiftPMがあまりにも良いから、Android側でひどいグチャグチャのGradleをSwiftPM（または1:1のJVM対応）に置き換えられたらいいのにって思ってる。Gradleの柔軟性や余計な機能はほとんど必要ないから、SwiftPMのシンプルさがあれば、かなりのQOL向上になるよ。

└

いや、CocoaPodsはSPMに比べて悪夢だったよ。iOSのアップデートごとに、どれかのポッドで新しい未解決の問題が出てきて、暗い呪文が必要だった。ローカルポッドの管理は問題を引き起こして、エンジニアが辞めちゃうほどだった。

└

SPMに対する一番の不満は、パッケージキャッシュが中央集権的で、ディレクトリやプロジェクト、ワークスペースレベルで使えないから、git worktreeと一緒に使う方法がないように見えることだね。

React NativeはiOSに対してこれにかなり依存してるんじゃない？

Hacker Newsで議論の続きを見る