Qt Bridges: Modernizing Software Design and Development

During Qt World Summit ‘25, we announced our new initiative, Qt Bridges, expanding the software design and development capabilities of Qt Quick and QML, allowing them to be used with more languages, starting with Python, .NET (C#), Kotlin (Java), Swift, and Rust.

Following this, Vladimir Minenko did a great write-up on the history, the plans, and what we are building towards in his blog, Qt’s New Bridging Technology - Looking Back to Move Forward. For those who haven’t had a chance to read it yet, I highly recommend it before going any further. I wanted to expand on this a bit and explain what makes it so exciting, not only for current Qt users but new ones as well.

Qt Bridges from a Product Manager’s Perspective

Over the years, I have been involved in a few different companies, all with substantially different products. Still, one thing that always seemed to remain was the amount of time, repetitive work, and artifact passing that was required to get from an idea to design to product. Let me take you through one concrete example to explain what I mean and how Qt Bridges could have helped us.

It is very rare for a company to consider fully rewriting its existing applications to unify its code base. This typically only happens when there is a very clear benefit to doing so, and even then, it is rarely chosen as the best option. This means they are not looking to start from scratch but would need ways to simplify and streamline their software design and development in other ways. This is where I see Qt Bridges as the perfect enabler to make their work easier, improving user experiences, adding velocity to development, and bringing in new capabilities, all while making the fewest code changes possible. But this isn’t just a hypothetical example; let me tell you about one concrete example from my past.

Setting the stage

The Team Topology:

We had 3 teams, 2 for our mobile apps (Android & iOS) and one focused on the companion device, which used a company-shared backend. Additionally, we had a dedicated designer who was a part of the design unit, responsible for a unified design system used by all the products across the company. In addition to our product that was exclusively mobile, there were about 5 more complementary products, all mixing mobile and in some cases desktop versions of their applications.

The Workflow:

When we were looking to address a new use case, we started with both platform leads, our team's architect, and designer. We would go over the problem, review the user flow, look for solutions, consider platform-specific features and limitations to ensure a consistent experience was achieved, and ultimately come up with a prototype to test. If it utilizes a specific element or sets of elements in the design system, our UX designer would make the product design, and if not, they would review with the design team around the need and our proposal; and then incorporate it if there were no reasonable alternatives to achieve the same solution with existing assets.

Once we had the final, tested design in Figma, the teams were able to get to work implementing it in each of their respective versions of the application, and if needed, also make the changes to the backend and companion devices functionality. This often meant reusing the components currently in our app, but if they were done for a different product, recreating the element within our team…twice.

Then we would go through the typical validation with our designer until it was ready. If down the road any of the other teams were looking for a similar solution, they would be in for the same process, and worst of all, was when the design team made the decision that they would be revisiting the entire design system based on a brand refresh…

How Qt Bridges Could have Improved our Software Design and Development

Our design team, like so many others, worked in Figma. Creating components, styles, etc., all of which would then be selected and reused by teams, and when an update was made, it was propagated across the products, and each new component or element was yet another tool in the design team's toolkit. This is the way all design teams either work or want to work, and the tools they use, i.e. Figma, are heavily pushing the concept since it can dramatically improve design teams’ work.

But much of the friction arose since the Product and R&D teams didn’t work in this way, due to well-established products using, as mentioned earlier, a range of different technologies for different platforms, all having to create and recreate these “universal” items such as buttons, slider, or even more complex components like a sing-in workflow which consisted of 5+ different screens depending on the user and success or failure points.

Where Qt Bridges makes me most excited is that it allows Product and R&D teams to work in a more unified way with designers and to reduce duplicate work, decrease time to market, and make iterations easier by reimaging how software design and development takes place. Once there is a design in Figma for a component (i.e., the sign-in flow), it can be created in Qt Quick & QML, and then all teams would not need to recreate all the buttons, loading animations, images, fallbacks, etc. for each product and platform. They could use the standard component and connect it to the underly logic within the app and only make minor modifications to meet any product specific changes.

Starting New Products with Software Design and Development in the Forefront

The above example helped to highlight just one example of how Qt Bridges could help existing companies and products, but what about new products that haven’t even been created yet, by teams that don’t exist, using workflows that are just emerging?

The potential value of Qt Bridges is just as big here, if not even larger. Individual developers can use, reuse, and expand components they create, which are included in the Qt Framework, or are even shared within the Qt Community. Focusing first on the problem they are looking to solve, and once they have established something worth testing start to implement the interface.

Regardless of their software design or development, they can simply pull from their “component” toolkit whether it’s an AI-powered application using Python, an indie game in C# needing a menu, or even an embedded device using C++.

Additionally, as software design and development workflows change, the same components can be utilized, whether it is done directly by the developer or as part of the developer’s toolkit, improving the overall quality, consistency, and ultimately sustainability of the application for the team or developer into the future.

If you are also excited about Qt Bridges and want to get all of the latest updates, be sure to sign up here. If you're new to Qt and would like to see what Qt Quick and QML are all about, have a look at our free, fully functioning examples here: try.qt.io

changed to consider