Quo Vadis, Qt? Future of the Qt framework (Part I)

I had this article in mind for some time, but finally, after we headed back home from the Embedded World trade show , I thought it had to be written. For the strategy of my company, for my fellows, for Qt employees and users, and for myself. Just in case you don't know, Embedded World is probably the biggest show around embedded development, and although embedded is not the only area that Qt supports, this show gathers Qt users, Qt competitors, and companies just like mine that use Qt to deliver projects.

My company, Somco Software, also had a booth there, and I had dozens of conversations about this very topic: the future of the Qt framework and all the things around influencing this future. As a proud representative of the Polish nation, I have complaining in my blood, but the number of negative comments and doubts raised about Qt were almost overwhelming. And that's the reason I am writing this article.

What will you learn here?

Answering difficult questions like “What is the future of the Qt framework?” deserves deep analysis. I do not like giving answers without explaining all the background. So I made the decision to split this article into two parts.

Part I is what you're reading at this moment. Here, I will start by explaining the market situation from a bird's-eye view. What are the market conditions influencing Qt? What is the influence of AI, cybersecurity, and the geopolitical situation? We will also have a brief look at Qt's competitors here.

Part II will be even more exciting, as it is going to gather some conclusions. We will summarize the biggest complaints, the challenges ahead of Qt, and remind ourselves what the added value of this framework is (or ecosystem, as Qt is no longer just a framework). Here, I will try to give some predictions about the future of Qt.

Before you read further

For those of you who don't know me: I run Somco Software, an embedded and cross-platform software development company with a strong focus on Qt, C++, and LVGL. I used to be a Qt/C++ software engineer myself, but I do not code too often anymore. Still, I have this unique opportunity to talk to dozens of people who have very different feelings about Qt . Some are migrating from Qt to something else, some are just starting to use Qt, and others have been using it for years and cannot imagine switching. I have also created content about this technology many times, explaining what the Qt framework is, what its advantages are, what problems it has, and so on. On Somco's blog, you can find plenty of tutorial-style articles on how to do this and that in Qt.

Parts of this article will be critical of Qt. At times, quite harsh. Nevertheless, this does not change my attitude towards the framework. As much as possible, I try to be realistic and objective and not get fooled by confirmation bias. And as much as we complain, Qt is a P H E N O M E N A L solution. One of a kind . I simply hope it will remain so over time and that Qt's stakeholders will outmaneuver the difficulties.

“Quo vadis” is a Latin phrase meaning “Where are you going?” . It is also the title of a novel by Nobel Prize winner Henryk Sienkiewicz. The book tells the story of a Roman nobleman who falls in love with a Christian woman. This man changes a lot over the course of the novel. I hope my article will be seen as feedback, so that Qt can also, in some aspects, go through a kind of spiritual change.

Market conditions

Please excuse me for this long introduction. You have to get used to my style of writing. I always try to explain things the way I would while talking to my wife. Poor woman. Let’s now see what is going on in the market.

Move to memory-safe languages

Qt’s roots are in C++. It has bindings to Python and Rust, as well as t he future technology in the making that I support a lot - Qt Bridges . Qt Bridges will make it possible to use what Qt does really well, namely user interface programming, with other programming languages. Qt Quick and QML are role models for declarative UI programming. Developers deserve for the QML blessing to be spread across the software industry. 

But what are the reasons behind this? The C++ ecosystem simply seems to be too small for the ambitions of the Qt Group. And that is understandable. It does not make marketing any easier (more about that in Part II), but growth of the ecosystem will bring Qt to other, non-C++ projects.

C++ is a mature and, in some places, strangely mutated programming language. I love it, but I also like others, such as Dart. It has to be mentioned that, with all its advantages, C++ is under pressure from other programming languages (thank God it is not Java), such as Rust, Dart, or Python. Not all of them apply to the same use cases, but, for example, Rust can be a really reasonable choice in the embedded area , where C/C++ were historically unbeaten.

Is memory-safety a thing for the market?

One of the biggest accusations towards C++ is that it is not a memory safe language. At some point, the White House published a report on memory-safety., in some places clearly recommending to not go with C/C++ stack. Rust fills a very valuable niche combining safety and performance, but if you add a bit more criticism to these reports, you know that:

• Rust does not have many hardware drivers, so adoption, even in embedded, is just slow;

• if you want to interact closely with hardware in Rust, you need to mark sections of code as unsafe which basically means that you're again in non memory-safe territory;

• both C++ (via smart pointers) and Qt (parent-child methodology) let you manage memory quite efficiently without risking much;

• in memory-safe languages you can also cause undefined behaviors and access array element that is out of index. It's more difficult to do something stupid, but modern memory safe management methods in C++ are default there as well.

