We are using webview_flutter as a trial run for a different approach to plugin implementations, based on previous proposals by @bparrishMines, https://docs.flutter.dev/go/platform-channels-in-federated-plugins, and various related discussions. The plan is to move from the current model of a single platform channel that mirrors the platform interface, to Pigeon-based platform channels that mirror each OS's APIs, with adapter logic (between the platform interface and the OS APIs on each platform) written in Dart. The goals are to:

• Implement https://docs.flutter.dev/go/platform-channels-in-federated-plugins for webview_flutter.
• Evaluate whether Pigeon is ready for us to make it the standard way of writing 1P plugins (and if not, to evaluate what more is needed).
• Evaluate the model of having the platform channel mimic the OS APIs, also as a potential standard way of writing 1P plugins. The hypothesis is that this will:
  • Make maintenance easier due to having more code in a single shared language.
  • Make testing easier since more code can be tested via Dart unit tests, rather than the much slower and more cumbersome native unit tests.
  • Make adding platform-specific extensions easier.
• Create a test case for evaluating future proposals that would ease the process of mirroring native APIs to Dart.

This is being done as a single change because the two steps—implementing in Pigeon, and moving the channel boundary—each involve completely rewriting the platform channels, so separating them would involve a significant throwaway work, and because our strong expectation is that this is the model we will want to move to, so it's unlikely that we would get any value from testing only one. (Also, it's not clear that we would get as much of a useful stress test of Pigeon by migrating the existing method channel.)

webview_flutter was chosen because it is a high-complexity and high-PR-volume plugin. That means we will get more information from the initial rewrite, and will have many PRs as a comparison to see how it affects our ability to maintain the plugin.

Steps:

• Rework Android
• Rework iOS