Battle of the giants: A comparison between Qt and Flutter

The development of user interfaces has undergone rapid progress in recent years. Two outstanding frameworks are at the heart of this revolution: QT and Flutter. In this article, we take a closer look at which of these two frameworks has the edge and whether Flutter is a viable alternative to QT in the embedded sector.

QT and Flutter are frameworks for the platform-independent development of modern user interfaces. QT was developed in the early 1990s by Norwegians Eirik Chambe-Eng and Haavard Nord for desktop applications. Flutter was only released in 2018 and has since built up a huge fan base, partly because it is well suited for developing cross-platform mobile apps. However, Flutter is rarely used in connection with embedded systems; QT is more common.

QT has been used in the development of embedded systems for a long time and has proven to be an extremely robust and reliable framework in this context. For this reason, it is often the first choice and has established itself as the ‘standard framework’ that people like to fall back on. QT offers a wide range of functions and predefined libraries, which facilitates the development of complex user interfaces (UIs).

Despite these strengths, there are a few factors to consider when deciding on QT, especially with regard to the licensing model. Although there is an open source version, its use in embedded applications often requires the purchase of a commercial licence. This can be a financial hurdle in certain projects. In addition, developing QT applications in C++ or QML is more complex than what is familiar from modern programming languages or the web today.

For our comparison, we deliberately chose two different test platforms. One represents the best-case scenario and serves as a reference platform. The other is a realistic platform that more closely matches the requirements and performance of common hardware in practice. Both platforms have a capacitive touchscreen with 800×480 pixels.

The best-case reference is the newly released Raspberry Pi 5. We use the latest version of the Raspberry Pi OS, which is based on the 64-bit version of Debian bookworm, as the operating system. QT5 and Flutter must then be installed using apt-get.

An STM32MP157F-DK2 served as a more realistic platform. Unlike the Raspberry Pi, which uses a pre-built Linux image as its basis, we took a different approach for the STM32. Using Yocto, we created our own customised Linux image. Yocto is an open-source project for creating custom Linux distributions for embedded systems. In our case, this image contains all the necessary dependencies and packages for QT and Flutter.

To compare the user-friendliness and performance of QT and Flutter, we wrote a test application in both frameworks. This simulates a simple app menu, comparable to a touchscreen interface familiar from modern coffee machines, for example.

To compare the user-friendliness and performance of QT and Flutter, we wrote a test application in both frameworks. This simulates a simple app menu, comparable to a touchscreen interface familiar from modern coffee machines, for example.

We developed the Flutter version using Dart, a modern, object-oriented programming language designed by Google specifically for the framework. The hot reload feature allows developers to make code changes and see them immediately in the running application, speeding up the development process. This enables faster review and adjustment of changes without time-consuming restarts or waiting times. With QT, this is officially only possible with paid licences.

Developing with Dart is also straightforward. Thanks to the wide range of packages provided by official and community developers, many features are easy to integrate. However, the different licences for the packages must be taken into account. Although these are mainly open source, they may use more or less restrictive licence models. The currency of the community packages must also be taken into account. In the course of these tests, the Flutter app is generated and executed using flutter-pi, a Flutter engine embedder (Flutter pi Github).

But it's not just performance that has to be right – the user experience is also important. Response speed and smooth operation of the UI play a particularly important role here. To assess this, we developed several small test applications that can be used to check frequently used functions:

• Multitouch test: This app visualises every detected touch point to provide direct feedback on the delay between the actual touch and the detected touch event. For QT-based apps, we implemented touch point detection with both QML and C++, as we found that detection with QML had a greater delay compared to C++.
• Gesture test: This application allows you to test common gestures, such as pinch-to-zoom or rotating an image with two fingers.
• Maze test: This app is used to check the precision of touch detection. Users must draw a line with their finger to navigate through a maze.
• Animation test: This app tests the performance of the frameworks in terms of animations by playing numerous animations simultaneously.
• Video performance test: This application checks how effectively the framework can play videos.

The easiest way to compile the test applications for the Raspberry Pi is to build them directly on the Pi. Interestingly, the process took only a few seconds for the QML application, while the Flutter app took more than 5 minutes to compile on the Raspberry Pi. This can be explained by the fact that dynamic linking is used for the QT app, while everything is always recompiled for the Flutter app.

Alternatively, you can also compile the applications ‘cross-platform’ from another computer. In practice, this is often preferred, especially for professional projects. This approach simplifies development for devices with limited resources by allowing the software to be created on more powerful systems. By simplifying dependency management and ensuring reproducible builds, development becomes more efficient and flexible.

As expected, both the QML and Flutter applications run without any problems on the Raspberry Pi. However, the Flutter app shows significantly higher CPU and memory usage. While the QT app only requires about 90 MB of RAM in the app menu, the Flutter app consumes more than 400 MB. It appears that the Flutter Linux desktop environment is significantly less efficient. This is not a problem on the Raspberry Pi with 8 GB of RAM. In practice, however, systems with significantly fewer resources are often used.

Our analysis shows that the memory requirements for the QT and Flutter applications on the STM32 with 512 MB RAM are significantly lower than on the Raspberry Pi, at 72 MB and 75 MB RAM respectively. This is probably due to the leaner Linux system and the use of a Flutter embedder instead of the desktop Linux environment. Nevertheless, there is also an advantage for the QT application compared to Flutter. Although the differences are not as significant as on the Raspberry Pi, QT once again performs better in comparison.

Our findings show that Flutter can be a suitable alternative to QT under certain conditions. The advantages of Flutter lie in a more modern development process and the use of contemporary programming languages, which generally speeds up development. Another plus point is the attractive licence structure, as there are no fees to pay, unlike with QT.

However, our investigation also showed that Flutter does not yet achieve the same efficiency as QT on embedded platforms. This is because QT requires significantly less memory for the same application. Therefore, the conditions under which Flutter is a suitable alternative to QT remain specific: the framework is particularly suitable for projects where fast development and cross-platform compatibility are important.

In scenarios where systems have limited resources and efficient use is particularly critical, QT will most likely continue to lead the way and remain the first choice.

Pure web applications could be another promising alternative to QT, especially since they can run natively in browsers on embedded devices and therefore have virtually no requirements for the underlying operating system. Although this flexibility offers an attractive approach, there are legitimate concerns about the resource efficiency and long-term future viability of such solutions.

Another key aspect in the web sector is the rapid development and frequent emergence of new frameworks and methods. This contrasts sharply with the requirements in the embedded sector, where long-term support and the maturity of technologies are paramount. Nevertheless, it could be interesting to take a closer look at this in the future.