Flutter is Google's open-source toolkit for building applications for Android, iOS, web, Windows, macOS and Linux from a single codebase written in Dart. Its defining choice is that it does not wrap the host platform's native controls. Flutter ships its own rendering engine and paints every pixel itself, which is why an application looks and behaves identically across platforms and why its widgets are portable in a way that platform-bridging frameworks never quite achieve.
The architecture has three layers. A C++ engine handles rasterisation, text layout and platform channels. Above it sits the Dart framework — the foundation library, then the widget layer that developers actually work in. Everything in that layer is a widget: not just buttons and text, but padding, alignment, gesture detection and theming. Widgets are immutable descriptions of what the interface should look like for a given state, and the framework rebuilds the tree whenever that state changes. StatelessWidget and StatefulWidget cover the basic split; beyond them sit the state management approaches — setState, InheritedWidget, Provider, Riverpod, BLoC — that decide how an application scales past its first few screens.
Dart is what makes this work in both development and production. During development, the just-in-time compiler enables stateful hot reload, so a change appears in a running application in under a second with state preserved. For release, Dart compiles ahead of time to native ARM or x86 machine code on mobile and desktop, and to JavaScript or WebAssembly on the web. Flutter is therefore genuinely compiled rather than interpreted at runtime, which is the source of most of its performance argument.
Why this skill matters now
Building the same application twice — once in Kotlin and once in Swift — is a cost most organisations have stopped being willing to pay. A single codebase halves the feature backlog, removes an entire class of behavioural divergence between platforms, and lets one team own the product rather than two teams negotiating parity.
Flutter has become the default answer to that problem for a large share of new mobile work. It is used across consumer applications, internal enterprise tools, kiosk and point-of-sale software, and increasingly desktop utilities, and its package ecosystem now covers the integrations that used to force teams back to native code. The demand shows up as a specific role — a Flutter developer expected to ship to both stores, not a mobile generalist.
The skills gap is in the second half of the work. Laying out a screen is quick to learn; what organisations hire for is state management that survives a growing application, correct asynchronous handling, integration with real backends and native platform code, performance work against jank and rebuild cost, testing at the widget and integration level, and a release pipeline that produces signed store artifacts reliably.