Does #22998 cover your request?

Potentially yes, but I would see #22998 a potential follow up to this ticket.

This ticket would only allow you to switch to use the bundler, and I would see #22998 to use the bundler by default when creating new projects.

So yes, it would cover our request, but I wouldn't say it is the same. Whether or not to, by default, use the bundler for cocoa pods is something that could be discussed after this ticket has been implemented. Also, #22998 has a quite big architectural decision to be made.

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

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.

@jmagman As said, while #22998 would also cover this, we could fix this with much less changes, by just using the bundler-installed pod if available.

That would only be a first step though, as it would only be available to people "in the know" with their own Gemfile (A new Flutter project without pod globally installed doesn't add such a file yet).

But I think it would be worthwhile, because if this project ever decides to put a Gemfile in place by default, it would probably keep using the same code (bundle exec pod first, pod second) for backwards compatibility.

Just let me know if you agree with the above sentiment and would be willing to accept a PR that adds a check to first check whether there is a bundler-managed pod version and would opt to use that.

I found rbenv global {{ruby_version}} can help

@jmagman As said, while #22998 would also cover this, we could fix this with much less changes, by just using the bundler-installed pod if available.

That would only be a first step though, as it would only be available to people "in the know" with their own Gemfile (A new Flutter project without pod globally installed doesn't add such a file yet).

But I think it would be worthwhile, because if this project ever decides to put a Gemfile in place by default, it would probably keep using the same code (bundle exec pod first, pod second) for backwards compatibility.

Just let me know if you agree with the above sentiment and would be willing to accept a PR that adds a check to first check whether there is a bundler-managed pod version and would opt to use that.

Any news about this? I agree with this answer

If someone wants to send a PR, sgtm to try bundle exec pod if a user-created Gemfile is present in ios directory, and bundle exec pod actually runs, with a fallback to vanilla pod.

It would be enough to make the cocoapods command configurable, so the user could substitute bundle exec pod for pod. In that case it wouldn't be necessary to check for the presence of Gemfile, change the strategy of the runner, or add fallback behavior

This just became more important because of this issue:
CocoaPods/CocoaPods#12080

Essentially, the global pod installation suddenly became broken because of an XCode update.
One option is to mess with the global pods via sudo or to use a Gemfile with bundler.
The sudo option is obviously not preferred.

Hello guys,
@ciriousjoker @wmadden @jmagman

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 also here, should close these as wont-fix given our work on SPM?

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