Pigeon improves the ease and safety of plugin development, and we've been having good experiences switching our plugins over to it as Pigeon has continued to mature and stabilize:

• It eliminates bad-cast errors, where we make a mistake in the manual synchronization of expected types across the language boundary, including (in some languages) nullability mistakes in most cases.
  • It avoids the need to try to validate that contract in review, switching between the Dart and host code trying to see if all of the pieces line up as expected; instead the API definition can be easily reviewed, and then the implementations using that API can be reviewed in isolation, which is far easier.
• It avoids the need to manage a bunch of string constants across languages.
• It avoids a lot of tedious boilerplate for dictionary extraction to get individual arguments (and in ObjC, much of the need for annoying special-case handling of NSNull).

While it still has some limitations that we may want to address before adopting it in specific cases (e.g., we may want to implement an instance-tracking system before applying it to things like camera or maps, rather than having to build multiplexing in the API itself), in general we should plan to migrate all of our plugins to Pigeon.

This serves as a central tracking point, and explanation for the motivation for these migrations for future repo archeology. Plugin migrations are tracked in individual issues:

• camera
• file_selector
• google_maps_flutter
• google_sign_in
• image_picker
• in_app_purchase
• ios_platform_images
• local_auth
• path_provider
• quick_actions
• shared_preferences
• url_launcher