Flutter: One Dart Codebase for Mobile, Web, and Desktop

What Flutter Actually Solves

Flutter addresses the cost of building the same user interface for multiple platforms. Instead of maintaining separate Swift, Kotlin, and JavaScript codebases, you write once in Dart and compile to native machine code for iOS and Android, JavaScript or WebAssembly for the web, and Intel x64 or ARM for Windows, macOS, and Linux. The target audience is teams that need a consistent visual experience across those surfaces without hiring per-platform UI specialists. It is not for developers who want to reuse an existing web stack, because Dart is a distinct language. The README positions it as a tool for 'crafting beautiful, fast user experiences,' which is marketing, but the concrete claim is that you control every pixel and can animate graphics, video, text, and controls without framework-imposed limits.

The Rendering Architecture: Skia and Impeller

Flutter's rendering is built on hardware-accelerated 2D graphics libraries. The README names Skia, which also underpins Chrome and Android, and Impeller, which is the newer engine. The README says Flutter was architected to support glitch-free, jank-free graphics at the native speed of your device. The key architectural point is that Flutter does not rely on the platform's native widget toolkit. It draws every frame itself, which is why the same UI can look identical on iOS and Android. That gives pixel-perfect control, but it also means the engine must compile shaders and manage the graphics pipeline directly. The README does not say which platforms use Impeller or Skia, so you must check the documentation.

Getting Started: Installation and First Run

The README points to the official install guide at https://docs.flutter.dev/get-started, but it also reveals a critical detail about the setup process. If you install from the GitHub repository rather than a prepackaged archive, the Flutter tool downloads the Dart SDK from Google servers on first run. That happens because the `flutter` command itself is a Dart script. The same download occurs when you run `flutter upgrade`. This means the SDK is not self-contained out of the box; it depends on Google's infrastructure for the initial bootstrap. After installation, you typically create a project with `flutter create`, run it with `flutter run`, and use `flutter build` to produce platform-specific binaries. The README does not list these commands explicitly, but they are standard for Flutter. The terms of service section is a reminder that using the tool implies agreement to Google's terms, which is a licensing consideration for enterprise deployments.

Hot Reload and the Development Loop

Flutter's stateful hot reload is the feature that most directly affects developer productivity. The README describes it as allowing you to make changes to code and see results instantly without restarting the app or losing its state. That is a concrete mechanism: the Dart virtual machine injects updated code into a running app, preserving the widget tree and any in-memory state. For UI iteration, this is a genuine advantage over native development, where rebuild cycles are slower. However, hot reload has limits. It does not work for all changes, such as altering native platform code or modifying the app's `main()` function. The README does not document these exceptions, but they are known constraints. If your work involves heavy native integration, you will still spend time on full rebuilds. The feature is a strong reason to choose Flutter for UI-heavy projects, but it is not a cure-all for the entire development cycle.

Integration with Native Code: FFI and Platform Channels

Flutter does not isolate you from the underlying platform. The README lists two mechanisms for reaching native code: FFI (Foreign Function Interface) and platform channels. FFI is available on Android, iOS, macOS, Linux, and Windows, and it lets you call C or C++ libraries directly from Dart. Platform channels are for invoking platform-specific APIs, such as camera or sensors, by sending messages between Dart and native code. This is a pragmatic design: you get the cross-platform UI, but you can still drop into native code when needed. The trade-off is that every platform channel or FFI binding is code you must maintain per platform, which erodes the single-codebase benefit. For a simple app, you may never need it. For a complex app with heavy native dependencies, you will write and test Swift, Kotlin, or C++ code anyway. The README's example repository is `examples/platform_channel`, which shows the pattern, but it does not explain how to handle asynchronous native calls or error propagation.

Real Limitations and Failure Modes

Flutter is not the right tool for every project. The most obvious limitation is the language barrier: Dart is not JavaScript, Swift, or Kotlin, so teams must learn it or hire for it. The README's claim of 'tens of thousands of packages' on pub.dev suggests a large ecosystem, but package quality varies, and you cannot assume a native library's Dart wrapper exists. Another failure mode is the rendering engine transition. Skia and Impeller behave differently, and the README does not state which platforms use which engine. If you ship an app that relies on Skia-specific shader behavior, upgrading to Impeller could change visual output or performance. The terms of service also introduce a compliance risk: the SDK downloads resources from Google servers, which may be blocked in some corporate networks or regions. Finally, the README does not mention offline build support, so a fully air-gapped environment would struggle to install the SDK or fetch dependencies.

Comparing Flutter to React Native

The main alternative to Flutter is React Native, which also builds cross-platform mobile apps from a single codebase, but the approach differs fundamentally. React Native uses JavaScript and React, and it maps components to native UI widgets, so the app feels native but the rendering is delegated to the platform. Flutter draws everything itself with Skia or Impeller, which gives it more visual consistency but also means it does not use the platform's native controls. That difference matters for accessibility and platform-specific behaviors. React Native apps often inherit native look-and-feel automatically, while Flutter apps must implement Cupertino or Material widgets explicitly to match platform conventions. In terms of performance, Flutter compiles Dart to ARM machine code, whereas React Native interprets JavaScript with a bridge, which historically caused performance bottlenecks. The README does not compare the two, but the architectural choice is clear: Flutter trades native widget fidelity for rendering control. If your team already knows JavaScript, React Native has a lower learning curve, but if you need pixel-perfect cross-platform design, Flutter's approach is more direct.

Maintenance and Upgrade Costs

Flutter's maintenance burden is tied to its release cadence. The releases listed on GitHub are beta tags (3.19.0-0.1.pre on 2024-01-11, 3.18.0-0.1.pre on 2023-12-12 and 3.17.0-0.1.pre on 2023-12-11), none newer than January 2024, while the repository itself was last pushed on 2026-11-02. The README points to a dedicated breaking changes page at https://docs.flutter.dev/release/breaking-changes. Check that page before upgrading, since it tracks breaking changes across releases. The `flutter upgrade` command triggers a new Dart SDK download, so every upgrade has a network and time cost. The license is BSD-3-Clause, which is permissive and allows commercial use, but the terms of service add Google-specific conditions for SDK downloads. That is a subtle distinction: the code is open source, but the tool's default behavior involves Google servers. For long-term maintenance, you also need to track Impeller's maturation, because the engine switch could affect rendering behavior in ways that require visual regression testing. The README does not provide a migration guide, so you must rely on the documentation site.

Editorial conclusion

Adopt Flutter if you need pixel-level control across mobile, web, and desktop from one Dart codebase and can accept the Google-hosted SDK download on first run. Do not adopt it if your team is already deeply invested in native iOS or Android tooling, or if you require a fully offline SDK installation. Before committing, verify your target platforms and rendering path against the Flutter documentation, and check the breaking changes list for each version upgrade.

Frequently asked questions

Official sources

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