wxWidgets or Qt: how to choose a desktop application toolkit

Consider wxWidgets for an application built around familiar windows, forms and operating system behaviour. Qt offers a choice between a conventional desktop interface and one designed for touch and dynamic views. Product requirements, the team's experience, and the cost of releasing and maintaining the application on the required platforms should guide the decision.

If you are commissioning an application for Windows, macOS or Linux, both names may appear in proposals. Developers use these libraries to build windows, buttons and responses to user actions, among other things. Choosing a library alone does not determine whether an employee can complete a task comfortably or whether your company can release the next version without difficulty. Those requirements need to be defined separately.

What does the user need to do?

Start with the tasks the product must support. For document work, these might include finding an item, editing a table, using keyboard shortcuts and printing. A touch panel may need large controls, a clear display of the device's status and easy movement between screens. This description gives you a better basis for assessing a developer's proposal than a general request for a “modern interface”.

wxWidgets uses platform controls and features, helping applications retain the familiar look of the operating system. That is a useful starting point when it is how you want the product to work. You still need to examine the actual screens: an interface that fits Windows may look different from one that fits macOS, and custom elements require their own development work.

With Qt, the proposal needs to be more specific. Qt Widgets supports conventional desktop interfaces, while Qt Quick focuses on dynamic and touch interfaces. Both can use a look and feel suited to the platform. “We will build it in Qt” therefore tells you little about the interface you will receive. The distinction is explained in the Qt user interface documentation.

If the product needs its own visual style, animated transitions and custom views, Qt Quick is worth assessing. The estimate should then account for the design of those elements and the team's experience in building them. Having animation tools available does not, by itself, make an application easy to use.

Cross-platform delivery includes installation and updates

The proposal should name the operating systems, versions and types of computer the application must run on. “Windows, Mac and Linux” is too vague to define acceptance criteria. Users need to be able to install the program, run it in their company's environment and retain their data after an update.

Check how the application works with the operating system: printing, file selection, the clipboard, multiple monitors, and keyboard or screen reader access where required. Shared code does not remove the need to check these functions on each agreed platform. In Qt, the libraries and additional components that must be delivered also depend on the platform and configuration.

Agree who will prepare installers and subsequent releases, and who will respond when the operating system changes. This brings maintenance costs into the comparison from the outset. They should not emerge only when the application works on the developer's computer but cannot be deployed to users' machines.

Licensing depends on the components you use

wxWidgets is available under the wxWindows Library Licence, which is based on the LGPL with an exception allowing compiled applications to be distributed on your own terms. This makes wxWidgets an option for closed-source products too. Before releasing a product, also check the terms covering other libraries and any modifications.

Qt offers commercial and open-source licensing options. Using the latter depends on meeting their conditions, and not every module is available under the LGPL. Building a commercial application does not, in itself, mean you must buy a Qt licence.

Ask the developer to specify the versions, modules, distribution method and associated obligations. If the plan requires a paid licence, its cost and the terms for continued use should be clear in the estimate. Having no library licence fee does not remove the cost of building the product, testing it or managing future releases.

Will one library be faster?

Without measuring the actual application, there is no basis for promising that wxWidgets will make it start faster or that Qt will handle its data better. Useful results for a buyer concern user tasks: how long it takes to open a document, filter a table or get a response while an import is running.

Consider a hypothetical team choosing a toolkit for a document viewer. The unresolved question is whether users can still scroll through a list and cancel an operation while data is loading. A focused trial of that scenario, using a representative file and the target computer, would help answer it. An attractive demonstration of an empty window would not.

The trial should resolve a specific risk. You do not need two complete prototypes when the requirements or existing code already justify a choice. If both proposals meet the requirements, maintenance costs and the skills of the people who will develop the product may matter more.

An existing application changes the calculation

If the program already uses wxWidgets or Qt, the cost of continuing to develop it is your starting point. Changing libraries also means reproducing behaviour users take for granted: shortcuts, settings, print output and error handling. These elements need to be included in the work and acceptance criteria.

Ask the developer to identify a specific limitation of the current application and compare two scopes of work: addressing it with the existing technology and rebuilding the relevant part. Keeping the current solution can be a sensible decision if it meets the requirements and has maintenance arrangements in place. We discuss the wider conditions for a change in our article on choosing Qt, Electron or Tauri when migrating an application.

How should a developer justify the technology choice?

A good proposal connects the library to the product's requirements. It should explain how the main screens will be built, which operating systems the tests cover, which licence terms apply to the release and who will maintain the application. For Qt, it should also state whether the developer proposes Qt Widgets, Qt Quick or a combination of the two.

You can then compare the scope, responsibilities and costs of the proposals. If the explanation stops at “wxWidgets is lightweight” or “Qt is more modern”, you still lack the information needed to approve the choice.