4Developers Wrocław 2019: The Many Faces of Flutter [ENG], Krzysztof Sroka

### Overview At 4Developers Wrocław 2019, front-end engineer and community organizer Krzysztof Sroka presented on Flutter and the realities of multi-platform development. Having transitioned to full-time Flutter development in early 2019 and organizing the Flutter Europe conference, Sroka examined the history, architecture, compilation model, and platform reach of Google's UI SDK beyond its standard mobile targets.

### Architecture and Compilation Flutter is structured like an onion across multiple distinct layers: - **Dart Framework**: The uppermost layer where developers compose UI widgets, manage animations, and interact with foundation libraries. - **C++ Engine**: Handles frame composition, rendering, and core subsystems beneath the Dart layer. - **Embedder**: The lowest level interfacing with the host operating system, managing threads, event loops, and render surfaces.

Flutter relies on Dart, combining elements of JavaScript, Java, and Swift. It uses two execution modes: Just-In-Time (JIT) compilation during development to power stateful hot reload, and Ahead-Of-Time (AOT) compilation for release builds, which produces native machine code and strips out debugging checks via tree-shaking.

To communicate with host platforms, Flutter historically used **Platform Channels**, an asynchronous message-passing interface between Dart and native code (Java/Kotlin on Android, Objective-C/Swift on iOS). While suitable for API calls like querying battery level, it is not fast enough to pipe high-framerate full-screen animations. More recently, Flutter introduced the **Foreign Function Interface (FFI)** in developer builds, enabling direct native calls to C/C++ libraries without message serialization overhead.

### Platform Support - **Mobile**: Android and iOS are fully supported. Community members have experimented with Wear OS, watchOS, and Android TV, but run into limitations such as a lack of circular screen support on wearables (treating them as square viewports) and missing TV-specific integrations. - **Desktop**: macOS, Windows, and Linux are in varying stages of development. macOS currently offers the most mature tooling (including debug runs and hot reload), whereas Linux relies on a thin OpenGL wrapper and Windows support remains nascent. Desktop targets are in Developer Preview without stable APIs or ABI guarantees, lack brownfield embedding support, and rely on system default fonts unless specific TTF files are bundled. - **Web**: Originally developed as a fork before merging into mainline Flutter, Flutter Web compiles to a browser layer relying on HTML5 Canvas for non-text rendering, DOM text elements, and JavaScript. At the time of the talk, web lacked hot reload (supporting only hot restart), FFI, plugins, and local file system access, with official debugging limited to Chrome. - **Google Fuchsia**: Fuchsia is an open-source operating system built by Google on a custom microkernel rather than Linux. Flutter is positioned as Fuchsia's primary UI SDK, indicating that Flutter applications written today may natively target Fuchsia in the future.

### Takeaways While mobile Flutter support is robust and capable of sustained 60 to 120 FPS rendering, it does not eliminate the need for platform-specific engineers. Business expectations that cross-platform frameworks allow companies to disband dedicated iOS and Android teams are unrealistic because platform integrations, native SDK wrappers, and platform quirks (e.g., iOS certificate management, autofill, map/webview integrations) still require native platform expertise. Across non-mobile platforms, Flutter shows promise but remains largely experimental, with Google prioritizing web over desktop targets.