â ï¸ _This PR does not update packages' versions as it only affects unpublished parts of example apps and tests._
We added `use_modular_headers!` to our `Podfile`s as we originally planned to phase out `use_frameworks!` (see https://github.com/flutter/flutter/pull/42204). However, our plans have now changed and we are instead phasing out CocoaPods entirely in favor of Swift Package Manager.
CocoaPods's `use_frameworks!` and `use_modular_headers!` are two different overlapping options that should not be used together. This change removes the `use_modular_headers!` from example apps' `Podfile`s. This change does not affect packages themselves.
Part of https://github.com/flutter/flutter/issues/156259
macOS privacy manifest enforcement is rolling out soon, so this brings all macOS plugins into alignment with our iOS policy of always having a manifest, including updating the repo tooling to enforce that.
Very few plugins are affected because most share the implementation package with iOS, and we didn't do any target platform switching when adding the manifests for iOS, automatically covering macOS as well.
Fixes https://github.com/flutter/flutter/issues/155564
Converts native unit tests from Objective-C to Swift, as a first step toward an eventual plugin conversion. Since OCMock usage was removed in a previous PR, the tests are converted essentially directly (the rewrites were largely mechanical syntax replacement), without any changes needed to production code.
There are a few places where interacting with the Pigeon-generated Obj-C is somewhat awkward because the NSError signature isn't auto-converting to `throw` in cases where we use `NSNumber` wrapping, but all that will get cleaned up when we switch the plugin over to Swift Pigeon generation and have idiomatic Swift APIs that the tests will be calling instead.
Fixes a couple of false positives in the repo tooling surfaced by this PR:
- `darwin/Tests/` wasn't recognized as a test directory.
- Swift tests weren't recognized as exempt from requiring Swift entries in the podspec.
Part of https://github.com/flutter/flutter/issues/119104
Usually when an iOS plugin uses Swift files, it requires a workaround in the podspec to add Swift to the search paths. Part of the `podspec-check` command is validating this workaround is found. However, when the only Swift file is the `Package.swift` (Swift Package Manager manifest), skip this validation since having this file does not indicate the plugin uses Swift files.
Fixes https://github.com/flutter/flutter/issues/147548.
Reverts: flutter/packages#6416
Initiated by: ditman
Reason for reverting: Failures happen (later) in other plugins (more updates in the related issue)
https://github.com/flutter/flutter/issues/145866
Original PR Author: ditman
Reviewed By: {jmagman}
This change reverts the following previous change:
Adds `--allow-warnings` to podspec_check_command.dart so stuff can keep rolling.
**To be removed soon!**
Adds privacy manifests to all iOS plugins.
While we only *need* to do the plugins listed [here](https://developer.apple.com/support/third-party-SDK-requirements/) for now, the wording of the page:
> The following are commonly used SDKs in apps on the App Store
suggests that the list of things for which this is required is just an arbitrary cutoff rather than a conceptual distinction, so it seems safest to just assume the list will grow over time and do all of them. To ensure that, this includes new repo tooling to check that a manifest is specified in the podspec.
The large caveat is that we do not currently know if this actually works. This is the method of inclusion that seems to be [the consensus among people using Cocoapods](https://github.com/CocoaPods/CocoaPods/issues/10325), as bundling it directly as a `resource` causes problems for clients who do not use `use_frameworks`. (In theory it seems like a manifest would not actually be *required* in that case since there is no framework, but it has the potential to actually stomp top-level resources.) Hopefully the automated analysis that Apple will eventually roll out will tolerate the file being bundled in a resource bundle in the framework rather than a top-level manifest file. If not, however, it's not clear how Cocoapods can be supported, so we can adopt this common approach for now under the assumption that eventually tooling will adapt to the reality of the ecosystem, and revisit the exact bundling later if necessary.
Only `shared_preferences` has a non-empty manifest, as it is our only plugin that uses a required reason API, and none of our plugins themselves collect private data. Ideally for that plugin we would instead use `C56D.1`, which is for wrappers, but as currently written we can't use it since it's exclusively a wrapper. If that changes in the future based on our pending request, we can revisit. For now, however, this reason should suffice since we don't currently allow reading from other app groups.
Fixes https://github.com/flutter/flutter/issues/131495
Fixes https://github.com/flutter/flutter/issues/139756
Fixes https://github.com/flutter/flutter/issues/139757
Fixes https://github.com/flutter/flutter/issues/139758
Fixes https://github.com/flutter/flutter/issues/139759
Fixes https://github.com/flutter/flutter/issues/139760
See also https://github.com/flutter/flutter/issues/139761
The Flutter build process creates podspecs that are just shims pointing to the local Flutter framework, and which don't pass the linter since they aren't intended for publishing. When finding podspecs to lint, skip those.
This avoids incorrect failures when running on a tree that isn't clean (in particular, where macOS and/or iOS builds have happened), which is very common locally.
Updates links and references to `flutter/plugins` to use `flutter/packages` instead, including making the `repository` pubspec.yaml check stricter in the repo tooling to ensure all packages are pointing to the right place.
Exceptions to the updates are:
- Changelog entries.
- Links to pull requests.
This will re-publish all the moved plugins, thus fixing the current redness of `release` (due to the current versions not being tagged in this repository).
