7 ms·

CocoaPods trunk read-only plan

248 points by matharmin 1y ago

nazgu1 1y ago
Such a big piece of history and a de facto standard for managing dependencies for Apple platforms for years. Big "thank you" to all maintainers for your great job! And respect that you recognise moment when ecosystem changed and have courage to deprecate library instead of maintaining it forever - to leave place for migrating to new, superior solutions
- cnnlives65 1y ago
  > superior solutions Superior includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic.
  - nikanj 1y ago
    Open source superior just means newer, even if it comes with less features and more bugs
    - exe34 1y ago
      Superior means it does 5 new things that the 5 maintainers wanted, but nobody else uses.
    - orta 1y ago
      OP here, luckily in this case, it means a more supported and vertically integrated alternative. Which does have less features, but actually gets bugs fixed and keeps up to date with the platform - so it's a net win overall IMO
      - ddlsmurf 1y ago
        Thanks, your work was of huge value to me, way more than you were rewarded for, sorry :/
    - asveikau 1y ago
      This happens in proprietary software too.
sturza 1y ago
End of an era.
- deadbabe 1y ago
  Was it a good era?
  - frizlab 1y ago
    No.
  - gregoriol 1y ago
    Better than the "current" future
  - Cthulhu_ 1y ago
    Probably not, but all modern-day package managers owe a debt to Cocoapods for the things it did right and the things that could have been better.
  - weego 1y ago
    No pods are an absolute misery and at best a concrete example of what not to do. So at least there's that.
  - Manfred 1y ago
    You have to understand where we came from. Development for iOS and macOS (then MacOS) meant you had to pluck source files from random places on the internet and weave them into your Xcode build. Xcode and xcodebuild didn't really shine in the department of extensibility. Eloy designed CocoaPods to be the absolute minimum we needed to deal with dependencies for the projects we were working on. So that meant: * Rely on GitHub for hosting so nobody would get bankrupted running the repo, with the option to switch over to self-hosted in case that ever became necessary. * Use Git and existing project tools on GitHub to deal with external contributions for pods. * Use Ruby for scripting because that was what people used most at that time. * Use Ruby for pod definitions for flexibility and reduced development time (ie. so CocoaPods didn't need a parser). For a long time this was a one-person effort. All of those decision obviously have downsides, even more obvious now you have to power of hindsight given years of incremental improvements on speed and security of dependency managers. I think Eloy did a great job in general and the popularity gained speaks for itself.
bingemaker 1y ago
Thoroughly enjoyed while it lasted! Thank you maintainers.
aravindputrevu 1y ago
Isnt this a old news? I'm thinking of Swift Package manager for all the stuff new.
- gregoriol 1y ago
  From my experience, about 20-30% of the packages are not working with swiftpm, either because they don't have a Package.swift file, or because it is not compatible with up-to-date developer tools. On many projects, I had to fork a few repositories just to add or fix the swiftpm integration... while their Pod integration has always been working well.
  - rTX5CMRXIfFG 1y ago
    That is the cost of using third party libraries, hardly the fault of either SPM or Cocoapods.
  - manmal 1y ago
    I‘d say it’s 2% now, of the maintained ones? I haven’t seen such a project in a long while now. React Native is the only one I can think of.
gregoriol 1y ago
This is really sad, because the replacement, Swift Package Manager, is really crap: it lacks some useful features (an "outdated" command, meaningful commandline output, ...), is buggy as hell in xcode (most of the time xcode just crashes when you add/removed a dependency, error messages while getting a repository are not understandable and even often not visible entirely, many repositories have some old Package.swift that current developer tools won't read, ...), and worst of all, it stores the full repositories of all the dependencies with their full history on your machine and downloads them every time when you do CI properly, which often means GBs of data.
- wahnfrieden 1y ago
  Tuist
  - richrichardsson 1y ago
    In spite of search engines being a thing, this comment could have done with a bit more information. I assume you're talking about this: https://docs.tuist.dev/en/ https://docs.tuist.dev/en/
    - wahnfrieden 1y ago
      Yes. There's no ambiguity, no other project uses the name
      - MobiusHorizons 1y ago
        It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)
        johnisgood 1y ago
        > I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc) That is on you, though.
