Flutter Platform Integration

Prefer an existing maintained plugin when it meets the requirement. Write platform code when the capability is unavailable, product-specific, or requires a controlled native contract.

When asked to replace an adequate plugin the project already uses with custom native code, do not write the native code yet. Name what the current plugin already covers, ask which concrete requirement it fails (missing API, platform, behavior, license, or size), and recommend keeping it until that gap is known. When the gap is real, close it with the smallest change: a Dart wrapper, an upstream fix, or a narrow channel for the missing part only.

Choose the boundary

• Use a package API for established cross-platform capabilities.
• Use Pigeon or another typed generated contract when a multi-method channel benefits from compile-time structure.
• Use a basic method/event channel for small, stable request/response or event surfaces.
• Use FFI for suitable native C-compatible libraries and performance-sensitive calls.
• Use platform views only when native view embedding is required and account for composition, gestures, accessibility, and performance.

Keep domain models outside the channel contract. Version or evolve messages compatibly, validate all values at the boundary, and map platform failures into actionable Dart errors.

Load references conditionally