There are significant updates in Qt 6 that also impact the underlying way in which the development host OS and target OS are supported. The most significant changes affecting development hosts and targets include how Qt integrates to the graphics system (Blog: Technical vision for Qt 6), the C++ minimum version update from C++ 11 to C++ 17, and the transition from QMake to CMake. We have also taken the opportunity to clean up and reorganize quite a few OS-specific bits (Blog: Qt 6.0 feature freeze).
Host operating systems in Qt 6.0
Qt 6.0 will be supported on development hosts familiar for Qt 5 releases; Windows, Linux, and macOS. For RedHat Linux users, the biggest change is the move of RedHat to CentOS in CI. For developers using Windows, only 64bit Windows 10 is now supported as a host. Additionally, there are minor updates with the latest host operating system versions (with new versions being added and older versions being dropped.)
A list of the planned Qt 6.0 development hosts in our CI and testing can be found here:
- Windows 10 2004 (64bit Intel; msvc2019 or mingw81/gcc8.1)
- macOS 10.15 (64bit Intel; XCode 11)
- Linux:
- Ubuntu 20.04 (64bit Intel; gcc9)
- CentOS 8.1 (64bit Intel; gcc9)
- SLES 15 (SUSE Linux Enterprise Server, 64bit Intel; gcc10)
- Open SUSE 15.1 (64bit; gcc9)
Other operating systems and versions may well work, but those listed above are part of our CI and verification activities. For Technical Support to accept issue tickets, the issues need to be reproducible on one of the supported hosts, or there needs to be a corresponding, customer-specific, additional service to cover the issue.
Development targets supported in Qt 6.0
In order to ensure that we can focus on the essential key features, we have limited the number of development targets, and cross functionality for what hosts can be used for those targets, in Qt 6.0. This means that there will be a gradual addition of targets through Qt 6.0, 6.1, and finally 6.2 (where the plan is to ensure Qt 6.2 is on par to be compliant with the wide range of supported target platforms in Qt 5.15 LTS.)
Naturally, all development hosts listed above can act as targets. Additionally, Windows 10 1809 64bit and macOS 10.14 and 11 (formerly a.k.a. 10.16), when available, can be targeted.
Embedded Linux meta-qt6 layer is created for Yocto 3.1 Dunfell (and gcc9.3). Qt 6.0 comes with four ready-made Boot-2-Qt images for ARM-v8A 64bit (iMX8) and ARM-v7A 32bit (iMX6) based devices. One should be able to bake Qt6 support on a wide range of hardware with the new meta-Qt6, and if needed Qt Professional Services can always jump in and help. There will be more details on the new meta-Qt6 in a later blog post.
Qt 6.0 will support development for mobile targets on iOS (13 and 14) and Android (28 build-time, 21 runtime).
Development hosts and targets in Qt 5.15 that are not planned in Qt 6
In addition to documenting what will be changing, it is also important to communicate what will be discontinued or will no longer part of our CI and verification efforts.
Both Windows 7 or 8.x version support will not be available for Qt 6. Microsoft discontinued the support for both Windows versions some time ago, and as a vendor, we can no longer maintain support for these windows versions in Qt 6. Windows 7 (both 32bit and 64bit) was supported as a target in Qt 5.15 LTS and Windows 8.1 (both 32bit and 64bit) as a target in Qt 5.12 LTS. This means that we will not have 32bit Windows support available. Additionally, it will no longer be possible to create UWP applications on Windows 10.
Apple watchOS and tvOS are both also dropped from CI due to low interest and the need to free up resources. We would like to hear if you have projects depending on these targets.
The Qt community may very well maintain support for these and other environments. As usual, there is also a commercial opportunity for customers to purchase additional, extended support for dedicated hosts and targets.
Development hosts and targets planned for later 6.x releases
Windows on ARM based PCs instead of traditional Intel based PCs is under work (QTBUG-85820). The ability to support it as a full-blown host and target may take time, but the initial focus is to enable Windows on ARM as a target for desktop applications.
The support for macOS on ARM (instead of Intel-only) based HW is being worked on (QTBUG-85279) and planned for Qt 6.1. This will also cover macOS as a development host. The DIY folks may find significant parts of the work already covered in Qt 6.0.
Adding macOS as development host for embedded Linux based targets requires changes to how we create and maintain cross compilation toolchains. We plan to include containers for the cross compilation tooling host. This work is currently roadmapped into Qt 6.2 (QTBUG-81947). This same work will also impact how embedded developments target support is implemented on all hosts.
For Yocto Embedded Linux, we will follow the Yocto roadmap. Qt 5.15meta-qt5 is with Yocto 3.0 Zeus, Qt 6.0 meta-qt6 layer is with Yocto 3.1 Dunfell, and it looks like Qt 6.1 will move to Yocto 3.2 Gatesgarth. Correspondingly, Qt 6.2 most likely will be with Yocto 3.3 (depending on how the roadmaps align). The Yocto community introduced the 3.1 Dunfell as an LTS release, so we may still revisit this plan whilst moving along with the latest and greatest release. The plan for this area for Qt 6.1 and 6.2 is still open to alteration.
Real-Time Operating System (RTOS) support for Blackberry QNX and GreenHills INTEGRITY is mostly pending on vendor compiler support for C++17. The current plan is Technology Preview (TP) level support in Qt 6.1, and full support in Qt 6.2. Windriver VxWorks schedules are open as of writing this blog. RTOS support is a special breed for support; Qt comes with a reference implementation on a specific HW+RTOS combination, but most customers have something custom as the platform. Therefore, it is always recommended to work with Qt Professional Services for full support in this area.
Finally, WebAssembly (a.k.a. WASM) will be back in Qt 6.1.
Detailed planning in JIRA - Waiting for your feedback
You can follow the detailed planning & progress in JIRA under Epics:
- Qt 6.0 development hosts (QTBUG-85851)
- Qt 6.0 development targets (QTBUG-85855)
- Qt 6.1 development hosts (QTBUG-86432)
- Qt 6.1 development targets (QTBUG-86433)
Looking forward to your feedback, input and contribution!
Commenting for this post has ended.
Any chance for Clang/LLVM on windows ?
Which variant do you have in mind?
Same as what google use for Chrome now. So we will be able to build whole qt+qtwebengine with free compiler on windows
Windows + Clang is planned under Qt 6.1 here https://bugreports.qt.io/browse/QTBUG-86432
It's a bit too early to completely drop off UWP in Qt6. AFAIK Microsoft doesn't yet support delivering traditional desktop apps to the Microsoft Store. Maybe after Project Reunion it will. Maybe it won't. Until further announcements from Microsoft it might make sense to skip UWP for Qt 6.0 and Qt 6.1. But if they still don't support delivering traditional desktop apps to the Microsoft Store by spring 2021 or don't announce anything new, it might be a good idea to bring UWP back in Qt 6.2.
Nevertheless it's always better to under-promise and over-deliver than to over-promise and under-deliver.
Microsoft supports traditional desktop apps since a few years (they even provide a converter app which automates packaging).
For the Store on PC, yes. However, if you want to run on Xbox, HoloLens, or Surface Hub, UWP is the only game in town.https://docs.microsoft.com/en-us/windows/apps/desktop/choose-your-platform says (emphasis mine):
Even though it might be possible to develop Qt applications for Xbox, HoloLens or Surface Hub, we haven't seen much interest from Qt users. While HoloLens and Surface Hub applications with Qt might make sense for some people, the Qt framework probably is not the first address for people who want to develop Xbox applications/games
@Peter Staab, Have you published a Qt app on the Microsoft Store using Desktop Bridge (converter)? Or do you know any such app?
--
The reason for low adoption of UWP is monetization. For e.g. as of this year, Microsoft shut down their own ad platform for Windows UWP apps. However you can still sell in-app purchases. So the monetization opportunities are still there, but they're quite limited. But with traditional apps it's even worse, because you cannot include Qt Purchasing into them.
So far I got 60+ apps published on the Microsoft Store with a focus on Windows 10 Desktop and I plan for more. If 1) Microsoft opens up their store to traditional apps, 2) allows in-app purchases into traditional apps and 3) Qt supports Qt Purchasing in traditional apps ... I think I won't miss UWP that much.
Windows 8.1 is still supported by Microsoft (for free) until January 10, 2023. It is most certainly not out of support. It still receives security patches every Patch Tuesday until that EOL date. See https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
Are you perhaps confusing it with Windows 8.0, which is in fact out of support?
I'm not sure I follow this.The current Supported Platforms page has both 32-bit and 64-bit support listed for Windows 10. I don't understand how dropping Windows 7 and Windows 8.x support would impact whether 32-bit support remains on Windows 10. Can you clarify this?
Hi Cameron,
We are not confusing Windows 8.1 with Windows 8.0. As you pointed out yourself, Windows 8.1 is in Microsoft's "Extended Support" phase until 2023. That means that the operating system gets security updates, but not much more is promised by Microsoft. That basically reflects what Qt's LTS versions are about. Having 5.15 available as an LTS version of Qt means, that the Qt applications you are running with that version on Windows 8.1 will get security updates until 5.15's end of support (which will also be in the year 2023 if I am not mistaken).
The end of 32 bit packages for Windows was perhaps phrased a bit unfortunately by Santtu. The decision no longer to support 32 bit on Windows was done deliberately from the Windows version support. This decision does not mean that we will actively remove support for 32 bit on Windows though. Having a platform as "supported" means more than "it works by chance". In the end it all boils down to resources. Windows platforms traditionally do not have the strongest focus on open source projects, so the majority of Windows work is done inside the Qt Company (that's my gut feeling). Interest in 32 bit packages on Windows has been decreasing over the time and we reached a point, where it no longer makes sense to invest into this architecture on Windows any more. These investments are not only measured in man power, but also computing power. We cannot just add more and more systems into our CI system. In order to bring new configurations there, other configurations have to be removed. Summing that up: It is possible, that 32 bit Windows builds of Qt6 will be possible, but as there will not be any CI coverage, we cannot be sure of that.
Extended support is still support, though. You can still request non-security fixes provided you have a support contract with Microsoft (and even during mainstream support, good luck getting non-security fixes without a support contract). Source
Besides, by that logic, Windows 7 support would have been dropped back in 2015 after it entered extended support, yet Qt maintained support for Windows 7 up through the end of extended support this year. There must be more to it than that.
Well it means that for commercial customers. As an open source user, I only get support for 5.15 until Qt 6.0 is released as far as I understand.
Understood. Thanks for these details. Maybe I can use this as an excuse to drop my 32-bit Windows support ;)
If you have a support contract with the Qt Company, you will get the security fixes you are asking for and you can request other changes via your support/sales channels. You can request changes for Windows 10, but they do not guarantee that every fix you are asking for will land in their product. This is basically the same The Qt Company offers.
Windows 7 had a much bigger market share for a much longer time so we decided to keep it for a longer time. The situation is different for Windows 8.1. There does not seem to be too much interest, so we are doing that cut for Qt6. At least as far as I know, there is not "more to it than that"
This is what I meant by there being "more to it" than just being in extended support ;)
Thank you for the info.
As a the developer of a GPLv3 app using open-source Qt, the loss of platform support in Qt 6 puts us in a bit of a bind considering that Qt 5.15 will only be supported for open-source users until Qt 6.0 (plus your roadmap doesn't estimate platform parity with Qt 5 until Qt 6.2). For example, WebAssembly developers using the open-source Qt have literally no way of running a supported Qt version during 6.0's life because Qt 5.15 support is gone for them and Qt 6 doesn't support WebAssembly yet.
I prefer to always ship the latest Qt version (and have even shipped a Qt 5.15.1-based release already) and regularly report bugs against the latest releases. Seemingly, I'm the exact active open-source Qt user that you are trying to encourage with your policy to end LTS support for open-source users. However, the platform support loss actually prevents me from continuing this, because I have users on Windows 7 and 8.1. I am stuck without being able to use a supported Qt build after Qt 6.0 releases, until I decide to drop Windows 7 and Windows 8.1. All other open-source Qt applications will be in the same situation (Wireshark comes to mind).
I understand the complexities of developing against an 11 year old OS, and I'm not asking you not to drop support for Windows 7 in Qt 6 or anything like that (though not dropping Windows 8.1 would be nice given that it's actually still supported by Microsoft until 2023). However, due to the lack of platform parity with Qt 6 (especially for WebAssembly developers), would you consider offering Qt 5.15 LTS builds to open-source users at least until Qt 6.2 is released? Dropping Windows 7 in 2H 2021 is more palatable, since Windows 7 Embedded POSReady remains supported until October 12, 2021.
Seconded, would like an answer to this please. We're in exactly the same situation as open-source users of Qt.
Thx for the info!
Is there any technical reason for dropping Windows 7 support? Will Qt 6 run on it when compiled from source?
Online Installer freeze on 64-bit Ubuntu 20.04 and 22.04 (VirtualBox VM's on windows 11) during install of gcc 64-bit. Not sure what I'm missing here.
I'm late to the party, but I'd mirror my tweet here: Qt 6 is cancer. When it's not an app that stops supporting Windows 7/8, not even a browser, but a mere UI framework, there's nothing screaming incompetence of its makers more than that. Don't use that crap.