Flutter in production: what the tutorials leave out

01The plugin boundary is where risk lives

Anything that touches the platform - camera, biometrics, payments, Bluetooth, a vendor SDK - goes through a plugin. When a well-maintained plugin exists, this is invisible. When it does not, you are writing platform channel code in Swift and Kotlin, which means you now need the native expertise Flutter was supposed to spare you.

Audit plugins for the SDKs you actually need before committing. Check the last release date, open issue count and whether the maintainer is one person. A plugin that has not shipped since the last major Flutter release is a liability, not a dependency.

The realistic mitigation is to wrap third-party plugins behind your own interface so replacing one is a contained change rather than a search across the codebase.

02Things that surprise teams

None of these are dealbreakers, but each has caught teams late enough to hurt.

• Binary size starts larger because the engine ships with the app. It matters for markets with expensive data and for install conversion.
• Text rendering and accessibility are Flutter's implementations, not the platform's. They are good and they are not identical, and screen-reader behaviour differs in ways only testing reveals.
• Platform-native look requires deliberate work. Flutter will happily render Material widgets on iOS, which users read as wrong.
• Web builds are real but are not a way to share a codebase with an existing web app; output size and SEO make it unsuitable for public marketing surfaces.
• Hot reload does not cover everything - state changes and native code still need full restarts, and the difference confuses new teams.

03Performance in practice

Flutter is fast by default and slow in specific, learnable ways. The common culprits are rebuilding large widget subtrees on every state change, expensive work in build methods, and unbounded lists rendered without recycling.

The tooling here is good. The widget rebuild profiler will show you exactly which subtrees rebuild and how often, and most performance complaints resolve to a state change scoped too widely.

Jank on scroll is nearly always image decoding or synchronous work on the UI isolate. Move real computation to a background isolate; the model is explicit and works well once teams stop treating Dart as single-threaded by necessity.

04When Flutter is the right call

Flutter fits when your design is a custom brand language rather than platform-native, when the team has no existing React investment, and when your platform integration surface is small and well covered by mature plugins.

It fits less well when you need deep platform integration, when you want to share code with a React web app, or when hiring locally for Dart is genuinely hard. Those are the constraints that decide it - not the framework's quality, which is not in question.