Is Qt Right for Your Project?

Determining the right framework can be very difficult. Web resources often provide conflicting guidance or are subjectively based on a single developer’s perspective. Rarely does anyone create a substantial program in multiple frameworks that would allow a true comparison; creating a completely duplicate program of any complexity is very difficult and time consuming. It’s not surprising then that developers often follow the course of least resistance. Without a clear reason to switch, they default to language and framework of their previous project, reusing software that is already familiar.

Since the choice of a software stack is so important to guiding the project’s future course, it’s worth treating initial software selection as a strategic decision rather than the unconscious assumption that it can sometimes be. We have certainly done a good deal of Qt development and believe it’s a great tool. However, it’s not the only tool in the toolbox. In fact, there are occasions where it’s not a great fit.

When selecting a software stack for your project, there are 8 factors we recommend that you take into consideration:

1. Existing Codebase
2. Skills and Availability
3. The Target Platform
4. User Interface Requirements
5. Remote Access Requirements
6. Vertical Markets
7. Tool Interest and Longevity
8. Business Strategy

1. Existing Codebase

How much code do you already have? Is it cleanly factored, well documented, and can it be easily reused? Existing development is a consideration that can often overwhelm other decisions. Just remember that if you have a lot of spaghetti code that can’t easily be reused, it shouldn’t carry the same weight as solid, reliable, and modular code. Qt and C++ is not exempt from this consideration; you can inherit terrible code written in any language. Don’t let an existing legacy hinder you from making a clean break to a newer, better approach.

On the other hand, existing codebases carry a lot of knowledge and experience with them. This is often not encoded in documentation or comments but is the result of maturation over a long period of time and the accumulation of many decisions, workarounds, and fixes. Starting from scratch with a new framework or programming language carries the risk of repeating mistakes from the past. As ever, weighing these aspects is not a black or white decision and requires nuanced and careful consideration.

2. Skills and Availability

The talent pool for expert programmers in a particular framework, language, or domain can be a significant factor when deciding on tools. This is especially true for a language as powerful and nuanced as C++. We’ve found, throughout our years of training developers from diverse backgrounds, that Qt tends to tame the complexity of C++ and enables programmers of many levels to be productive. The ability to make developers of different skill levels effective contributors comes from Qt’s cleanly-structured design and complete library, along with QML. Due to its similarities to JavaScript, QML makes user interface development dramatically simpler and closer to web-based development. Even with this acknowledgement, it still remains hard to recruit high-quality talent that is able to tackle the challenging areas of Qt and C++: optimizing, modifying plumbing, or extending and customizing. Outside of Qt, it is easier to fill jobs for web-based technologies. If your project primarily sticks to the basics, going outside of Qt could be of benefit. However, if you need to dig under the hood of your web-based framework, you may be in the same situation. Excellent people are rare, regardless of the language. The importance of talent pool and language choice will vary, depending on your industry, locality, and ability to compete on salaries and other benefits.

3. The Target Platform

Since most tools shine in some environments but not in others, the platform that your application targets is a major consideration. One of Qt’s strengths is building cross-platform applications. However, while it provides an acceptable UI for all platforms, it won’t be fine-tuned for each platform. If you are only building mobile apps, for example, you may want to consider a framework that specializes in cross-platform mobile development, like React Native or Flutter. Similarly, if you’re only targeting one of the two mobile environments, Apple iOS or Google Android, you may want to investigate the best tool for each environment – Swift or Kotlin, for example. Moreover, if your app has a desktop and web-based interface, it may make sense to use an HTML5-based tool like Electron that can more easily cross the gap between the two environments. Finally, the size of the processor can introduce serious constraints.
While an ARM microprocessor can run nearly any modern toolchain, microcontrollers have a number of constraints and can be more
limiting in your language and framework choices. Qt offers a optimized version to target microcontrollers, but it might still require a big focus on performance to make your application work well. You’re probably better off picking a smaller lighter-weight framework that’s designed to go into small applications like Crank Storyboard, if your main focus is on the low end of the hardware performance spectrum.

4. User Interface Requirements

What does your application need to display? Simple text? Responsive mobile pages? 3D graphics? Complex visualizations? The sophistication of your graphical needs can be a big driver in selecting an appropriate programming environment. If you can live with console input and text output, nearly anything will do. If, however, you’re building a lot of sophisticated graphs, you may want to consider a language with extensive data visualization libraries like R, Julia, or Python. Then again, if you’re looking to do 3D manipulation or integrating 3D graphics into 2D UIs, that’s an area where Qt really shines; web-based technologies will likely struggle in these types of applications. Because of its ability to create software closer to the metal, Qt also does very well in areas where data management is paramount, such as scientific applications, high-throughput measurement systems, or real-time data collection.