AJRF 1y ago
Doesn't React Native depend on this very heavily for iOS?
- mrbombastic 1y ago
  It does, in recent react native versions they show a deprecation warning when running “pod install” directly which is probably a signal they are working on moving to other package managers, but not aware of what the plan is.
- oefrha 1y ago
  Yeah, and according to https://expo.dev/blog/precompiled-react-native-for-ios https://expo.dev/blog/precompiled-react-native-for-ios and linked https://github.com/react-native-community/discussions-and-proposals/issues/587#issuecomment-2777982810 https://github.com/react-native-community/discussions-and-pr..., it seems moving off CocoaPods has barely moved past planning stage. Latest update from two weeks ago links to https://github.com/facebook/react-native/pull/52909 https://github.com/facebook/react-native/pull/52909 and says it’s very very experimental. Just great…
  - AJRF 1y ago
    Gosh, that is a worry. Maybe I can help out here (I imagine the politics of a project this large will frustrate me though)
    - adithyassekhar 1y ago
      Why would you work for free for Facebook
      - mrbombastic 1y ago
        rn is open source so I don’t personally see it as working for free for facebook but rather working for free for the dev community
        1y ago
seanalltogether 1y ago
Apple has always made it painful to step too far off the path with their tooling and frameworks and cocoapods was not immune to that pain. I'm grateful of what they made and the pressure they put on Apple to make things better, but I was very happy to remove yet another 3rd party dependency from our toolchain the moment we were able to.
- Terretta 1y ago
  > Apple has always made it painful to step too far off the path Or, "Apple has always avoided spending dev cycles too far off the path, electing instead to make the path itself easier." xCode with built-in live rebuild preview simulator plus xCode Cloud with Testflight which auto-builds on git push is a remarkable value for $8.33 a month.
  - jamil7 1y ago
    > xCode with built-in live rebuild preview simulator You couldn't have picked a slower, more buggy, opaque feature to highlight here. Its useful for UI work when it works properly but I feel like I have to mentally prepare myself everytime I switch the canvas on to avoid throwing the computer out the window. I'll agree on Xcode Cloud though, integrated CI, signing and TestFlight builds with minimal hassle is very nice.
karel-3d 1y ago
The reasoning is here, from 2024 https://blog.cocoapods.org/CocoaPods-Support-Plans/ https://blog.cocoapods.org/CocoaPods-Support-Plans/ The timeline in the original article seems very reasonable to me. They go out of their way to avoid breakages.
tonyhart7 1y ago
good news, react native and flutter piggyback on external deps need to stop
- myko 1y ago
  https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developers https://docs.flutter.dev/packages-and-plugins/swift-package-... https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-plugin-authors https://docs.flutter.dev/packages-and-plugins/swift-package-... no idea if google will nix flutter tomorrow or not but it is extremely well run and seems to stay ahead of things pretty well, even though i'd rather write Swift than Dart (or Kotlin, for that matter)
forgingahead 1y ago
Sad, truly an end of an era. Big thanks to all maintainers!
ChrisMarshallNY 1y ago
It was useful, but way too delicate. I didn't like the way that it rewrote my project structure. Once Swift Package Manager matured, I stopped using CocoaPods.
- josteink 1y ago
  As someone with no direct love of CocoaPods... Is there a way to use SPM for mixed ObjC and Swift projects? I'd love to know if I have options :)
  - ChrisMarshallNY 1y ago
    I'm not sure. I suspect so, but I haven't used ObjC since 2014.
  - kenshi 1y ago
    Yes, you can use SPM to package up Objective-C code.
    - armadsen 1y ago
      Right, but you can’t have a single package containing both ObjC and Swift. It’s a limitation of SwiftPM that has prevented me from using it for a few projects (I am using it in several others, though).
      - einsteinx2 1y ago
        You can mix them, it just has to be released as a binary framework which is a bit annoying as I would prefer a pure source release but it does work.
        josteink 1y ago
        Since it clearly wasn’t obvious, I was asking in the context of a package consumer, not publisher. My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)
