Qt6 is ready for you. It may not have been the case a couple of years ago, but at 219 Design, we’d like to assure you that Qt6 is ready now.

So the real question is: are you ready for Qt6?

An enormous body of successful software applications is based on Qt5. Perhaps you are responsible for one of them. How should you approach updating your application from Qt5 to Qt6?

219 Design has carried out this process on a variety of applications recently, and we’d like to share our observations in the hope that you find them helpful. By the end of this article, we hope you feel clear-eyed and better equipped to tackle the task, and generally more ready to take the plunge, at a time that makes sense for your project.

  • First, we consider several factors that might influence your decision and timing.
  • Then, we recommend a few prelude steps that can be done at any time – perhaps long before you commit to the actual upgrade.
  • We’ll also talk about what types of extra effort might be required, depending on your distinctive use of Qt.

Get Past Hurdle One: Is Now the Time? Do I really have to?

On one end of the spectrum, there are scenarios where you may have no choice but to upgrade. Mobile apps fall into this category. Updating your Qt Android or iOS app inevitably brings along the non-negotiable requirement of updating your Qt version. The app stores “rev” their API requirements fairly frequently, and each Qt release locks you into a small set of platform SDK versions. In other words, to pass the app store gatekeeping, you’ll need a particular mobile SDK. And, to target that SDK, you’ll need a particular Qt version.

Far on the other end of the spectrum, 219 Design is aware of (and quite happy for) one confidential client with an “air gapped” product on hardware that hasn’t changed for almost a decade, and the product continues to ship and to run just fine using Qt4 (yes, Qt four).

In both of the above examples, hardware and operating system play a big role. If you are able to stay firmly pinned to one static hardware configuration and one static operating system, then you may not be compelled to move off of Qt5.

However, unless you are planning to end-of-life your product in the near term, sooner or later a chain reaction will kick into effect, wherein new hardware requires a new OS version (or vice-versa), and then in the wake of that, Qt6 will become required.

Get Past Hurdle Two: Is Now the Time? Do I WANT to?

The preceding section explains why you might get boxed in and have no choice but to upgrade. But, of course, there are also plenty of reasons to willingly and enthusiastically upgrade.

Qt6 has now gone through many minor releases, bringing it to a mature level. Some benefits of Qt6 over Qt5 include: improved rendering performance, improved API for various so-called “platform extras,” and an improved QML engine.

It’s also easier than ever to maintain the build of your Qt app with CMake and drop all use of qmake. This is not a required step in upgrading to Qt6, but if you choose to drop qmake for CMake, you will enjoy much greater parallelization of builds, speeding up incremental rebuild times substantially.

In addition to improvements made available to you within the Qt6 framework itself, we’d like to point out that the migration process itself can also bring benefits in the form of deeper knowledge of the structure and dependencies of your project. Even if you start the process and then back away after determining the scope is bigger than acceptable, you will likely have gained a few build-script clean-ups and a concrete understanding of which modules in your code could use the most remediation.

Consider Fortifying the Test Suites

Speaking of finding modules in your code needing remediation…

Sobering reality check: Updating Qt likely touches every layer and every file of your application. Even if some files in your codebase do not depend on Qt, you may need to upgrade your compiler, and in that case, the new compiler will certainly touch every file of your application.

This all-inclusive scope is why upgrades can be so dreaded. However, this is also why we claim they are a great way to shine a floodlight throughout your codebase and attain some valuable system-wide insights.

Here are the prelude steps, which have their own merit and can be done regardless of whether you proceed to upgrade to Qt6.

  1. Update your compiler to the latest recommended GCC, Clang, or MSVC.
  2. Enable maximum (or the highest you can pragmatically tolerate) compiler warnings. Here are some of our favorite settings: scripts and tools from our Qt/QML Project Template on GitHub
  3. Consider increasing your unit test and automated test coverage. (Note: once you read the next section, you might have better ideas about which specific areas of your app warrant more test coverage.) Automated performance tests are (as usual) also a good idea.
  4. Devise a plan for GUI testing. Some teams use Squish for automated Qt GUI tests. A written GUI test plan that can be carried out manually is extremely valuable. At 219 Design, we have seen high dividends from a simple approach of banning all QML runtime warnings.

Regarding QML warnings, this is a good place to mention that another benefit of Qt6 and CMake is the ease of precompiling QML to bytecode for performance purposes, which has the added bonus of turning some (though not nearly all) QML runtime warnings into build-time warnings.