5. Remote Access Requirements

If remote access is required, web-based solutions can often be a natural choice. The upside is that development will naturally use a
browser interface, making remote browser access identical to local access. However, this benefit is also a downside since web technologies are constrained to the browser, making it difficult to create an optimal desktop experience. It’s possible to create a tailored desktop and remote UI with Qt, as it has become very versatile in being able to support remote and browser-based UIs through WebAssembly or WebGL. The requirements of remote access should be considered. Will it be used for control more frequently than local access? Is it for maintenance support? Is it for training, oversight, or administration? Based on the frequency of use, UI needs, and flexibility, you can make a more detailed assessment on whether Qt or web-based tools are better for your remote access requirements.

6. Vertical Markets

The market for your product may impact the toolkit you want to use. Sometimes a particular tool chain has a strong foothold in a particular area like automotive or point-of-sale applications. Having access to open source libraries, third-party expert consultants, pre-existing software stacks, and third-party offerings can help shortcut the development process. Development using uncommon tools in one of those areas can mean that your team will need to reinvent the wheel for common protocols or hardware devices.

In some vertical markets, the application will need to directly access hardware. If all hardware components are off-the-shelf and have
properly encapsulated drivers, then this won’t be a problem, regardless of language. However, custom hardware is often found in industrial or robotics designs, making them challenging to use in programming environments that use a virtual machine such as Java
or web-based technologies.

The final constraint that vertical markets may impose are software lifecycle, development, and quality standards that must be met for regulation and safety reasons. You’ll want to pick a language and toolset that is familiar to certifying agencies and doesn’t introduce any problematic concepts like unprompted garbage collection. While the specifics of each standard differ, similar characteristics will apply to medical devices that need IEC 62304 certification, automotive systems that comply to ISO 26262, and industrial systems that require IEC 61508 compliance.

7. Tool Interest and Longevity

Is the language you want to use “hot” in the development community? A tool’s popularity may tell you how easy it will be to have programmers join your team. “New and exciting” needs to be balanced with stability; don’t pick something that’s so new it is undergoing continual refinement and requires changes throughout the code base on each subsequent tool release.

Another measure of developer interest is the community size. If your tool of choice has a large and active forum on Stack Overflow or
Reddit, and ongoing projects on GitHub, you’ll know there are plenty of programmers interested and contributing in that space. Newer tools may have a lot of interest but fewer practitioners and smaller online communities.

Another measure of desirability is lifespan. Languages and tools that have been around a long time have proven their worth and have lived beyond obsolescence. Finally, is the software easy to maintain? The more maintainable the code base, the longer the productive lifespan – you’ll be able to keep the code fresh and reusable across multiple projects.

While maintainability is often as much about programming style and documentation standards, tool characteristics can help or hurt maintainability too. Development environments that contain a hodgepodge of techniques and paradigms make it very difficult for a developer to know where and how to fix a bug or extend functionality without breaking existing code. Tools built on web standards can be difficult to modify with a combination of HTML5, JS, CSS, and custom JavaScript frameworks. However, Qt applications can also suffer from this problem due to the mix of C++, QML, and Qt libraries. Finding tools that can easily integrate unit testing into the development process can help maintainability and should be a priority for modern development.

8. Business Strategy

Often, development tool choices are not considered by anyone outside of the engineering department. However, with the additional
impacts that software tool choice imposes on hiring talent, available consultants, the cost and availability of third-party libraries, codebase longevity, and product stability, it is wise to make these strategic decisions with input from the whole team. Certainly, you want your programmers to feel the choice of development tool is a good technical fit, however, engineers may not be as aware of all the other downstream considerations – just as management, HR, leadership, or other corporate areas may not fully understand the technical aspects of software selection. Bringing all parties to the table to create an open dialog for selecting critical software tooling will ensure that such decisions not only help the immediate product development but also support the company’s longer-term considerations.

Summary

As you can see, there’s a lot to consider when making your initial software selection. While Qt makes a lot of sense for a good number
of projects, it’s not the only kid on the block. We have lots of experience helping customers evaluate whether Qt is the right choice for
a project. We know all about the framework, its license options, its strengths and weaknesses, and much about other possible choices. We have seen people pick Qt and succeed but we’ve also seen people have problems. We can help you structure your decision-making process around the software options that might be the best fit for you and give you the necessary guidance to head in that direction.