Fix an iOS Flutter Plugin Error by Checking the Pod Platform Target

Find the minimum supported platform in the actual error

An iOS plugin may require a higher deployment target than an older Flutter project declares. CocoaPods then reports that the pod does not support the current platform or cannot find a compatible version. Updating every pod or deleting Podfile.lock does not explain that mismatch.

Read the minimum version named by the plugin and compare it with the platform :ios value in ios/Podfile, the Xcode target's deployment setting, and any project configuration that overrides it. These values need to agree with the oldest OS version your product intends to support.

Raise the target intentionally

If product requirements allow it, update the Podfile platform and the relevant Xcode target settings together, then run pod install from the iOS project directory. Commit the lockfile change and inspect which pod versions moved. A successful pod install only proves dependency resolution; it does not prove the app still supports the devices your audience uses.

If the deployment target cannot be raised, pin a compatible plugin version or choose an alternative whose support range matches the product. Do not patch a plugin's podspec locally without a maintained fork; that can hide APIs the older OS does not provide.

Build the iOS scheme that CI archives, not only the simulator debug target. If CI and a developer resolve different pod versions, compare Ruby, CocoaPods, Xcode, and lockfile state. Keep the deployment floor documented because it is a product decision as much as a build setting.

Read the resolver message as a compatibility constraint

CocoaPods resolves a graph of native dependencies, and each pod can declare a minimum iOS version. The first useful error usually names the pod and the version it requires. Trace that pod back to the Flutter plugin that introduced it, then check the plugin's supported Flutter and iOS ranges. A podspec message is evidence about the native dependency graph; it is not a recommendation to raise the entire product's minimum OS without considering the users who will be excluded.

Compare all places that can set a deployment floor: the Podfile platform declaration, app and extension target build settings, generated Pods project settings, and any .xcconfig included by the target. A value in one place may be overridden in another. After a deliberate change, inspect the resolved project settings rather than assuming the Podfile was the last word. If only a notification extension or another target needs a newer OS, avoid raising unrelated targets without checking whether the product supports that separation.

Test the support decision on real build paths

Raising a deployment target can be a product change with a customer impact. Review device analytics and the published support policy before doing it. If the minimum cannot move, check whether an earlier plugin release supports the existing floor, or replace the plugin with one whose native code has a compatible range. Pinning an older plugin should include a security and maintenance review; the oldest technically compatible version is not automatically the best choice.

Once the values agree, run dependency resolution and inspect Podfile.lock for unexpected updates. Build the simulator configuration and the archive configuration used for distribution. A simulator build can pass while an extension target or signing action still uses an inconsistent setting. Keep the Xcode and CocoaPods versions visible in CI logs, because resolver behavior and supported project formats can change with those tools.

When a plugin update raises its minimum platform, document the reason, the affected targets, and the fallback decision. This gives reviewers context for a deployment-target diff and prevents a future cleanup from silently lowering the setting and reintroducing the same incompatibility.

Before merging, search the repository for other declarations of the old minimum, including extension targets and release configuration files. A partial update can make CocoaPods resolve successfully while Xcode still builds one target against an unsupported floor. Ask the release owner to confirm the supported-device impact, then add a CI check or review checklist that keeps the Podfile and target settings aligned during future plugin upgrades.

Also check extension and test targets for a different deployment floor. A project can compile its main app while a notification extension fails during archive. Record the chosen minimum in the release checklist, review device analytics before raising it, and pin a supported plugin version when the product cannot move the floor. This turns a one-time repair into a maintained product decision.