Add CI steps to test iOS and macOS plugins with both CocoaPods and Swift Package Manager

[vashworth]

Tests new Swift Package Manager feature added in flutter/flutter#146256.

Fixes flutter/flutter#146901.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[stuartmorgan]

I don't think we need to build-all twice; there's already some redundancy in the build-all app vs individual example builds. We use that redundancy to get x64/arm64 coverage already, and I would vote for doing the same thing here.

To do that we would remove this step, and only build-all with SPM. That gives us SPM build coverage of all plugin in this step, and CocoaPods coverage in all the example app builds. Then when the flag is removed or reversed, we switch build-all to force SPM off and reverse the coverage roles.

[vashworth]

So if I understand correctly, you're suggesting we update build-all (https:/flutter/packages/blob/main/.ci/targets/ios_build_all_packages.yaml / https:/flutter/packages/blob/main/.ci/scripts/build_all_packages_app.sh) to have SPM enabled so it builds all with SPM.

And then in platform tests (this file), only build with CocoaPods?

Just a reminder, native tests will need to be run with SPM enabled because CocoaPod testing dependencies will have been removed (see "Updating unit tests in plugin example app"), which will make native tests not be able to be run without SPM. But we can still do what you're suggesting and just add a new step to the yaml that enables SPM

packages/.ci/targets/ios_platform_tests.yaml

Lines 25 to 28 in ea572aa

	- name: native test
	script: .ci/scripts/tool_runner.sh
	# Simulator name and version must match name and version in create_simulator.sh
	args: ["native-test", "--ios", "--ios-destination", "platform=iOS Simulator,name=Flutter-iPhone,OS=17.0"]

[stuartmorgan]

And then in platform tests (this file), only build with CocoaPods?

Whoops, I was skimming and thought this was the build-all step. But yes, thanks for figuring out what I meant despite the confusing description.

Just a reminder, native tests will need to be run with SPM enabled because CocoaPod testing dependencies will have been removed

Right, I forgot about that.

I guess we could flip it around from the start, and do the SPM testing in-package, and the CocoaPod testing only in build-all (and, until the flag reaches stable, in stable post-submit). The reason I was thinking we should start the other way is that we could potentially break the example app for people who don't have the flag enabled without noticing if we only tested SPM in-package, but the impact of that if it happens is extremely small, so probably not worth worrying about unless it actually starts happening in practice.

[vashworth]

The reason I was thinking we should start the other way is that we could potentially break the example app for people who don't have the flag enabled without noticing if we only tested SPM in-package

So the way I currently have set up, it builds the example app with the flag disabled, then it builds with the flag enabled, then it runs tests (still with the flag enabled).

So the example app builds with both the flag disabled (aka CocoaPods only) and enabled. I'm inclined to keep it this way so we can be sure the example app works both ways.

As for build-all, we could also do it twice - once with it disabled and once with it enabled?

[stuartmorgan]

So the example app builds with both the flag disabled (aka CocoaPods only) and enabled. I'm inclined to keep it this way so we can be sure the example app works both ways.

The problem is that adds about 5 minutes to each shard (a roughly 25-33% increase). If the only thing we get from that is coverage of an example app that almost nobody but us runs most of the time, and doesn't affect production clients, I don't think that's a good tradeoff of CI resources.

[vashworth]

Gotcha, then yeah I think we keep build-all using CocoaPods and do platform tests with SPM (because the example app has to be built with SPM so native tests use SPM).

[vashworth]

@stuartmorgan friendly ping

[stuartmorgan]

LGTM with one change.

[stuartmorgan]

This will explode on our stable tests (which you aren't seeing in presubmit because we only run native stable tests on post-submit to reduce CI utilization). You'll need to gate either the whole call, or just exiting on failure, on a Platform.environment['CHANNEL'] != 'stable' check for now, with a TODO to enable it for stable once the flag is available there.

[vashworth]

Oh good catch, done and validated: https://chromium-swarm.appspot.com/task?id=6929f2858af7f110

[stuartmorgan]

LGTM!