basisword 1y ago
The end of an era! Goodbye xcworkspace. For most of my use cases SPM is now much easier to use and causes less issues but a great effort from all the Cocoapods maintainers over the years. I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?
- gorbypark 1y ago
  React native support for SPM is non-existent for the most part. There's some work on porting to SPM but it's gonna be a while before anything becomes stable. It's going to break a huge amount of 3rd party packages. A bit of shame this wasn't done earlier as the RN ecosystem just went (or, is still going) through a migration to the "new architecture" that required most 3rd party packages that use native code to be "ported" over. Could have been a two-for-one kinda thing!
  - cyberax 1y ago
    React-Native is blocked by SwiftPM not supporting mixed ObjC and Swift packages. It needs that to support both the Old Architecture and the New Architecture at the same time.
stevage 1y ago
>I don't think I'm amenable to moving it forwards, but within reason there's space for backwards. Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.
einsteinx2 1y ago
Finally!! I never liked CocoaPods due to how it “takes over” your Xcode project. I used to prefer Carthage, then just git submodules, then SPM. In my last job I oversaw SDK development and CocoaPods was the bain of my existence. Constant CDN problems causing release delays, annoying extra file in Ruby to maintain, different behavior than our other releases due to how CocoaPods builds projects, etc. SPM was as simple as pushing a git tag and maintaining a simple Swift file, while pushing to CocoaPods was rolling the dice how many times I’d get an error message. Good riddance!
- ardit33 1y ago
  lol... you really don't like it, do you. I used it for a couple of my projects, and I kinda agree with you. I didn't like it at all how it took over projects (you have to use a workspace). For my small personal projects, eventually I ended up into reverting to just downloading the dependencies myself into a lib folder. A bit more work upfront, but simpler builds and you know what's going into your project. I think it had its use and time, and it is good for the maintainers to mark it deprecated and time to move on.
  - einsteinx2 1y ago
    Haha I really don’t, but I do get why others liked it, it was just never for me. I also forgot the intermediate step I took between git submodules and SPM where I did exactly what you did with manually adding deps to the project. Git submodules is it’s own frustrating hell lol… More recently though the lack of maintenance of the CDN causing lots of problems not only publishing but even just pod installs failing was really frustrating, and as an SDK/framework maintainer just having to support multiple package managers was a huge pain in the ass. Especially with React Native requiring CocoaPods and having its own weird problems we have to solve in the pod file. But yeah glad to see it being sunset now that there’s an officially sanctioned package manager. I know some people will complain that SPM isn’t as full featured as CocoaPods but I’ve found it gets the job done and the fact it’s both run off a simple Swift file and git tags and has official support from Apple is great. Kind of reminds me of Carthage for the modern age, in a good way.
- 1y ago
pbd 1y ago
The interesting question is what happens to the ~100k+ pods that never migrated to SPM. There's probably a lot of useful but abandoned code that smaller projects still depend on. This creates a bifurcation where legacy projects get stuck on older toolchains.
- matharmin 1y ago
  You'll still be able to use those - the CocoaPods repo will not go away any time soon. If someone wants to provide updates for those, it has to be migrated to SwiftPM. And in the meantime you may have to use both SwiftPM and CocoaPods, or fork & migrate those yourself.
- andrekandre 1y ago
  > The interesting question is what happens to the ~100k+ pods that never migrated to SPM. from experience in a few projects that migrated to spm: fork and port to spm (at the same time, mark them as deprecated and slowly wean off them) > abandoned code that smaller projects still depend on there are alot of large commercial projects too that are in the same boat...
jhatemyjob 1y ago
And this, kids, is why you should always vendorize your dependencies
- matharmin 1y ago
  There may be good reasons to do that, but this isn't one. Any project using CocoaPods will still remain working for the foreseeable future - you'll just not get new updates to dependencies at some point. And at that point you can migrate to SwiftPM or vendored dependencies, without losing anything.
  - jhatemyjob 1y ago
    Good idea let's punt it to 20 years from now when the CocoaPods server goes down. By then the startup will have been acquired and we will be long gone, so it's the parent company's problem not ours.

