Platform Channels And Plugins
Platform integration is where Flutter stops being purely shared Dart.
Channel Discipline
For app-owned platform code:
| Concern | Rule |
|---|---|
| Channel names | Use stable names like app.example/notifications |
| Method names | Treat them like public API once released |
| Arguments | Validate shape and nullability on Dart and host sides |
| Errors | Convert platform errors into typed app failures |
| Threading | Follow documented main-thread/background-isolate guidance |
| Tests | Fake the Dart service and smoke the platform implementation |
Plugin Discipline
Prefer plugin packages for reusable platform capability. Prefer app-local platform channels for narrow app-specific calls. Prefer Pigeon when hand-maintained method strings become error-prone.
Federated Plugins
Federated plugins split interface and implementation packages. This is useful for package authors and broad platform support, but app developers must verify that every target has an implementation.
FFI
Use FFI when the value is a native C-compatible library, not ordinary platform UI. FFI moves complexity into build, bundle, ABI, and signing concerns.
Gotcha: Platform code expands the test matrix. Android passing does not prove iOS, desktop, or web behavior.