ハクソク

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

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

266日前原文(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に対してこれにかなり依存してるんじゃない？

└

そうだよ。最近のReact Nativeのバージョンでは、「pod install」を直接実行すると非推奨の警告が出るから、他のパッケージマネージャーに移行しようとしてるのかもしれないけど、具体的な計画は知らないんだよね。

└

そうだね、https://expo.dev/blog/precompiled-react-native-for-ios とリンクされてる https://github.com/react-native-community/discussions-and-pr... によると、CocoaPodsからの移行はまだ計画段階をほとんど進んでないみたい。2週間前の最新のアップデートでは、https://github.com/facebook/react-native/pull/52909 にリンクされてて、すごく実験的だってさ。ほんと最高だね…

└

ハイブリッドモバイルアプリにはCapacitorもあるよ。

└

Flutterもね: https://docs.flutter.dev/get-started/install/macos/mobile-io...

└

Unityもそうだと思うよ。

Appleはいつもツールやフレームワークからあまりにも離れたことをするのを痛めつけてきたし、CocoaPodsもその痛みから逃れられなかった。彼らが作ったものには感謝してるし、Appleに改善を促す圧力も感謝してるけど、私たちのツールチェーンからまた別のサードパーティの依存関係を取り除けた時は本当に嬉しかった。

└

Appleは常に道から外れるのを痛い思いをさせてきた。 それとも、「Appleは常に開発サイクルを道から外れすぎないように避けて、代わりに道自体を楽にすることを選んできた。」 xCodeの内蔵ライブリビルドプレビューシミュレーターと、git pushで自動ビルドするTestflight付きのxCode Cloudは、月8.33ドルで素晴らしい価値だね。

理由はここにあるよ、2024年の https://blog.cocoapods.org/CocoaPods-Support-Plans/ で。元の記事のタイムラインはすごく妥当だと思う。彼らは壊れないようにかなり気を使ってるね。

役に立ったけど、すごくデリケートだった。プロジェクト構造を勝手に書き換えるのが気に入らなかったな。Swift Package Managerが成熟してからは、CocoaPodsは使わなくなったよ。

└

CocoaPodsに特に愛着がないんだけど… ObjCとSwiftの混合プロジェクトでSPMを使う方法ってあるのかな？選択肢があれば知りたいな :)

前に進むのにはあまり賛成できないけど、理にかなった範囲内で後ろに進む余地はあると思う。ちなみに、「前に進む」と「後ろに進む」をこういう発言で同じように解釈する人はみんなじゃないよ。「早く」や「遅く」と言った方が分かりやすい。

やっとだ！！ CocoaPodsがXcodeプロジェクトを「支配する」感じが嫌いだった。前はCarthageが好きだったけど、次はgitサブモジュール、そしてSPMに行き着いた。前の仕事ではSDK開発を監督してて、CocoaPodsは本当に厄介だった。常にCDNの問題でリリースが遅れたり、維持が面倒なRubyの余計なファイルがあったり、CocoaPodsがプロジェクトをビルドする方法のせいで他のリリースとは違う挙動をしたり。SPMはgitタグをプッシュしてシンプルなSwiftファイルを維持するだけで簡単だったし、CocoaPodsにプッシュするのはエラーメッセージが出る確率がどれくらいかの賭けみたいなもんだった。さようなら！

└

笑… 本当に嫌いなんだね。いくつかのプロジェクトで使ったけど、ちょっと同意するよ。プロジェクトを支配する感じが全然好きじゃなかった（ワークスペースを使わなきゃいけないし）。小さな個人プロジェクトでは、結局自分で依存関係をlibフォルダにダウンロードすることに戻った。最初はちょっと手間だけど、ビルドがシンプルで、自分のプロジェクトに何が入ってるか分かるからね。使い道と時期はあったと思うし、メンテナが非推奨にするのは良いことだと思う。次に進む時だね。

└

それは時代の産物だったし、Appleが本当に対処しなかった問題を浮き彫りにしたよね。SPMの未来にはもっと自信が持てるようになった。少なくとも、Swiftと一緒に進んでいる感じがするから。

面白いのは、SPMに移行しなかった約10万個のポッドがどうなるかってこと。小さなプロジェクトが依存している、役に立つけど放置されたコードがたくさんあると思う。これが原因で、レガシープロジェクトが古いツールチェーンに縛られちゃうんだよね。