Currently for Swift we conditionally import either Flutter (iOS) or FlutterMacOS (macOS), but for Objective-C we always just import Flutter. This was deliberate since technically Swift is the only supported language for macOS plugins, but that's a largely irrelevant distinction; the module-based plugin builds that we use on macOS mean that plugins using Obj-C just works, and we in fact use it in several 1P plugins where we share implementations between iOS and macOS and haven't converted to Swift yet.

AFAICT the only thing we need for generated code to work on macOS is the conditional import.

This will be a blocker for adding macOS support to webview_flutter_wkwebview (unless we port the top layer of that plugin to Swift first). I can see a few options here:

1. Make the support opt-in and semi-hidden, continue to not advertise it as supported, and don't set up e2e tests for Obj-C macOS.
2. Make the support automatic, but don't advertise it or set up the e2e tests.
3. Make the support automatic, set up e2e tests, and consider it fully supported.

The problem with 1 is that it's more complexity in the API than 2 or 3. I think in the current test setup adding tests wouldn't actually be that hard, in which case we should probably do 3 if we're going to use it, but if it turns out to be non-trivial we can reconsider.