See previous discussion here, here, here, and here. I'd like to have a dedicated discussion about adopting --quick, so splitting this out.

Summarizing, currently we run pod lib lint on all of our iOS and macOS plugin implementations; as far as I'm aware this gives us two major pieces of functionality:

1. Analyzes the code (in a synthetic project created on the fly by CocoaPods)
2. Validates the podspec itself

When this command was added, we didn't have any other native code analysis, but now we are explicitly running xcode-analyze. The CocoaPods-based analysis has a number of issues:

• It's duplicating non-trivial CI work that xcode-analyze does.
• It analyzes all transitive dependencies, so we get failures from code we don't control, causing us to have to turn it off for some plugins anyway.
• We don't control the project that is created, so we've had issues in the past where we can't turn off specific warnings in specific plugins.
• It uses a published Flutter pod rather than the local one (also because we don't control the project), which means we have to publish a Flutter pod any time we add new API and want to use it in flutter/plugins (example), which means we have to re-learn every year or two how to do this. And after the end of 2026, that will be impossible, so at some point we will have no choice but to turn this off anyway because it will be a hard blocker for using a new API (e.g., multi-view).

I think at this point (1) is net negative, and we should turn it off with --quick. We will still get whatever minimal linting of the podspec --quick does, but not have to deal with all the downsides of the analysis. The main downside is that we will lose some coverage of (2) but:

• We still build all our plugins in non-SwiftPM mode, so if we fully break CocoaPod integration we will catch that in presubmit in other tests.
• I can't remember the last time we had a real issue that this caught that another test didn't catch. (In theory since it builds in a couple of modes, it might catch errors that are specific to apps that force a different mode, but modules mostly abstracted away those differences anyway).
• We are unlikely to make any new complex podspec changes to any of our plugins at this point, since the plugins are mature and CocoaPods is being phased out.
• It looks from the source code like the main thing that we will lose other than the largely duplicate build validation is checking that the URLs are valid, and I don't think we care given that we don't actually expect anyone to ever look at the podspec anyway.

/cc @vashworth @jmagman