Removing plugin_ffi template

In the native assets we will create a way to bundle native code without the boilerplate code for every OS. Moreover, the packages with native assets will be regular Dart packages, removing the split between Dart packages and Flutter plugins with native code. (For example package:realm and package:realm_dart.)

Therefore, once we have support for native assets, the intention is to first deprecate and then remove the FFI plugin template.

Once native assets come out of experimental, we would mark the FFI plugin as deprecated, and subsequently remove it one or two Flutter versions later.

All the documentation and code labs that currently refer to FFI plugins need to be migrated in that time frame.

• https://docs.flutter.dev/platform-integration/ios/c-interop
• https://docs.flutter.dev/platform-integration/android/c-interop
• https://codelabs.developers.google.com/codelabs/flutter-ffigen

Potentially adding package_ffi template

Packages with native assets are much simpler than the FFI plugins due to having less boilerplate code (example). They are basically a

1. dart package,
2. with a pubspec.yaml dependency on https://pub.dev/packages/native_assets_cli and https://pub.dev/packages/native_toolchain_c,
3. a toplevel build.dart doing the native build,
4. an ffigen.yaml for the bindings, and
5. a src/some_c_code.c with the native code.

It could suffice to have this in dart create, instead of adding a template to flutter create. However, the downside would be that dart create would not have a flutter sample app invoking the native code. And this sample app working out of the box means that our users know the building/bundling works for the target OS/arch they are working on.

It could suffice to have this as a sample (both a package with native assets as well as an example app using it), instead of flutter create. The downside over a template would be that changing the name from the sample is error prone. (And checking out the sample with git clone is more work than running flutter create.)

The extra steps that users have to do also have to be duplicated in our documentation and code lab.

Since we are intending to remove flutter create -t plugin_ffi, maybe we should consider whether we should add flutter create -t package_ffi.

Context:

• Native assets support for MacOS and iOS #130494 (review)

cc @stuartmorgan @vashworth @zanderso