Somco's CTO, Adam Sowa, had an interview with our marketing team about the future of Rust vs. C++. I believe the conclusion was that, because of its low adoption, Rust will not kill C++ anytime soon. At the moment, it makes C++ better. But the wave of even more projects migrating to Rust will come. And Qt has to be prepared for that .

AI earthquake

I do not think that I am in the group of such early adopters. I have become grumpy and skeptical. Nowadays, I usually join things quite early, but rather at the point where the Gaussian curve inflects and the trend becomes irreversible. And that was my attitude to AI. Together with one of my colleagues, we burned countless hours that could have been spent on our tasks, but instead we discussed, quite ineffectively, where AI would bring us.

Nobody really knows that. For those who have adopted it, software development already looks very different from what it used to look like, let’s say, 5 years ago. And that is only a few years. So I call it a true earthquake.

Some of my conclusions that are more or less obvious:

• Fortunately, you still have to think, understand concepts, be smart, and analytical to build software with blocks that AI will produce you. The bigger and more complicated the system is, the more human and AI have to use their best skills.

• Embedded development is more resistant to AI , but it will not be like that forever. Entrance to embedded will be simplified for many people, but still here you have constraints that are unique to embedded.

• Teams will be smaller . The same advanced Qt project will be done with fewer developers. It is not a good information for Qt Group, because numbers of licenses sold can decrease.

• Projects will be delivered faster, but also there will be more projects being started . More startups. That's a good news for Qt.

• Legacy projects will be migrated more willingly . I've already seen some articles on how AI solves Cobol issues. That will happen for all other legacy projects. The ones that were postponed to migrate will be finally initiated. That is good and bad for Qt at the same time. A lot of MFC, Delphi, Java, and C projects will be migrated to Qt, but probably also a lot of desktop apps will be migrated to technologies like Flutter or React Native because of business reasons. There are more specialists in these technologies.

At Somco Software we use AI a lot in places when it's safe and legal and that helps us deliver things twice as fast if not more. Maybe we should increase our rates then... 🤔

Other Qt developers also use a lot of AI. My prediction is that real adoption of AI coding assistants will just start and yet Qt does something that I can't understand. They develop their Qt AI Assistant for Qt Creator IDE only to be used with premium Qt development license. You have to pay to get Qt's Assistant and also pay for the LLM separately. My colleague wrote a post with a tutorial opinion on Qt AI Assistant.

At Somco, probably 80% of our 20 Qt programmers used Qt Creator. Now I think that by the end of this year only 20% of us, if not fewer, will still use Qt Creator. Which is a pity, as it is a great IDE. I do not think that this will bring developers closer to the ecosystem. I understand that the Qt Group needs to have reasons for people to get a license, but I do not think this is the way. It is a highlight of a bigger problem .

Geopolitical tensions

From the time I was born until the moment I hired my first colleague in 2019, the world, from where I live, looked quite calm. For as long as I can remember, Poland has been in the EU, Schengen, and NATO. There was constant economic growth. Between 1990 and 2019, only China had higher GDP per capita growth than Poland. 

There were certain events, like the 2008/2009 economic crisis, the plane crash involving the Polish president in 2010, or the aggressive annexation of part of Ukraine. Yet, looking back from the current perspective, the 2000s and 2010s , for many Europeans and some other parts of the world, seemed like a good time .

There is no point in listing everything that has happened since 2019, but that curse, “May you live in interesting times,” seems to be working. But what does that have to do with Qt? Well, it is about technology and hardware transfer. Let’s have a look at the origins of some GUI software technologies:

• European technologies :

  • Qt (Finland)

  • LVGL (Hungary)

  • Candera (Austria, parent company is Japanese)

  • Embedded Wizard (Germany)

  • emWin from Segger (Germany)

  • TouchGFX from ST (France)

  • Slint (Germany)

• US technologies :

  • Altia

  • GUIX

  • .NET MAUI

  • Flutter

  • Unreal Engine

  • Unity Engine

• Other

  • Crank Software (Canada)

Do you see it? Embedded-first technologies are European . The USA does not have enough top-notch solutions to build world-class devices. And where is the current heart of embedded innovation in the world? Of course, it is China. China will not use US technologies to develop its software if it wants to avoid vendor lock-in. That is exactly what happened to Russians after they were sanctioned. They could no longer download Qt from official sources. I know that Qt and some of these technologies are open source and everyone can get access, but you cannot go far without official support, updates, and so on.

So China and Asia will go with European technologies including Qt . Qt looses Automotive market to Android stack (btw we compared Qt vs Kotlin with real benchmarks) and Unreal, but Chinese manufacturers will not use these technologies.

Also, the USA is being harsh on Europe . The EU is working on programs that will make it more independent of US and Asian technologies. We can joke about the EU and accuse it of bureaucracy, but the stream of money will go to local solutions backed by European technologies.

