I also noticed that when running flutter run it uses the global version of pod, so it's difficult to restrict version of pod. We use Bundler to manage version of fastlane and cocoapods for other commands, and fastlane respects Bundler if Gemfile is available. I hope flutter can do similar check.

The same thing. We're using fastlane for CI/CD and it require cocoapods to be in Gemfile. So as a workaround I currently have two cocoapods installed - the first one is installed globally and the second one is installed by bundler and used for archiving. Not so good solution anyway. I'd like flutter to respect Gemfile if it persists...

**NOTE: ** Should consider switching to SPM instead and there will be no need for CocoaPods and therefore Bundler, unless are there any other gems that are being used?

I also like to have all dependencies strictly set by a project environment (.ruby-version, Gemfile, Podfile - you know). And as I working with many projects at the same time, some of them are legacy, I can't rely on global versions of any tools. So I would love to have flutter build which respects Gemfile and Bundler as fastlane does

Related to #40135

Hello guys,
@Antol @vysotsky @allenhsu

I added the feature to support Bundler to manage Gem dependencies, please review the PR and test it out and share you suggestions if any to improve it.

Here is the Draft PR.

Meanwhile I'm working on the tests for my changes to be done this week.

Thank you.

@loic-sharma should we close this issue as a wont-fix since we're focusing on swift package manager?

Thanks for the ping! We can close this issue once we started deprecating CocoaPods. I added it to the Swift Package Manager umbrella issue: #126005

@loic-sharma I'm going to close this issue because, in my opinion, we shouldn't add new functionality supporting cocoapods since we are imminently deprecating it anyway. This is to stop well-meaning people from opening PRs implementing this feature.

If you feel strongly, feel free to re-open this issue.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.