[thomson-t]

Why

Pull requests and releases of the Flutter plugin can soon be blocked for a reason unrelated to the change being made. CocoaPods, the older iOS package manager, is going read-only: its central repository plans to refuse uploads from 1 to 7 November 2026 as a test and permanently from 2 December 2026, dates the announcement says may move. The plugin's CocoaPods fallback takes its minimum iOS SDK version from the Swift Package Manager manifest, so once that minimum names a version that never reached CocoaPods, the CocoaPods build of the example app fails, and today that build blocks both merging and publishing to pub.dev. Once this lands, a CocoaPods dependency that cannot be resolved shows as a warning instead of failing the job. Compile errors in the CocoaPods build still fail it.

Programme

Standalone change, no programme.

What changes

• Before: a failure anywhere in "Build iOS flutter app (CocoaPods)" failed that job. The job is a required check, and the pub.dev release depends on it.
• After, when pod install fails: the old build step is now two steps. A new step, "Resolve CocoaPods dependencies", runs flutter build ios --config-only, which is where pod install happens. When it fails, a warning step reports it, the CocoaPods build is skipped, and the job stays green.
• After, when pods resolve:
  • The xcodebuild of the example app runs as a separate step and still fails the job on a compile error.
  • The check that the iOS SDK is linked only once also runs as before.
  • This is the only build that compiles the plugin's iOS sources through CocoaPods. The Swift Package Manager job removes the podspec.
• Unchanged:
  • "Switch example to CocoaPods" and the example's flutter test step still fail the job.
  • The Swift Package Manager job is unchanged and still required.
  • The CocoaPods iOS check can stay required. After this change it fails on test, setup and compile errors, but not on dependency resolution, and it is the only place the example's tests run.
• Docs and changelog: the README is unchanged in this pull request. The changelog entry comes from this title.

Start reading at the "Resolve CocoaPods dependencies" step in build-ios.yml.

Linked work

None.

Rollout

• Path: merging changes CI only. It is live from the merge for every pull request and for the next release run. No plugin code or published package changes.
• Feature flags: none.
• Turning it off: revert the pull request; the next run uses the old steps.
• What we watch: the CocoaPods iOS job on the next pull requests and the next release.
  • It stays green with no warning while trunk has the SDK versions the plugin asks for.
  • A warning on that job means the resolve step failed, most likely because a CocoaPods dependency no longer resolves. The job log names the cause. Setup and compile errors still fail the job.

Risks

• Any failure in the resolve step no longer blocks a merge or a release. That covers flutter pub get and flutter build ios --config-only, including its pod install, so a podspec that does not resolve also only produces a warning.
  • Not addressed: telling a version missing from CocoaPods apart from other resolve errors would mean matching CocoaPods' error output. The warning and step summary flag the failure.
  • How we would see it: a warning on the CocoaPods iOS job.
• When resolution fails, the CocoaPods compile and duplicate-SDK checks are skipped.
  • Contained by: they need resolved pods, and the warning covers that case. Once pods resolve, both fail the job as before.
  • How we would see it: both steps show as skipped next to the warning.

Risk class: low.

Who

• Written by: an automated coding agent, at a maintainer's request.
• Code reviewed before opening: no one.
• Design reviewed before opening: a maintainer agreed the approach before this was written.
• Decision this implements: keep the CocoaPods fallback while it still resolves, and stop its build from blocking merges and releases. The record is not public.
• Checked: actionlint on the workflow file, no issues.
• Not checked: the warning path. It needs a CocoaPods failure, which this pull request does not cause. The checks on this pull request exercise the passing path.

Size

Hand-written: 18 lines added and 3 removed, in 1 file.
Generated: none.

[claude]

Besides the inline finding, I checked the new step conditions. They correctly use outcome, not conclusion: with continue-on-error, outcome is still failure while conclusion becomes success. A skipped build step's outcome is skipped, so the linked-once check and the warning step each run only in the case they're meant for. The new comment, warning and summary text contain nothing internal or partner-identifying.

Extended reasoning...

I checked the step-condition semantics (outcome versus conclusion, and the skipped-step case) and the new text for internal or partner details, and found no further problems beyond the inline finding.