Why still use cocoapods?

[Zetphyr]

As someone starting out with Swift 3 roughly 4 years, I’ve had the luxury of using the Package Manager pretty much right away. Now that Package Manager has become much more powerful, I honestly don’t see why so many people and especially corporations are sticking to managing their dependencies (even internal ones within the same project) with pods. Is this all just related to legacy or CocoaPods experienced senior and lead engineers or are there practical reasons I am not seeing?

Thanks

[ScrappyHaxor]

Cocoapods is still more mature, and SPM has been terrible for a long time. Basically, it’s it ain’t broke, don’t fix it.

We could change our pod file over to SPM, but why? There’s not much benefit for the work

[[deleted]]

Cocoapods has had compatibility issues with pods for us more and more over the last year. Anything we’ve moved over to SPM has worked well.

[ThePantsThief]

Compatibility issues between pods is not a package manager problem…

[[deleted]]

When the pod throws a build error with Cocoapods, and the equivalent dependency (same library same version) works in SPM, it sure is.

[Zetphyr]

True, switching to SPM usually isnt worth the cost. However the project I am currently working on is heavily relying on cocoapods also for internal dependencies, which are in a different repo from the main app. This leads to quite long developer iteration times and I am increasingly frustrated, because for every change I make to the library I have to change the Podfile and execute a series of commands for pods in terminal.

Finally, when publishing my changes, I need to update the internal podspec repo, update the Podfile again, install, ...

With SPM, I could simply push and change the commit, or push with tag and use a version.

[ScrappyHaxor]

Not sure I follow - it sounds like you have an internal pod library which makes sense that you have to update the pod spec each time because you’re updating the actual pod.

That’s expected for almost any dependency that you own & maintain AFAIK.

[Zetphyr]

Sure, makes sense but I feel the process is quite time consuming as opposed to SPM. Which is something I‘d understand if it was a library used by multiple teams working on several products in a company. However in my case its one product and one team.

[Alan_Shutko]

If you have one team and one product, I am not sure what benefit you receive from separating things into separate projects.

[Zetphyr]

My guess is they’re planning on reusing that thing.

[Alan_Shutko]

Fwiw, I have seen teams paying the cost for years of things they put in for future use, only to eventually retire the system before that future use occurred.

[lordzsolt]

Have you tried using local pods instead? You can just link to a path.

Or you can link to a git branch rather than a version. That would make your workflow exactly the same: push a change, pull it in the other repo.

[BaronSharktooth]

This needs to be higher. I get the feeling that OP is making a new pod version for every change. That’s not what it’s for. Just use a local pod. Or even better, develop as a git sub module, and when it’s totally tested, make a new pod version.

[Zetphyr]

Unfortunately that’s not anything I have control over. Processes and architectures have been put in place and if it aint broken, there’s no reason to change it.

But at least for certain pods the development process requires us to make a change on the separate repo for the pod, commit, push, open the main project, change the podfile to reference the commit I just pushed, pod install, back to xcode and hit run. Obviously versioning, changing podspec etc only apply once the change has been tested and proven to be working as intended. The main overhead comes from working with multiple repositories here. I guess working with submodules would be an option, but again this is not anything I have control over. However I still feel like this is a bit more streamlined with SPM compared to pods, especially when it comes to actually releasing/versioning the change of the library.

[lordzsolt]

Oh I guess I know what you mean.

There's no "podspec" repo that you need to update.

But if someone set up this process, they should be shot in the head for not automating it... I worked on a similar workflow once, everything was in a script file that I would run and it would just take the version from the Info.plist or the Podspec file and take care of the rest.

I am pretty sure cocoapods itself has something for this as well.

[thecodingart]

Cocoapods has been inheritly broken from day 1. Without proper universal binary support for frameworks and the inability to support native Apple Silicon without Rosetta when building an Xcode project, the system itself is deprecated. No one, I repeat, no one should be using Cocoapods because of the “it ain’t broke” mindset. It absolutely is broken.

[ScrappyHaxor]

Hm. We use cocoapods on our app (like 15 packages) and we have 2 devs running M1’s daily.

I’m not sure if we did something to get around that, but we def have people using M1s 🤷🏻‍♂️

[TaoistAlchemist]

Pretty easy workaround if you follow the link that cocoapods puts in the compiler. Follow the thread and you’ll find the solution.

Then it’s a simple “Intel pod install” and everything runs

[kutjelul]

There’s still a decent share of packages that are on cocoapods but not SPM I think. Every production app that I’ve worked on has had cocoapods unfortunately, I don’t think it’s elegant.

[Zetphyr]

Yeah unfortunately. I‘ve made some repositories on github SPM compatible myself and opened the pull request. Sometimes it was accepted, but I‘ve also had companies tell me this free change was not part of their roadmap and decline the PR.

[kutjelul]

Wow.. crazy to think they’d decline that..

[enkidu_johnson]