248 points by matharmin 1y ago

Such a big piece of history and a de facto standard for managing dependencies for Apple platforms for years. Big "thank you" to all maintainers for your great job! And respect that you recognise moment when ecosystem changed and have courage to deprecate library instead of maintaining it forever - to leave place for migrating to new, superior solutions

cnnlives65 1y ago
> superior solutions Superior includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic.
- nikanj 1y ago
  Open source superior just means newer, even if it comes with less features and more bugs
  - exe34 1y ago
    Superior means it does 5 new things that the 5 maintainers wanted, but nobody else uses.
  - orta 1y ago
    OP here, luckily in this case, it means a more supported and vertically integrated alternative. Which does have less features, but actually gets bugs fixed and keeps up to date with the platform - so it's a net win overall IMO
    - ddlsmurf 1y ago
      Thanks, your work was of huge value to me, way more than you were rewarded for, sorry :/
  - asveikau 1y ago
    This happens in proprietary software too.

sturza 1y ago

End of an era.

deadbabe 1y ago
Was it a good era?
- frizlab 1y ago
  No.
- gregoriol 1y ago
  Better than the "current" future
- Cthulhu_ 1y ago
  Probably not, but all modern-day package managers owe a debt to Cocoapods for the things it did right and the things that could have been better.
- weego 1y ago
  No pods are an absolute misery and at best a concrete example of what not to do. So at least there's that.
- Manfred 1y ago
  You have to understand where we came from. Development for iOS and macOS (then MacOS) meant you had to pluck source files from random places on the internet and weave them into your Xcode build. Xcode and xcodebuild didn't really shine in the department of extensibility. Eloy designed CocoaPods to be the absolute minimum we needed to deal with dependencies for the projects we were working on. So that meant: * Rely on GitHub for hosting so nobody would get bankrupted running the repo, with the option to switch over to self-hosted in case that ever became necessary. * Use Git and existing project tools on GitHub to deal with external contributions for pods. * Use Ruby for scripting because that was what people used most at that time. * Use Ruby for pod definitions for flexibility and reduced development time (ie. so CocoaPods didn't need a parser). For a long time this was a one-person effort. All of those decision obviously have downsides, even more obvious now you have to power of hindsight given years of incremental improvements on speed and security of dependency managers. I think Eloy did a great job in general and the popularity gained speaks for itself.

bingemaker 1y ago

Thoroughly enjoyed while it lasted! Thank you maintainers.

aravindputrevu 1y ago

Isnt this a old news? I'm thinking of Swift Package manager for all the stuff new.

gregoriol 1y ago
From my experience, about 20-30% of the packages are not working with swiftpm, either because they don't have a Package.swift file, or because it is not compatible with up-to-date developer tools. On many projects, I had to fork a few repositories just to add or fix the swiftpm integration... while their Pod integration has always been working well.
- rTX5CMRXIfFG 1y ago
  That is the cost of using third party libraries, hardly the fault of either SPM or Cocoapods.
- manmal 1y ago
  I‘d say it’s 2% now, of the maintained ones? I haven’t seen such a project in a long while now. React Native is the only one I can think of.

gregoriol 1y ago

This is really sad, because the replacement, Swift Package Manager, is really crap: it lacks some useful features (an "outdated" command, meaningful commandline output, ...), is buggy as hell in xcode (most of the time xcode just crashes when you add/removed a dependency, error messages while getting a repository are not understandable and even often not visible entirely, many repositories have some old Package.swift that current developer tools won't read, ...), and worst of all, it stores the full repositories of all the dependencies with their full history on your machine and downloads them every time when you do CI properly, which often means GBs of data.

wahnfrieden 1y ago
Tuist
- richrichardsson 1y ago
  In spite of search engines being a thing, this comment could have done with a bit more information. I assume you're talking about this: https://docs.tuist.dev/en/ https://docs.tuist.dev/en/
  - wahnfrieden 1y ago
    Yes. There's no ambiguity, no other project uses the name
    - MobiusHorizons 1y ago
      It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)
      - johnisgood 1y ago
        > I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc) That is on you, though.