Overall, think automation.

For a deeper look at how we recommend doing that, check out our blog post about automation and this one about testing.

Assess The Impact

Some projects will have a surprisingly quick and easy upgrade process. It can be as simple as a few class names edited with search-and-replace, then recompile, and your app launches on the first try.

Note: for reasons described above, you still want to subject your updated app to thorough testing—definitely including GUI testing—even if your upgrade appears to have succeeded trivially on the first build. GUI testing is always important, and doubly so if your app runs on any high-DPI displays. Verify that your GUI still looks as you intended on both high-DPI displays as well as dual-display situations as needed.

For projects that need more than simple search-and-replace fixes, here are the types of code impacts you can experience:

Renames:

  • QAndroidJniEnvironment renamed to QJniEnvironment
  • QTextToSpeech::BackendError renamed to QTextToSpeech::Error
  • and others

Changes to API:

  • QRegExp
  • QSignalMapper
  • and others

Removals:

  • QDesktopWidget
  • qSort
  • QList::toSet / QList::fromSet
  • and others

Changes in QML:

  • Replace DropShadow with MultiEffect (see https://forum.qt.io/post/766055 )
  • QML Calendar has been promoted out of Qt.labs.calendar into QtQuick.Controls
  • and others

Changes in GUI:

  • High-DPI scaling should now work out-of-the-box

Of course, the above is just a small sample of changes. There are many others. However, the complete story is spread across many Qt documents that cover many Qt modules. In the end, the best source of truth for identifying changes relevant to you is your own codebase. More on leveraging your own code in the next section.

If you are a documentation maximalist, there is a webful of additional links that you can read, starting from the Qt6 Porting Guide.

Assessment Tools/Tactics

One simple step that is readily available to you in Qt Creator is to enable the Qt6 porting readiness checks in clazy. Run these checks against your codebase to get a first rough report of how impacted you will be.

Note that you will run the clazy checks before upgrading to Qt6. You run the checks on a Qt5 codebase. Nonetheless, you are encouraged to use Qt 5.15 (the latest in the Qt5 line). Therefore, if you are using e.g. 5.8, you will need to do a mini-upgrade to 5.15 to guarantee maximum clazy effectiveness.

For instructions on how to run these checks, refer to: Porting C++ Applications to Qt 6 using Clazy Checks

You will also want to make a list of which Qt modules you use, and spend a few minutes in the Qt docs to assess whether each relevant module was removed or heavily modified between Qt5 and Qt6.

Here is where to look up upgrade/removal docs for each module:

Finally, it may sound pessimistic, but it’s pragmatic and diligent to search the Qt Bugtracker for open Qt6 issues tagged with whatever platform and Qt modules you are most heavily reliant on.

At this point, if you haven’t identified any show-stoppers, it’s time to point your project build dependencies to Qt6 and simply start compiling. 🤞

Until Next Time (Qt7, anyone?)

We hope this blog post demystified the Qt6 upgrade landscape, and we hope you are feeling emboldened thanks to the handful of tools and scripts that we linked to.

Qt6 is ready, and now you are, too. In short: you got this. 🤓👍️ If you’d like a little collaboration and support along the way, don’t hesitate to reach out.
Upgrades aren’t most people’s definition of fun, but completing one is definitely satisfying.

What 219 Design Can Bring to the Table

  • In our experience, there are a handful of reasons why you might not want to treat this strictly as a “we’ll do it ourselves” small exercise – especially in a regulated medical‑device context.
  • Codebase Size and Complexity: We recently upgraded several large codebases (on the order of hundreds of thousands of lines each) and discovered many “small” but cumulatively impactful issues.
  • Hidden Behavior/Regression Risk: Some changes build cleanly but produce changed behavior in runtime or UI logic. These are costly if uncovered late.
  • Build/Toolchain Migration: If you’re still using QMake or an older toolchain, the migration may involve a build‑system overhaul plus a Qt6 upgrade. Combining both can increase the risk and the schedule.
  • Regulatory/Validation Impact: In medical device software, framework migration affects traceability, change control, verification/validation artifacts, and potentially qualification of toolchains or architecture changes. Having a partner with experience in these contexts helps reduce risk.
  • Predictable Estimation and Risk‑Mitigation: Because we’ve done this multiple times, we can provide time and cost estimates to help clients budget and plan.
  • Cheat‑Sheets & Institutional Knowledge: We have experience and internal tools, so future migrations go faster to save your team time.

We can help!

Contact Us