flutter-plugins▌
flutter/skills · updated Apr 8, 2026
Scaffolds Flutter plugins with native interop, method channels, FFI integration, and federated architectures.
- ›Generates standard plugins, FFI plugins, or federated multi-package architectures based on native code requirements and team structure
- ›Configures Android v2 embedding lifecycle interfaces, platform-specific native environments (Kotlin/Java, Swift/Objective-C), and method channel registration
- ›Implements package-separated federated plugins with app-facing and platform-specific
flutter-plugin-generator
Goal
Scaffolds and configures Flutter plugin packages, handling standard method channels, FFI integrations, and federated plugin architectures. It configures platform-specific native code environments, implements Android v2 embedding lifecycle interfaces, and establishes platform interface packages.
Decision Logic
Use the following decision tree to determine the plugin architecture and template:
- Does the plugin require C/C++ native code via
dart:ffi?- Yes: Use
--template=plugin_ffi.- Note: FFI plugins support bundling native code and method channel registration, but not method channels themselves.
- No: Proceed to step 2.
- Yes: Use
- Does the plugin require BOTH
dart:ffiand Method Channels?- Yes: Use
--template=plugin(Non-FFI). You must configure FFI manually within the standard plugin structure. - No: Proceed to step 3.
- Yes: Use
- Will the plugin be developed by multiple teams or require highly decoupled platform implementations?
- Yes: Implement a Package-Separated Federated Plugin (App-facing package, Platform Interface package, Platform Implementation packages).
- No: Implement a standard monolithic plugin.
Instructions
-
Gather Plugin Requirements STOP AND ASK THE USER:
- What is the plugin name?
- What is the organization name (reverse domain notation, e.g.,
com.example)? - Which platforms should be supported (comma-separated:
android,ios,web,linux,macos,windows)? - Do you need an FFI plugin or a standard Method Channel plugin?
- Do you prefer Java or Kotlin for Android? Objective-C or Swift for iOS?
- Should this be a federated plugin?
-
Generate the Plugin Package Execute the Flutter CLI command based on the user's parameters.
Standard Plugin Example:
flutter create --org com.example --template=plugin --platforms=android,ios,macos -a kotlin -i swift my_pluginFFI Plugin Example:
flutter create --template=plugin_ffi my_ffi_plugin -
Configure Federated Plugin Architecture (If Applicable) If the user requested a federated plugin, configure the
pubspec.yamlof the app-facing package to endorse the platform implementations.# App-facing pubspec.yaml flutter: plugin: platforms: android: default_package: my_plugin_android windows: default_package: my_plugin_windows dependencies: my_plugin_android: ^1.0.0 my_plugin_windows: ^1.0.0For the platform implementation packages, define the
implementskey:# Platform implementation pubspec.yaml (e.g., my_plugin_windows) flutter: plugin: implements: my_plugin platforms: windows: pluginClass: MyPlugin -
Prepare Native Environments for Editing Before modifying native code, you MUST build the example app to resolve dependencies and generate necessary files.
cd my_plugin/example flutter build apk --config-only # For Android flutter build ios --no-codesign --config-only # For iOS flutter build windows # For Windows -
Implement Android v2 Embedding Lifecycle Modify the Android plugin class (e.g.,
android/src/main/kotlin/com/example/my_plugin/MyPlugin.kt). Extract logic fromregisterWith()into a private method shared withonAttachedToEngine(). ImplementActivityAwareorServiceAwareif context is needed.package com.example.my_plugin import androidx.annotation.NonNull import io.flutter.embedding.engine.plugins.FlutterPlugin import io.flutter.embedding.engine.plugins.activity.ActivityAware import io.flutter.embedding.engine.plugins.activity.ActivityPluginBinding import io.flutter.plugin.common.MethodCall import io.flutter.plugin.common.MethodChannel import io.flutter.plugin.common.MethodChannel.MethodCallHandler import io.flutter.plugin.common.MethodChannel.Result class MyPlugin: FlutterPlugin, MethodCallHandler, ActivityAware { private lateinit var channel : MethodChannel override fun onAttachedToEngine(@NonNull flutterPluginBinding: FlutterPlugin.FlutterPluginBinding) { setupChannel(flutterPluginBinding.binaryMessenger) } // Shared private method for v1 and v2 embedding compatibility private fun setupChannel(messenger: BinaryMessenger) { channel = MethodChannel(messenger, "my_plugin") channel.setMethodCallHandler(this) } override fun onMethodCall(@NonNull call: MethodCall, @NonNull result: Result) { if (call.method == "getPlatformVersion") { result.success("Android ${android.os.Build.VERSION.RELEASE}") } else { result.notImplemented() } } override fun onDetachedFromEngine(@NonNull binding: FlutterPlugin.FlutterPluginBinding) { channel.setMethodCallHandler(null) } override fun onAttachedToActivity(binding: ActivityPluginBinding) { // Handle Activity attachment } override fun onDetachedFromActivityForConfigChanges() {} override fun onReattachedToActivityForConfigChanges(binding: ActivityPluginBinding) {} override fun onDetachedFromActivity() {} } -
Validate and Fix Run the plugin tests and analyzer to ensure the generated code is valid.
cd my_plugin flutter analyze flutter testIf the analyzer reports missing dependencies or unresolved native symbols, verify that step 4 (building the example app) was executed successfully. Fix any missing imports in the native code blocks.
Constraints
- Never attempt to use Method Channels inside a package created with
--template=plugin_ffi. If both are required, use--template=plugin. - Always build the example project (
flutter build <platform>) at least once before attempting to edit or analyze native Android (build.gradle), iOS (.xcworkspace), or Windows (.sln) files. - Never leave public members undocumented in the Dart API (
lib/<package_name>.dart). - Always use the v2 Android embedding (
FlutterPlugin). Do not rely solely on the deprecatedPluginRegistry.Registrar. - Never edit the
.androidor.iosdirectories inside a Flutter module; only edit the native code inside the plugin'sandroid/orios/directories.
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.5★★★★★69 reviews- ★★★★★Hassan Jackson· Dec 24, 2024
flutter-plugins has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★William Robinson· Dec 20, 2024
Solid pick for teams standardizing on skills: flutter-plugins is focused, and the summary matches what you get after install.
- ★★★★★Hassan White· Dec 16, 2024
We added flutter-plugins from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Soo Bansal· Dec 8, 2024
Useful defaults in flutter-plugins — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★William Park· Dec 8, 2024
flutter-plugins fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- ★★★★★Ama Perez· Nov 27, 2024
flutter-plugins has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Chinedu Mensah· Nov 27, 2024
flutter-plugins is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
- ★★★★★Diya Thompson· Nov 15, 2024
Useful defaults in flutter-plugins — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Aisha Brown· Nov 11, 2024
I recommend flutter-plugins for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Hassan Srinivasan· Nov 7, 2024
Keeps context tight: flutter-plugins is the kind of skill you can hand to a new teammate without a long onboarding doc.
showing 1-10 of 69