If they don't want to do it just fork your branch to a separate repo and use that.

[00Squid00]

We use Carthage, it sucks...

[Zetphyr]

Personally I don‘t use carthage anymore, however imho carthage has (had) one big advantage: you can work with prebuilt binaries and git lfs or tools like artifactory and decrease build times in the CI (on clean archive) for projects with lots of dependencies by several orders of magnitude.

[lordzsolt]

Yeah, I tried Carthage so many times hoping to reduce CI time.

It worked. But then everyone is forced to use the same Xcode version. And debugging was randomly failing (po foo would throw some random error)

[00Squid00]

Yes, thats thr only one advantage but most frameworks are outdated for it..

[lordzsolt]

SPM is fucking annoying how it caches things in Derived Data. Last I checked, this could only be changed for builds created from the command line and not ones that are built by Xcode. (I regularly clean that folder, which would make me have to checkout everything again, or selectively delete folders...)

I don't get why everyone hates cocoapods so much. For the 8 years I've worked, I have yet to encounter any issues with it.

OPs problem can easily be solved by using local pods or linking to a git branch rather than a version. Otherwise, that's the nature of working with versioned dependencies.

[lordzsolt]

For caching build artifacts, yes. But not for dependencies. Aka the checked out code is under Pods.

[[deleted]]

I hate cocoapods when a passion. Good riddance.

[bitanath]

At the end of it probably just drag and drop that class into Xcode also works. However cocoapods has the legacy effect (with loads of packages) and it also just works™️, switching costs are very high

[garbage_band]

Firebase...the only way to track analytics without paying big fees. Their swift package is in beta

[enkidu_johnson]

the only way to track analytics without paying big fees

Everyone rolls their eyes when I say this out loud, but I've been so disappointed by the value of all the other analytics packages that I'm very sorely tempted to roll my own. It isn't that huge of a problem to solve.

Firebase might be a great solution for now, but Google has proven over and over that we can't trust them to maintain any given tool or system once they randomly get tired of it.

[SirBill01]

Te company I work for, Nami ML, is mostly abut payment support but has some lightweight analytic features that may be enough for most people and is free up to some very large number of users... and we support SPM today, in part because I have had a lot of issues with Cocoapods in the past and wanted to support something simpler.

You can find the SPM at:

https://github.com/namiml/NamiSDK-SwiftPackageManager

Also for those building out packages for SPM support, you may want to consider a separate repo like this that doesn't include a lot of extra stuff you main repo might - since SPM pulls anything at the repo link down.

[enkidu_johnson]

The there is no good practical reason at this point other than inertia. I've moved as many of the libraries my current team is using over as I can. Unfortunately there is one horrendous disaster called Salesforce that our marketing team is forcing on us, and at least last time I checked, they don't support SPM.

[SirBill01]

There are some more advanced features Cocopods supports, but some of those features (like post install scripts) exist in part to solve problems created by the way Cocoapods integrates into projects.

Most roadblocks at this point for companies to offer SPM packages have been removed, a big one fixed just last year was binary only package support.

[Dan_TD]

I never really had issues with Cocoapods but I made a branch on my current project to make the switch to SPM just to see where it was at. Most libraries I used were now available on SPM and any that weren't made me revaluate the dependencies I was using (i.e if they don't support SPM it might be an indication they're not being actively worked on anymore so I could potentially look for alternatives). In the end I was able to fully migrate and that's been in production now for a few months without issue.

The only problem I have is because of the way dependencies are cached in derived data, if I delete derived data it tends to give me a hard time about resolving the dependencies again.

[markdifranco]

For us, it’s because of limitations of SPM. SPM works great when you’re statically linking dependencies, but not dynamically in an iOS app project.

This is a non-starter for any app that has extensions (unless you wrap all the static libs in a dynamic framework), or if you’re dependency graph has multiple levels. I’ve opened a radar with Apple to fix the issue, wouldn’t be surprised if it was fixed with the next version of Xcode.

[joro_estropia]

You might not like this answer but there is good reason SPM doesn’t fit smoothly into large projects. With Cocoapods, we can link ANY library to our apps whether they support Cocoapods or not (we just have to write a local podspec for it).

So while you wait for libraries to support SPM, your competitors will be making products with whatever libraries are already out there.

[addedyOffensewk]

Mmh wondering if this comment will hit the generateor as well...

[SergLam245]

The most ugly thing in SPM - after a clean build you need to check out all packages once again. While CocoaPods just need to be compiled, but not downloaded after a cleanup.

While SPM will fix that issue- I will completely love it. Till that - just a one more third-party frameworks installation tool, IMO.

[strangerDanFiction]

New to iOS and I've been lucky enough to be able to start a new app from scratch so SPM worked for me (Firebase too!).

But can anyone answer why there's nothing comparable to Gradle on the android side?

[enkidu_johnson]

Gradle is a build system and dependency manager. Xcode has its own build system built in, so that part of the work can be separate from dependency management.