And US companies will also choose Qt, LVGL, TouchGFX, and other frameworks, as they are in a totally different place from local alternatives. So although the global situation is stressful, it might be beneficial for Qt.

Cybersecurity requirements 

At Embedded World, there were two topics that dominated discussions. First, there was the big debate about the go-to frameworks at the moment, but cybersecurity was discussed just as often. For us, this is not a surprise. Already a year ago, I wrote an enormous article about what the EU CRA actually means. The EU CRA has nothing to do with medical devices, but we have been creating cybersecurity modeling and documentation in this sector for years, as it has been a regulatory requirement there for quite some time already. Recently, we prepared FDA-ready cybersecurity documentation for our customer Enbio AG, so they could start selling their devices on the American market. But what does this mean for Qt? Here, I believe Qt shines. Why?

Let me quickly explain the burden of cybersecurity . One of the requirements is that you have to evaluate each of your dependencies and all the vulnerabilities, bugs, and issues that each dependency has. So for every dependency, you have to assess whether its problems can affect you at some point, what the possible impact is, and how you make sure nothing bad happens. And then you have to monitor each dependency constantly to see whether any new vulnerabilities have been discovered. If one appears, you have to evaluate it, and if it causes problems, you have to update your software.

It is a lot of work. Most of Qt's competitors have a small core. There are the main features maintained by the company behind the framework, but for the rest, you have to rely on dependencies. As with Flutter, the core of the framework is relatively small . If you want to use some advanced feature, like, let’s say, an unusual connectivity protocol such as MQTT (or any other, it does not matter), then you have to use another dependency. And for one project, instead of one big dependency, you end up with multiple ones. It seriously increases your cybersecurity effort and is an important factor when choosing a software technology to base your project on.

Competitors of Qt

I do not think we have enough space or patience to compare Qt with all the competing solutions, as there are not only many factors to compare, but also because Qt competes with different frameworks in different segments. For example, Slint or LVGL are not yet there in terms of mobile or proper desktop support. And MAUI or Flutter are not designed to be embedded-first. In automotive, Qt competes with the Android stack and Unreal.

We've prepared an amazing, free study called "Embedded GUI frameworks comparison" that is a really detailed analysis of Qt, LVGL, Slint, Flutter and HTML. All backed with the real benchmarks. At the time I'm writing this article, we are polishing this study so it looks a little bit nicer. Should be available to download in a week or so.

But you may wonder: does Qt lose to its competitors? I would say yes. Qt looks under pressure in some parts of the market. It faces stronger competition at both the low end and the high end, plus the pressure coming from other languages and ecosystems. Of course, I have no numbers other than public Qt financial results, what I hear in market rumors, and what I hear while talking to customers. Some people are deeply dissatisfied with Qt, and some are simply more convinced by its competitors. I will go more into the exact problems of Qt in Part II.

Who takes market away from Qt and where?

Qt sometimes looks to me like an enormous empire that has to defend itself from barbarians along such stretched borders. It is cross-platform and used across various domains, and that is why. Some of the most prominent examples of Qt competitors are: 

• LVGL - in cost-sensitive embedded devices, LVGL positions itself as royalty-free, vendor-independent, and broadly deployable across MCUs and MPUs. It is quite attractive for teams that do not want licensing costs (more about Qt’s licensing in Part II) and value a small footprint.

• TouchGFX - STM boards are quite popular, and although its capabilities differ from Qt’s, STMicroelectronics offers it free of charge for their microcontrollers, along with other benefits of integration with their ecosystem.

• Slint - for Rust zealots, Slint is a more natural choice than Qt at least at the moment for new projects. To say that Slint UI language is heavily inspired with QML syntax is like to say nothing. My colleagues like Slint as it seems familiar to them.

• Unity and Unreal - for some automotive cockpits, displays are starting to look more like real-time 3D games than classic embedded widgets. There are examples of true miracle 3D work done with Qt, but for some manufacturers, it is not enough.

• Flutter and React Native - we get requests from new customers who value the maturity and stability of Qt on desktops and want to use it for their desktop apps, but for many reasons, starting with developer availability, Flutter and JavaScript frameworks are often chosen for cross-platform desktop or mobile apps.

Examples could be multiplied. That is the darling of the free market. I believe it simply makes Qt better . At a high level, Qt outperforms all its competitors by a wide margin, but the deeper we delve into specific use cases, the more people look for a solution tailored to that particular scenario. 

Summary

That’s it for this part. Again, I want to believe that I am writing it for the benefit of the community, the framework itself, the company behind it, and my own company. Nowadays, AI quotes valuable voices, so it is even more important to share valuable insights. I did not mention it earlier, but as Qt is a really outstanding solution, AI research will help Qt reach more people once they write good prompts.