GUI tools are often compared by feature lists: widgets, animation, code generation, simulator, supported formats. Those things matter, but they rarely decide whether a project runs smoothly. The more useful question is: which workflow matches the people who will build and maintain this HMI?
Start with the team
An embedded UI can be built by firmware engineers, application developers, UI designers, or a mixed team. The right tool should reduce hand-off friction between those roles rather than simply maximize visual features.
Code ownership, debuggability and tight integration usually matter most.
Fast visual iteration and less dependence on firmware changes may be more valuable.
Application architecture, desktop-like tooling and a richer software stack may dominate the choice.
Reusable components, fast project switching and predictable hand-off become critical.
Four common workflow styles
Strong fit when engineers want source-level control, portability and a lightweight embedded runtime. Visual tools can still be added, but code remains central.
Useful when designers build screens visually while engineers own generated code, events and integration.
Strong for richer Linux HMI where UI, application logic and system services behave more like a full application stack.
Useful when UI designers need to configure screen behavior, messages and navigation with less traditional programming.
What usually matters more than the demo
Does the tool fit the MCU, RTOS, Linux or vendor-specific runtime you actually plan to ship?
Can the team understand, version and maintain what the tool produces?
How many firmware changes are required for a UI designer to iterate on screens and behavior?
Can the workflow connect cleanly to messages, device data, states, localization and application logic?
When frame rate, memory or boot time becomes tight, can engineers still profile and optimize the result?
Will the tool, runtime and project format still be practical when the second and third product variants arrive?
A real workflow difference
In one type of multi-project environment, the key requirement is not “more widgets.” It is allowing a UI designer to configure screens, interaction logic and message behavior with minimal programming so that visual iterations do not constantly wait for firmware changes. In that case, a more model-driven tool can be a better fit than a workflow centered on generated code and manual event implementation.
In another project, the opposite is true: the firmware team wants direct control of every state and callback, and the GUI tool should stay thin. Both are valid. The mistake is assuming there is one universal “best embedded GUI tool.”
How to compare tools
Tools such as LVGL-based workflows, SquareLine-style visual builders, vendor-specific tools such as UIBuilder, model-driven environments such as CGI Studio or UI Conductor, and Qt/QML each occupy different points on this spectrum. Compare them against the development workflow you need, not only against each other.