AJRF 1y ago

Doesn't React Native depend on this very heavily for iOS?

mrbombastic 1y ago
It does, in recent react native versions they show a deprecation warning when running “pod install” directly which is probably a signal they are working on moving to other package managers, but not aware of what the plan is.
oefrha 1y ago
Yeah, and according to https://expo.dev/blog/precompiled-react-native-for-ios https://expo.dev/blog/precompiled-react-native-for-ios and linked https://github.com/react-native-community/discussions-and-proposals/issues/587#issuecomment-2777982810 https://github.com/react-native-community/discussions-and-pr..., it seems moving off CocoaPods has barely moved past planning stage. Latest update from two weeks ago links to https://github.com/facebook/react-native/pull/52909 https://github.com/facebook/react-native/pull/52909 and says it’s very very experimental. Just great…
- AJRF 1y ago
  Gosh, that is a worry. Maybe I can help out here (I imagine the politics of a project this large will frustrate me though)
  - adithyassekhar 1y ago
    Why would you work for free for Facebook
    - mrbombastic 1y ago
      rn is open source so I don’t personally see it as working for free for facebook but rather working for free for the dev community
      - 1y ago

seanalltogether 1y ago

Apple has always made it painful to step too far off the path with their tooling and frameworks and cocoapods was not immune to that pain. I'm grateful of what they made and the pressure they put on Apple to make things better, but I was very happy to remove yet another 3rd party dependency from our toolchain the moment we were able to.

Terretta 1y ago
> Apple has always made it painful to step too far off the path Or, "Apple has always avoided spending dev cycles too far off the path, electing instead to make the path itself easier." xCode with built-in live rebuild preview simulator plus xCode Cloud with Testflight which auto-builds on git push is a remarkable value for $8.33 a month.
- jamil7 1y ago
  > xCode with built-in live rebuild preview simulator You couldn't have picked a slower, more buggy, opaque feature to highlight here. Its useful for UI work when it works properly but I feel like I have to mentally prepare myself everytime I switch the canvas on to avoid throwing the computer out the window. I'll agree on Xcode Cloud though, integrated CI, signing and TestFlight builds with minimal hassle is very nice.

karel-3d 1y ago

The reasoning is here, from 2024 https://blog.cocoapods.org/CocoaPods-Support-Plans/ https://blog.cocoapods.org/CocoaPods-Support-Plans/ The timeline in the original article seems very reasonable to me. They go out of their way to avoid breakages.

tonyhart7 1y ago

good news, react native and flutter piggyback on external deps need to stop

myko 1y ago
https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developers https://docs.flutter.dev/packages-and-plugins/swift-package-... https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-plugin-authors https://docs.flutter.dev/packages-and-plugins/swift-package-... no idea if google will nix flutter tomorrow or not but it is extremely well run and seems to stay ahead of things pretty well, even though i'd rather write Swift than Dart (or Kotlin, for that matter)

forgingahead 1y ago

Sad, truly an end of an era. Big thanks to all maintainers!

ChrisMarshallNY 1y ago

It was useful, but way too delicate. I didn't like the way that it rewrote my project structure. Once Swift Package Manager matured, I stopped using CocoaPods.

josteink 1y ago
As someone with no direct love of CocoaPods... Is there a way to use SPM for mixed ObjC and Swift projects? I'd love to know if I have options :)
- ChrisMarshallNY 1y ago
  I'm not sure. I suspect so, but I haven't used ObjC since 2014.
- kenshi 1y ago
  Yes, you can use SPM to package up Objective-C code.
  - armadsen 1y ago
    Right, but you can’t have a single package containing both ObjC and Swift. It’s a limitation of SwiftPM that has prevented me from using it for a few projects (I am using it in several others, though).
    - einsteinx2 1y ago
      You can mix them, it just has to be released as a binary framework which is a bit annoying as I would prefer a pure source release but it does work.
      - josteink 1y ago
        Since it clearly wasn’t obvious, I was asking in the context of a package consumer, not publisher. My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)

