Allow directly sharing iOS and macOS plugin native code

[stuartmorgan]

See previous discussion in #52285. At that time the decision was to use symlinks, but that's kind of a pain due to dart-lang/pub#3143, which means all files have to be symlinked, rather than the directories (which wasn't true when the decision was made initially). For non-trivial plugins that can be a lot of files (e.g., in_app_purchase).

I'd need to look at the logic again, but I think it would be plausible to have a pubspec.yaml entry in the platform section that would allow opting into a shared directory instead of the currently hard-code ios or macos. If it's not too much complexity, I think the maintenance benefits for plugins would be worth the effort.

See also #114179

(/cc @jmagman for thoughts)

[jmagman]

At least on the tool side I don't think it would be too difficult.

Would need to handle all the IOSPlugin and MacOSPlugin usage and make a... DarwinPlugin?

flutter/packages/flutter_tools/lib/src/flutter_plugins.dart

Lines 1209 to 1215 in b31b9dc

	final List<String> platforms = <String>[
	AndroidPlugin.kConfigKey,
	IOSPlugin.kConfigKey,
	LinuxPlugin.kConfigKey,
	MacOSPlugin.kConfigKey,
	WindowsPlugin.kConfigKey,
	];

flutter-plugins-dependencies would have to create a new darwin key, for the projects to handle:

flutter/packages/flutter_tools/lib/src/xcode_project.dart

Line 105 in 378387b

String get pluginConfigKey => IOSPlugin.kConfigKey;

flutter/packages/flutter_tools/lib/src/xcode_project.dart

Line 553 in 378387b

String get pluginConfigKey => MacOSPlugin.kConfigKey;

And then the podhelper needs to know about the new key when parsing flutter-plugins-dependencies:

flutter/packages/flutter_tools/bin/podhelper.rb

Line 292 in 3c9288c

dependencies_hash['plugins'][platform] || []

I'm sure I'm forgetting some places.

[hellohuanlin]

this can be part of effort of swift migration for path_provider/shared_preferences/url_launcher plugins, as discussed in the swift migration doc

[jmagman]

The pubspec would also need to support a darwin field, and pub would need to be taught that it means iOS and macOS are supported.

[stuartmorgan]

The pubspec would also need to support a darwin field, and pub would need to be taught that it means iOS and macOS are supported.

I was thinking that rather than a new platform field, it would be a new subfield. Something like:

flutter:
  plugin:
    iOS:
      pluginClass: Foo
      sharedDarwinSource: true
    macOS:
      pluginClass: Foo
      sharedDarwinSource: true

That way we aren't conflating conceptual platforms with the directories.

If we do that, it's entirely local to Flutter, with no pub.dev changes needed.

[jmagman]

Adding just that key is easier. Got it working in draft PR #115337, it needs an end-to-end integration test.

sharedDarwinSource concept maybe needs a design doc? Or maybe this issue and that PR are sufficient to get sign off from stakeholders (you me and... @cbracken?).

Also requires documentation updates:
https://docs.flutter.dev/development/packages-and-plugins/developing-packages#step-2c-add-ios-platform-code-swifthm
https://docs.flutter.dev/development/packages-and-plugins/developing-packages#step-2e-add-macos-platform-code-swift

[cbracken]

Agreed this seems like a pretty sensible approach for code that's common across both platforms (i.e. not UIKit or AppKit specific).

You could imagine cases where there's some shared Darwin code but also some AppKit or UIKit code; in such a case we'd want to support shared Darwin code in darwin and the specific bits under a macos/ios directory.

[stuartmorgan]

in such a case we'd want to support shared Darwin code in darwin and the specific bits under a macos/ios directory

Pods don't allow references outside of the pod root, so that gets to be problematic. My thought was that if enough is common that you're using using sharedDarwinSource, you just put your macOS- and iOS-specific bits in the darwin directory, separated out however you want (subdirs, file naming convention, etc.)

[stuartmorgan]

sharedDarwinSource concept maybe needs a design doc?

Finally got back to this: https://flutter.dev/go/plugin-shared-ios-macos

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.