We have some plugins that have separate macOS and iOS plugin implementations only because at the time macOS support was added, the decision was that only Swift was officially supported for macOS (even though ObjC did and does work because of module interop) for simplicity of things like plugin templates. We wanted examples of plugins that followed our official recommendations, but the policy for iOS 1P plugins was to only use Obj-C.

Having them be separate now that we're allowing Swift iOS 1P plugins no longer serves any purpose, and is just overhead to maintaining two plugins. It's minimal overhead since the plugins in question are small and don't change frequently, but there's still no reason for it. Other benefits:

• It would be good to have 1P examples of shared Swift plugins as that's expected to be a pretty common case in the ecosystem.
• Adopting/demonstrating Allow directly sharing iOS and macOS plugin native code #115085 once it lands.
• Eliminating the need for an eventual rewrite of existing iOS implementations in Swift (since we expect that in the long term most or all 1P plugin development will be in Swift).

Plugins to merge:

• shared_preferences: shared_preferences_macos should add iOS support and be renamed shared_preferences_foundation. shared_preferences_ios and the existing shared_preferences_macos should be discontinued on pub.dev, and shared_preferences_ios removed from the repo.
  • We should do the macOS part of [shared_preferences] Convert to Pigeon #117914 before doing this since iOS has been converted to the structure we want but macOS hasn't.
  • We should ideally do this before doing Allow setting prefix in shared preference - for migrating from old app that did not use flutter #52544 (comment) so we aren't doing the native part of that work twice (cc @tarrinneal since we've discussed that project).
• path_provider: same set of changes here.
  • As above, we should do the macOS part of [path_provider] Convert to Pigeon #105735 first.

(cc @jmagman @hellohuanlin since this has come up in discussion, but I don't think we've filed it. It probably makes the most sense for me to do this since I'm familiar with some of the pitfalls in the mechanics of renaming a package for sharing.)