Flutter Native rendering path
The runtime uses OpenGL when the host Qt Quick scene graph supports it, with a software path as a controlled fallback. That gives teams a practical route from development machines to real ARM panels.
Flutter Embedded UI engineering
Flutter for embedded Linux HMIs, without giving up product control
Flutter is attractive when a product should feel like one app family across iOS, Android and the device HMI. On embedded Linux, however, somebody has to own the runtime around the app: rendering, input, lifecycle, packaging, diagnostics and kiosk operation. hexDEV built that missing product layer as an independent Flutter embedder for hex-browser.
open_in_new See the runtime page A modern connected device rarely ends at the built-in display. The same product often needs a phone app for onboarding, a tablet UI for service and a local HMI for daily operation. Flutter can keep those surfaces close together because teams can reuse design, widgets and application logic instead of rebuilding the same interface three times.
The hard part starts after the demo. A Raspberry Pi can prove that Flutter belongs on a display, but a shipped embedded product needs predictable startup, display ownership, input handling, graphics fallback paths, reproducible deployment and supportable diagnostics. That is the layer hexDEV adds around Flutter.
What we actually built
The runtime is our own Qt 6 / Qt Quick Flutter embedder for hex-browser. It is an independent implementation: it talks to the Flutter engine through the embedder API, implements the hex-browser plugin boundary and exposes the Flutter surface as a Qt Quick item. It does not shell out to another runner and it does not depend on the flutter-pi runtime.
We deliberately support familiar embedded Flutter bundle conventions, because they are useful in real projects. A Flutter app can still be built into outputs such as app.so, kernel_blob.bin, icudtl.dat and Flutter engine library candidates. For Yocto environments using meta-flutter, the resolver also understands paths such as data/flutter_assets, lib/libapp.so and lib/libflutter_engine.so. That is build compatibility, not runtime inheritance: the product runtime is hexDEV's own embedder.
That distinction matters. Existing embedded Flutter projects such as flutter-pi showed a practical bundle workflow for Raspberry Pi and Linux targets. We keep the useful build and artifact-layout compatibility, but the runtime that hosts the app is ours: integrated into Qt Quick, loaded by hex-browser, packaged for embedded toolchains and designed to run as a managed kiosk HMI.
Qt Quick integration
The Flutter surface is a Qt Quick item. It participates in focus, geometry, display metrics, lifecycle, locale, keyboard, mouse, touch and wheel handling instead of running as a disconnected sidecar.
Production diagnostics
On-device diagnostics expose backend state, item size, device-pixel ratio, lifecycle, input state and the last error. Logging categories keep runtime, engine, channel, input, frame, backend, plugin and shutdown signals filterable.
Yocto-ready packaging
The embedder can be packaged for the same Yocto SDK families used by hex-browser. Package metadata records target, tune, CPU, FPU and checksum data so integration stays reproducible.
One app family, three product surfaces
The business case is simple: the same Flutter skills and much of the same UI code can serve an Apple/iOS app, an Android app and the embedded HMI on the device. Screen sizes, hardware capabilities and platform integrations still need careful engineering, but the design system and application logic no longer have to start from zero on every surface.
That matters most when the device is one part of a larger customer experience. Onboarding may happen on a phone, service may happen on a tablet and daily operation may happen on the built-in display. A managed embedded Flutter runtime lets the HMI feel like part of the same product instead of a separate legacy control panel.
Flutter UI family
Apple/iOSAndroidEmbedded HMIWhere it fits
The embedder is especially useful when a product already has Flutter skills, when the same UX should appear on mobile and device panels, or when a modern HMI has to be delivered without a full native rewrite.
Industrial touch panelsRetail and vending HMIsBuilding automationMedical and lab devicesFleet-connected products
How hexDEV turns this into a product path
The value is not only the embedder itself. It is the complete path around it: integrating the runtime into hex-browser, compiling the Flutter app for the right runtime mode, packaging the runtime with Yocto toolchains, deploying bundle and runtime onto the target, connecting it with Tempo2Market configuration and update flows, and keeping kiosk operation maintainable in the field.
That is where hexDEV can help: we work from the low-level embedded Linux layer through device application runtime, cloud connectivity and updates, diagnostics and long-term maintenance. If Flutter is the right UI layer for your product, we can make it work as part of the actual device software stack.
Want one Flutter app family across mobile and device HMIs?
We can review your target, UI requirements, graphics stack, update model and deployment workflow, then map a realistic path from prototype to maintained kiosk product.