Flutter: Google's cross-platform SDK, and what you inherit when you adopt it

What Flutter actually replaces in your stack

Flutter is not a language and not a backend. It is a UI toolkit plus a rendering stack, shipped as an SDK, and the README frames it as "Google's SDK for crafting beautiful, fast user experiences for mobile, web, and desktop from a single codebase." The thing it removes is the per-platform view layer. Instead of writing a SwiftUI screen and a Jetpack Compose screen and keeping them in sync, you write one widget tree and Flutter draws it. The README also notes it works with existing code, which matters if you are adding a Flutter screen to an app that already has native screens rather than rewriting from zero. The audience is narrow in one respect: you have to be willing to write Dart. Everything above the rendering layer, including business logic, sits in Dart unless you cross into native through FFI or platform channels. Teams that want to keep their existing Kotlin or Swift domain code and only replace the view layer will find that boundary is where most of the integration work lives.

The rendering path: Skia, Impeller, and why the widget tree is the API

The mechanism the README describes is a layered architecture with its own compositor. Flutter draws through hardware-accelerated 2D graphics libraries, named in the README as Skia and Impeller, and the README claims the architecture supports "glitch-free, jank-free graphics at the native speed of your device." That is a design statement, not a measured result, and the README offers no numbers. What is concrete is the consequence: because Flutter owns the painting rather than delegating to platform widgets, the widget catalog is the primary API surface, with Material and Cupertino sets for the two dominant mobile idioms and support for custom or entirely new visual components. The README explicitly says the layered architecture gives "control over every pixel on the screen." That control is the product. It is also the reason a Flutter app does not automatically pick up a new platform control style when the OS updates; you get consistency across platforms at the cost of platform-native drift. Dart compiles to 32-bit and 64-bit ARM machine code for iOS and Android, to JavaScript and WebAssembly for the web, and to Intel x64 and ARM for desktop, per the README. One codebase, five compilation targets, and the same widget tree on each.

Installing Flutter and running a first app

The README does not carry install commands. It points at the get-started page: "Install Flutter" links to https://docs.flutter.dev/get-started. Follow that page for your platform; the repository itself is not the install path for most users. Two repository details are worth knowing before you start. There is a flutter_console.bat at the top level of the repository for Windows shells, and the tooling lives under bin/. The README also states a terms-of-service point that surprises people: the Flutter tool may download resources from Google servers, and when installed from GitHub rather than a prepackaged archive, it downloads the Dart SDK on first run because that SDK executes the flutter tool itself. The same download happens on flutter upgrade. In an air-gapped or heavily proxied build environment, that first-run fetch is the first thing that will fail. Once the SDK is on PATH, the standard entry point is the create command, which scaffolds a project directory with the platform runners already wired up. The repository ships examples/hello_world/ if you want to read a minimal project instead of generating one. For editor integration, the README lists plug-ins for Visual Studio Code and IntelliJ / Android Studio, so you do not need to work from a bare terminal. The daily loop is the hot reload feature the README highlights: "stateful hot reload, allowing you to make changes to your code and see the results instantly without restarting your app or losing its state." Preserving state across a reload is the part that changes how you work. You can adjust a layout while a form is half-filled and see the result without re-navigating to that screen. It is the single most cited reason people stay on the toolchain.

Where Flutter is the wrong tool

The rendering model is the limitation. Because Flutter paints its own widgets, an app that must look and behave exactly like a platform-native control, or that depends on a system component Flutter does not wrap, has to reach through platform channels or FFI. The README lists FFI support for Android, iOS, macOS and Windows, and platform channels generally, so the escape hatch exists and is documented. It is still an escape hatch, and each crossing is code you maintain per platform. The second constraint is release cadence. The recent releases in this repository are 3.19.0-0.1.pre, 3.18.0-0.1.pre and 3.17.0-0.1.pre, roughly monthly beta cuts, and the README links a breaking-changes page that tracks changes across releases. A framework that ships this often will move under you. If your organization pins dependencies for a year at a time, Flutter's upgrade treadmill is a real cost, not a theoretical one. The third case is size and scope. A small utility app, a CLI, or anything where a few megabytes of runtime for a screen or two is a bad trade should not start here. Flutter is also not a backend framework; the README describes it as a UI toolkit for platforms, and treating it as a server stack is a category error.

How it compares with React Native

The closest comparison for a cross-platform UI toolkit is React Native, and the difference is architectural rather than stylistic. React Native renders to platform-native views, so a button is the platform's button and inherits its look and its accessibility behavior. Flutter renders to its own canvas through Skia or Impeller, so a button is Flutter's button on every platform. That flips the trade-off. React Native gives you native fidelity by default and forces you to fight it when design wants something the platform does not offer. Flutter gives you identical output everywhere and forces you to fight it when the platform changes underneath you or when a native component has no Flutter equivalent. The language split follows: React Native keeps you in JavaScript or TypeScript, which most web teams already have, while Flutter requires Dart, which the README calls a "world-class" language but which is nonetheless a new hire skill for many teams. If your team is already deep in React and your app is mostly forms and lists, React Native has less friction. If your app is animation-heavy, or the design is the product and must be identical on iOS, Android, web and desktop, Flutter's own-rendering approach is the more direct route.

Licence, maintenance, and what upgrades cost

The repository is BSD-3-Clause, a permissive licence, and the repository also carries a PATENT_GRANT file. Permissive licensing means you can ship Flutter-built binaries without open-sourcing your app, but I am not giving legal advice and the patent grant is a separate document worth reading if patents are a concern in your sector. On maintenance: the repository is not archived, and the last push was on 2024-01-11. Given how long ago that is, the honest statement is that this snapshot does not show recent activity; anyone evaluating Flutter today should check the current state of the repository rather than relying on this record. The upgrade cost is documented rather than hidden. The tool downloads the Dart SDK on first run and again on flutter upgrade, and the README points to a breaking-changes page that accumulates across releases. Practically, that means budgeting time for each SDK bump, reading the breaking-changes list before upgrading, and pinning the SDK version in CI so that a build does not silently change under you. The package ecosystem is a second dependency surface: the README refers to "tens of thousands of packages" on pub.dev, and those packages carry their own maintenance schedules and their own upgrade lag when the SDK moves.

Editorial conclusion

Adopt Flutter if you own your rendering and can absorb a fast release cadence; avoid it if you need a thin binary or a slow-moving dependency. Before committing, read the breaking-changes page, confirm the tool's first-run download from Google servers is acceptable in your build environment, and check that your target platforms are listed in the README's platform set.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes