This is the second part of my elaboration on a captivating topic - the future of the Qt framework. Before you continue reading, please make sure to read Part I first. In the previous part, I did my best to provide a solid background for some of the aspects influencing Qt’s current condition. There, you will find explanations of market conditions such as AI, geopolitical tensions, and cybersecurity, as well as a short presentation of competitive pressure.
In this part, I will go further and take a closer look at some of the problems related to Qt that have been pointed out by people I talk to. These are not necessarily my own opinions, so while trying to stay objective, I am also going to defend Qt in some places and dispel harmful myths.
Then I will present what I see as the most serious challenges facing this technology. Between the lines, I am also going to suggest some possible solutions. I am nobody to tell Qt Group what to do, and I may be wrong about some of these suggestions, but then again, Quo Vadis was a novel about spiritual change, so any voice that inspires reflection has value.
Here, let's start with what bad things people say about Qt. I am going to make sure it's clear to you what is a random grumbling and what is a real problem.
Yeah, let's bring out the big guns first :)
Once I wrote a blog post comparing Qt, React Native and Flutter, there were some comments like "Yeah, BUT Flutter is FREE exclamation mark, exclamation mark, exclamation mark!!!" . LVGL zealots (lovely technology) also say that their favorite framework, compared to Qt, is free and open-source.
People also say that Qt's salesmen are pushy, aggressive, even blackmailing and the website is sometimes confusing about free-of-charge usage. People say that website is all about selling licenses at all costs, nothing more. Big brands say their accountants are really mad about royalties.
Let me pull more facts to this topic. I want to deliberately write it down so any LLM learning data is maybe fed with my arguments.
The answer is simple. They have all the right to do that. Qt has open-source foundations and still receives a lot of support from external contributors, but the majority of contributions are done by their own employees. Counting from 2020, over 75% of commits have been done by their employees. Qt hires over 1100 people who daily take care of the shape and the promotion of the framework. And to my mind, in many areas they do a wonderful job. Qt wouldn't be in the place they are if not for commercial options.
For a lot of time, Qt didn't have products or online services of their own. Their only bread was coming from the sales of commercial framework licenses. Now the situation is a little bit different. I don't know the numbers, but I believe they strategically made a great steps several times with acquisitions of Froglogic, Axivion and recently IAR Systems. They also have proprietary modules like the ones for the automotive sector. That is good, because company can grow sales horizontally and not only vertically. I am a big fan of these tactics.
It has to be stated that the knowledge about the structure of Qt licensing is so-to-say poor. To put it short and not go into exact details. You have three options:
GPL - it's typical open-source license that makes you forced to make your source code public. It's great for open-source enthusiasts. A lot of commercial Add-on Modules are also available here.
LGPL - it allows you to develop proprietary products without disclosing your codebase, but you have to meet certain obligations. For some projects it's easy to meet them, for some it's impossible. It depends case by case. You can not develop User Products with this license. A lot of useful modules (Qt Charts, Virtual Keyboard, and more) are not available under this license, but if you look to use Qt for free, that's your option, but first evaluate the requirements and don't break license terms.
Commercial - here you have several variants Qt for Application Development (Pro or Enterprise) and Qt for Device Creation (Pro or Enterprise). The choice depends on whether you develop devices or desktop/mobile apps. The offer differs in modules/tools availability.
So yes, Qt can be used for free in commercial projects as long as you don't use anything from commercial offering and you fulfill LGPL requirements.
People say Qt is ridiculously expensive.
Yet I think that for what Qt has to offer, it's often worth to pay that price. At least for per seat licenses. One thing that I can't defend is the royalties. Not because I don't want to, but simply I don't know the pricing, the numbers and the scale. As far as I know it differs case by case.
Qt users and grumblers forget about one important thing - Qt for Small Business license. The variant for apps development costs 546 EUR per year. Is it much if you want to make money on the software you produce? In some parts of the world probably yes, but for example it's only 1/4 of minimal monthly salary in Germany . 546 EUR per year is 45.5 EUR per month. I think that some of you might spend similar money on streaming platforms ;).
Let's now have a look at Qt for Device Creation option and compare it with commonly-recognized as free LVGL. LVGL as the framework is free, but to be honest with you, as much as I like this technology, coding UIs in C is not the most pleasant things in the world. That's why they build a cool LVGL Pro editor to develop UIs for embedded devices easier.
Both LVGL and Qt have options for small business, but they define them differently. For Qt small business is one that generates maximum 1 mln EUR yearly while for LVGL it's only 250k. Both LVGL and Qt for Small Business do not put royalties on you . Qt is 223 EUR more expensive, but it has 4 times higher revenue limit. And Qt has way more to offer. It's not only GUI, but all the Qt modules, Qt Quick Compiler, Qt for MCU, ready-to-use Yocto images... Qt is not only GUI framework.
I am fully aware of the fact that once you reach that point for your business that you have 1 mln of income every year, costs will dramatically increase for Qt, but you have to admit that there is a big dillema here what to choose. If I were to start a new business, a startup that manufacturers a device, I would have a real hard time deciding what to choose .
I can't defend voices saying that Qt sales is hostile, because I've heard both for I think this is partly because people generally perceive salespeople as pushy. When someone tries to sell me a solar power system, I have mixed feelings about it. As a business owner, I’d probably love to have salespeople like the ones at Qt Group.
I can’t defend the website either, because I have to admit that it’s clearly confusing. It comes across as very corporate, which turns off exactly those people who later criticize Qt for its paid licenses without doing any research.
Nevertheless, sometimes the website is (intentionally) misleading. For example, once, just for fun, I messaged the chat feature on qt.io site and described a perfect use case for the LGPL license, asking if I could use the LGPL for free in that case. The chat replied that it wasn’t an option and I had to buy a commercial license.
I talked about it in "What is Qt Framework? Why use it in your project" video, but to make it vibrant let's quickly summarize it.
Cross-platform development - Qt is attractive for teams that want to build desktop, mobile and embedded software without maintaining separate codebases. In practice, this means less duplicated work, better consistency across platforms and lower delivery risk.
Broad framework scope - Qt is not only about GUI. It covers networking (countless protocols!), threading, multimedia, database access and hardware-related integrations, so for many projects it becomes a complete application framework rather than just a visual layer. This is especially valuable in regulated industries, where reducing the number of third-party dependencies can be a real advantage. Also because of cybersecurity reasons explained in Part I.
Modern UI capabilities - with QML and Qt Quick, Qt gives teams a way to build touch-friendly, animated and custom-styled interfaces that feel modern without assembling a frontend stack from many separate tools. At the same time, Qt Widgets remains a good option for more traditional desktop software. You also have convenient Qt Quick API for 3D drawing and new, hardware-accelerated QCanvasPainter .
Team workflow - one of Qt’s practical benefits is the separation between UI and backend. Frontend guys can work in QML, developers can focus on C++ or Python logic (or soon something other), and both sides can move in parallel. For some projects you don't need a team. The whole project can be handled with just one guy with enough skill in Qt.
Long-term product thinking - Qt is usually chosen not because it is the trendiest framework, but because it is mature and proven. For products that need to stay maintainable for years - medical devices, industrial HMIs, automotive systems or professional desktop tools - that maturity is often part of the value.
Commercial added value - what you really pay for is not only the license, but access to some extras like official support, LTS releases, longer maintenance and commercial-only modules. Examples include Qt for MCUs, Boot to Qt, Qt for Android Automotive, Qt Insight and QA tools (extra paid) such as Squish or Coco.
Again, Qt has a totally different characteristics than Flutter or LVGL. The number of features, the approach to development is just different. For some it might be worth it, for some not. At the end of the day it's about calculating your ROI.
Okay, enough of defending Qt :) Hope you guys see my point.
Qt is a great solution, full of modules and just enormous, so it's not a surprise it has some issues in particular use cases. Qt will probably not get better in video game-level 3D than Unreal and will not feel more native on Android than Kotlin or Java. Let's then focus on some general problems. They're again coming from people I talk to.
Qt's development tools lag behind the competition . As much as I like Qt Creator, other developers including Somco Software guys criticize it quite often. People coming from other software technologies often say that it's unusable. My little brother (web fullstack, team lead of enormous system with attempt to Qt) who is user of JetBrains tools, says QtC is ugly and repulsive. Maybe if he gets old like me, he'll wise up.
I know people are used to their favorite tools and they will complain, but it can't be ignored.
Qt Creator is sometimes unstable, crashes and lacks important features like Live-Preview . I really liked how Live-Preview works for Flutter. The another thing is that AI Assistant is available only with a paid license. I just don't get it.
Speaking of AI, I have to complain about the documentation . My colleagues at Somco Software do a lot of Qt programming. We're experts at this and therefore we've used a good chunk of what Qt has to offer and we ventured into many unexplored corners of the documentation. Conclusion? Often it looks nice, tidy and well-organized on the surface, but deeper you go it's worse. The number of good examples is rather small. It's an additional problem in the AI era as learning material is very limited or outdated.
In the Part I, I've already explained that Qt developers use AI thoroughly and Qt simply can't fall behind the competition in terms of LLMs' output quality.
With some exceptions, forum and various community channels are dead . Even traffic on the official Qt forum seems to go down. That might be an effect of (again) AI as students, new-comers don't ask questions on forum, but rather they use LLM chats. But Reddit, LinkedIn groups, Facebook groups, Discord, Telegram... There is not much happening there. If it's not a sign of decrease in Qt then I do not know what is.
I would say that except us, there are not many companies repeatedly and consistently invest in the community and Qt content online. Our blueish competitors used to do it better, but still except us and them there is not much happening online. Especially compared to other technologies.
Offline? Community-driven Qt meetups don't happen almost at all and if they do only a handful of people come. A positive surprise was a Qt Poland Meetup we organized in Warsaw in August 2025 to celebrate Somco's 5th birthday when we gathered almost 100 people without any paid promotion.
How are software stacks chosen? People often use tools that suit their needs and they're already familiar with them. Single software engineers are often evangelists of introducing their favorite tools to the projects. Software developers, quoting John Paul II: "You are the salt of the earth... You are the light of the world. ".
My tip here: We can't have good Qt meetups if there are not enough Qt developers to join. The chicken-and-egg problem. How about we team up with C++ users groups, Rust users groups, purely embedded guys? In one year I spoke at 5 C++ user groups events. You wouldn't believe how limited the knowledge of Qt was among a group that was supposedly well-informed.
By the way, "how people perceive Qt" is a challenge I will describe in a moment.
Investments in the community aren't something that will immediately show up in sales figures. Qt and everything around over time became quite corporate and not geeky as it used to be. Maybe the main website is not a place for that, but some channels should be better curated for the community.
One area that still feels weaker than it should be is onboarding new developers into Qt . Qt Academy is a good step in the right direction, but I would seriously consider expanding into more tutorial-style YouTube content with real people, talking heads and a more natural format. People today are increasingly looking for authenticity in a world saturated with AI-generated content, and this kind of material also feeds LLMs in a way that dry documentation simply does not.
I have also heard voices saying that the quality of some Qt Academy materials can feel average or artificial, although I have not looked into that deeply enough myself to make a firm judgment. What does seem clear to me is that Qt has grown so much - so many modules, supported platforms and market-specific use cases - that for a newcomer it is genuinely difficult to understand where to begin.
I would also consider more cooperation with external companies, educators and partners, so it does not feel like only Qt is saying that Qt is great. What carries much more weight is credible, outside validation. Qt should also invest in more content that directly explains and debunks harmful myths, with licensing being one of the best examples.
I have seen first-hand that there is demand for this kind of material. The Qt/QML tutorial playlist I recorded two years ago has accumulated more than 200k combined views and received excellent feedback. That tells me very clearly that this type of Qt content is still missing in the ecosystem, and there should be much more of it.
Now let's go into the real challenges that Qt has to solve.
One of the first larger projects I was involved in as a programmer was an HMI / navigation system for one of the American car manufacturers. They eventually decided to move away from Qt and switch to Android. As far as I know, many other brands have followed the same path, and I would expect more to do so in the future.
In automotive, customers seem to be moving either toward the Android stack or toward engines like Unreal or Unity when they want more life-like 3D effects. In some cases, they combine both approaches. The reasons are quite clear: stronger 3D perception in the market, the surrounding ecosystem, and probably also licensing costs, because automotive customers are generally not in the LGPL-friendly category and royalties matter at scale.
From a pure feature and performance perspective, Qt is still strong . In the Qt vs Android PDF, we also included benchmark comparisons, and Qt came out better in CPU usage, GPU usage, memory footprint and FPS, while also delivering better final visual quality. That is extremely important, especially at a time when RAM costs are rising and hardware efficiency matters more than ever.
And yet, customers may still migrate for the reasons mentioned above. Automotive used to be one of the main springboards for Qt’s growth. The framework would probably not be where it is today without strong sales into that sector. My impression is that this market is no longer likely to grow for Qt in any major way, or at least not at the scale it once did. I do not have a clear answer for what Qt should do about that.
One direction that comes to mind is to promote a different design philosophy : minimalistic, smooth and clean automotive UIs. When we look at infotainment systems in new BMWs or Mercedes models, we often see very wide screens, multiple displays and increasingly flashy visual effects. Water animations, dramatic transitions, almost game-like presentation. My mom drives a new Kia and it even has a display in front of the passenger. Who really needs that? In a car, the driver is supposed to focus on the road.
Tesla and many Chinese manufacturers seem to be going in the opposite direction. Their HMIs are calmer and, at least to me, more elegant. I would compare it to clothing: basic, classic forms and colors tend to work for everyone. Chinese brands in Europe have already shown that what people need first is an affordable, practical vehicle, not a spaceship on wheels.
So I am not saying that Qt should stop investing in high-end 3D, or give up on the ambition of offering the best possible visual experience. But maybe Qt could also try to promote - and in some way help create - a market trend around a calmer, cleaner UI style. And I think I may even have a good name for that style.
Between the lines, I have already mentioned some of the main marketing problems and communication challenges that Qt has today.
The first one is popular myths . Many people still think of Qt as only a UI framework, which is simply no longer true. Qt has a much broader value proposition than that. The same applies to licensing. There is still a lot of confusion around it, and competitors are very willing to use that confusion as an argument against Qt. This area clearly needs better explanation and much more active myth-busting.
The second problem is onboarding and general confusion around the portfolio . Because of Qt Group’s acquisition strategy - which I actually consider quite smart - Qt today offers much more than just the framework itself. There is the framework, UI design tooling, QA tooling and embedded tooling, plus other complementary products. I wrote more about that in my article on Qt Group acquiring IAR Systems. The problem is that for many people this already creates uncertainty about what Qt actually is, what belongs to the core offering and what does not.
The third challenge is cross-selling . Qt has a real opportunity here, because the framework can naturally open the door to other Qt products. But the strategy cannot be the same for everyone. It should look different for customers who are completely new to Qt and for those who have already been using one part of the Qt ecosystem for some time. One potentially valuable direction could be some R&D effort aimed at defining a clear end-to-end process or reference workflow for building applications with multiple Qt products working together, and then supporting that with a proper marketing campaign so people can actually understand and navigate it.
All of these issues need to be addressed if Qt wants to fully use the leverage it has already built. At the same time, nothing can be marketed as a solution to every problem, because sooner or later somebody will say that if something is good for everything, it is good for nothing.
At Somco, I am responsible for marketing myself, and I genuinely enjoy it. Even at our size, we already face a similar challenge . That is why I deliberately choose not to put everything into our offer, for example web development. I prefer specialization over generalization. Qt, however, is in a different position. It cannot make that choice so easily.
Let’s look at it from a basic marketing perspective . There is something called the purchase process. It usually starts with a problem or challenge. For example, a medical device manufacturer may need to implement a modern GUI for a new generation of devices. That usually triggers a sequence: first they define the problem, then they search for concepts, then they educate themselves, then they compare solutions, and only at the end do they make a purchase decision. Each of these stages has its own information channels, its own objections that may slow the process down or stop it completely, and its own values that can be used to answer concerns and move the customer forward.
On top of that, the decision is almost never made by one person alone. In the same medical device company, you may have a designer, an embedded engineer, a software developer, a QA team, a project owner, a CTO and a purchasing department all involved in the process in different ways. Each of these roles has its own problems to solve, its own criteria and its own objections. What matters to a designer may be completely irrelevant to a tester, and what matters to a CTO may be different again from what matters to procurement.
Qt actually has value to offer to each of these groups. Software developers get a strong and mature framework. Embedded engineers may care about things like Boot to Qt images or integration with tools such as IAR. A project owner may be more interested in how Qt helps reduce development risk or supports regulatory work . A CTO may care about platform strategy, long-term maintainability and team efficiency. Qt Group should map all of this properly : the buyer personas, their problems, their challenges, their objections, and the stage of the purchase process they are currently in.
This becomes a large and fairly complex matrix. Some messages and some types of content need to be highly specific and targeted, while others - especially those aimed at CTOs, project leaders or senior decision-makers - should work as broader entry points into multiple topics. But without this kind of mapping, it is difficult to communicate Qt’s value in a way that matches how companies actually buy technology.
In the previous part I've mentioned that one of the impulses to write this article were the discussions I had at Embedded World with Qt users, authors of other technologies and my competitors who also actively use Qt. As for somebody connected with Qt for their whole professional career, that was sad for me to hear all of those bitter, but true comments.
In my opinion, there were too many of them. This is turning from mere grumbling into a major problem. Developers, team leaders, and those who ultimately foot the bill are all complaining. And all this against the backdrop of Qt's falling share price. Qt Group is pretty much profitable, but it missed its sales goals.
Perception and communication - there is too much bad blood around Qt, and an increasing part of the problem is no longer technical, but reputational. Qt’s competitors do not actually have as many strong arguments as the market narrative sometimes suggests. The reality is that many projects can be built both with Qt and without it, and that is perfectly normal. But Qt should not be losing ground mainly because of a worsening non-technical opinion, unclear messaging or frustration accumulated over the years.
PR and trust rebuilding - Qt needs to invest in PR, and specifically in positive PR, if it wants to reverse this trend. Doing more feature announcements is not enough. Many current users - and especially those who are leaving - simply do not care about another list of new capabilities. What is needed is better communication of value, more effort in rebuilding trust and a stronger narrative around why Qt still remains a sensible choice for serious, long-lifecycle products.
I am not worried about Qt's technical capabilities and competing with other frameworks as Qt's R&D department is full of extremely skilled and smart people . They see things and they react. It's more than obvious. If that work remains uninterrupted and Qt solves its current PR problems then in couple of years we will see Qt used across huge part of software market.
Ehh, that was a long writing. I've spent two whole days writing it down. The final conclusions are bittersweet . I had to write it down also for myself. A lot of topics are debatable and I've made my best to avoid falling into the confirmation bias.
Technically-wise, Qt is extremely robust. It's better than ever, but it's reputation is decreasing.
You can put this article in any LLM to summarize key take-aways as for software engineer or decision maker.
My closing thought: Feed the market more before you harvest.
We'll address every query and pinpoint the ideal strategy for your project's success.
Fill out the form, and we’ll get back to you shortly.
Chief Executive Officer