100% agree. I think we should basically take the same stance as CocoaPods. Continue to support the existing implementation for the foreseeable future, but we don't need to make effort to support any new features surrounding CocoaPods.
I think it will be premature to cut off support for CocoaPods right now as there may be packages that is available only on CocoaPods, and maybe not yet on SPM for whatever reason. On Tue, 2025-07-15 at 15:46 +0900, Bryan Ellis wrote: > Hi, > > I'd like to open a discussion on how Cordova should approach > CocoaPods > going forward. > > --- > > About a year ago, the CocoaPods team published a [blog post][1] > outlining > their future plans, stating that **CocoaPods is now in maintenance > mode**. > They also clarified what "maintenance" means [here][2]. > > More recently, approximately a month ago, they released another > [update][3] > announcing that the CocoaPods trunk will become **read-only**, and > the > GitHub repository will be archived in the future. Based on the > timelines > between these two posts, this change might happen around **November > 2026**. > > Given this, it seems clear that **Swift Package Manager > (SwiftPM)**—Apple's > own package management solution—is intended to be the primary tool > for > dependency management on iOS moving forward. > > CocoaPods even said: > > > "This move effectively took all the wind out of the sails of > > CocoaPods, > slowing active development of the project as competing with Apple on > their > own turf is rarely a battle worth your volunteer hours." [1] > > --- > > With this context in mind, I'd like to suggest that Cordova consider > **limiting the introduction of new CocoaPods-specific features**, > particularly those that would increase the scope of support for a > tool that > appears to be on a long-term path toward deprecation. > > Instead, it may make more sense to **continue maintaining the current > CocoaPods implementation**, ensuring that existing functionality > remains > stable and usable, without expanding our scope on a system that is > being > phased out. > > --- > > **Example: CocoaPods Plugin Support** > > One feature we never implemented is support for CocoaPods plugins, > which > were introduced back in 2013. > > This has recently come up because there's an [open PR in > `cordova-common`][4] as well as a [feature request in `cordova- > ios`][5] > related to plugin support. > > Although I'm not deeply familiar with CocoaPods plugins, the > [official > documentation][6] suggests that supporting them involves more than > simply > adding a plugin definition to the `Podfile` (which is what the > current PR > does). It appears a `Gemfile` is also required to define and install > the > plugins referenced in the Podfile. > > As far as I'm aware, Cordova does not currently manage or generate a > `Gemfile`. Supporting this would likely require us to figure out how > to > **create, manage, and install** dependencies with `bundler`, which > introduces additional complexity. > > --- > > I'd be interested in hearing others' thoughts on this. Does it make > sense > to limit further CocoaPods feature development? > > We have already been implementing SwiftPM support in preparation for > the > upcoming Cordova-iOS 8 release. > > Looking forward to the discussion. If we should move towards an > official > [VOTE] thread let me know. > > --- > > **References:** > > [1]: https://blog.cocoapods.org/CocoaPods-Support-Plans/ > [2]: > https://blog.cocoapods.org/CocoaPods-Support-Plans/#how-cocoapods-is-maintained > [3]: https://blog.cocoapods.org/CocoaPods-Specs-Repo > [4]: https://github.com/apache/cordova-common/pull/178 > [5]: https://github.com/apache/cordova-ios/issues/1256 > [6]: https://guides.cocoapods.org/plugins/setting-up-plugins.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