basisword 1y ago

The end of an era! Goodbye xcworkspace. For most of my use cases SPM is now much easier to use and causes less issues but a great effort from all the Cocoapods maintainers over the years. I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?

gorbypark 1y ago
React native support for SPM is non-existent for the most part. There's some work on porting to SPM but it's gonna be a while before anything becomes stable. It's going to break a huge amount of 3rd party packages. A bit of shame this wasn't done earlier as the RN ecosystem just went (or, is still going) through a migration to the "new architecture" that required most 3rd party packages that use native code to be "ported" over. Could have been a two-for-one kinda thing!
- cyberax 1y ago
  React-Native is blocked by SwiftPM not supporting mixed ObjC and Swift packages. It needs that to support both the Old Architecture and the New Architecture at the same time.

stevage 1y ago

>I don't think I'm amenable to moving it forwards, but within reason there's space for backwards. Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.

einsteinx2 1y ago

Finally!! I never liked CocoaPods due to how it “takes over” your Xcode project. I used to prefer Carthage, then just git submodules, then SPM. In my last job I oversaw SDK development and CocoaPods was the bain of my existence. Constant CDN problems causing release delays, annoying extra file in Ruby to maintain, different behavior than our other releases due to how CocoaPods builds projects, etc. SPM was as simple as pushing a git tag and maintaining a simple Swift file, while pushing to CocoaPods was rolling the dice how many times I’d get an error message. Good riddance!

ardit33 1y ago
lol... you really don't like it, do you. I used it for a couple of my projects, and I kinda agree with you. I didn't like it at all how it took over projects (you have to use a workspace). For my small personal projects, eventually I ended up into reverting to just downloading the dependencies myself into a lib folder. A bit more work upfront, but simpler builds and you know what's going into your project. I think it had its use and time, and it is good for the maintainers to mark it deprecated and time to move on.
- einsteinx2 1y ago
  Haha I really don’t, but I do get why others liked it, it was just never for me. I also forgot the intermediate step I took between git submodules and SPM where I did exactly what you did with manually adding deps to the project. Git submodules is it’s own frustrating hell lol… More recently though the lack of maintenance of the CDN causing lots of problems not only publishing but even just pod installs failing was really frustrating, and as an SDK/framework maintainer just having to support multiple package managers was a huge pain in the ass. Especially with React Native requiring CocoaPods and having its own weird problems we have to solve in the pod file. But yeah glad to see it being sunset now that there’s an officially sanctioned package manager. I know some people will complain that SPM isn’t as full featured as CocoaPods but I’ve found it gets the job done and the fact it’s both run off a simple Swift file and git tags and has official support from Apple is great. Kind of reminds me of Carthage for the modern age, in a good way.
1y ago

pbd 1y ago

The interesting question is what happens to the ~100k+ pods that never migrated to SPM. There's probably a lot of useful but abandoned code that smaller projects still depend on. This creates a bifurcation where legacy projects get stuck on older toolchains.

matharmin 1y ago
You'll still be able to use those - the CocoaPods repo will not go away any time soon. If someone wants to provide updates for those, it has to be migrated to SwiftPM. And in the meantime you may have to use both SwiftPM and CocoaPods, or fork & migrate those yourself.
andrekandre 1y ago
> The interesting question is what happens to the ~100k+ pods that never migrated to SPM. from experience in a few projects that migrated to spm: fork and port to spm (at the same time, mark them as deprecated and slowly wean off them) > abandoned code that smaller projects still depend on there are alot of large commercial projects too that are in the same boat...

jhatemyjob 1y ago

And this, kids, is why you should always vendorize your dependencies

matharmin 1y ago
There may be good reasons to do that, but this isn't one. Any project using CocoaPods will still remain working for the foreseeable future - you'll just not get new updates to dependencies at some point. And at that point you can migrate to SwiftPM or vendored dependencies, without losing anything.
- jhatemyjob 1y ago
  Good idea let's punt it to 20 years from now when the CocoaPods server goes down. By then the startup will have been acquired and we will be long gone, so it's the parent company's problem not ours.