[Development] Qt Bridges Alpha Milestone

[Cristián Maureira-Fredes]

Hello everyone,

It has been a few days since we reached the first milestone of the Qt 
Bridges projects (not a full-blown release!), so I wanted to share more 
information about it, since the repository requests email took many 
people by surprise on what was this about.

If you already know about the project and are interested, I’d like to 
encourage you to visit the information that we shared in the Qt Forum, 
so you can try it out!

https://forum.qt.io/topic/164138/about-the-early-code-access-in-qt-bridges

The next steps are a Beta Milestone (planned for late March), and the 
Technical Preview for the end of May, but most likely we will keep you 
posted with the latest updates.

Below, there is more information that can be useful if you are curious 
about this new project we are developing within The Qt Company.



# What is Qt Bridges?

This project has been a research project by The Qt Company, that was 
publicly announced during Qt World Summit 2025. The objective is to 
bring more languages to the Qt ecosystem, by providing not a set of 
bindings to the Qt API but re-thinking the interaction between Qt Quick 
and other languages.

The whole idea is built on top of creating Qt Quick applications with a 
QML file defining the user interface details, and the logic implemented 
in other languages. The model is simple:

* QML is used to define the UI
* Host language implements the application logic (So far Java/Kotlin, 
C#, Python, Swift and Rust)
* Qt Bridges provide a small, idiomatic, language-native API to describe 
what data should be exposed to QML and signals interactions in a way 
that looks native to both sides.

We have learned by other binding projects like Qt for Python that 
maintaining bindings to other languages is a very complicated task, and 
creates a few cases when one needs to do interpretation of C++ idioms, 
types, and ideas that might not be straightforward to represent in other 
languages (the usual example I give is ‘What is a void* in Python?’). 
Another motivation is to hide that from users, by providing a new API 
that can do all that handling internally as much as we can.


# Who is the target audience of the project?

Considering the goal is to bring this to new developers outside our 
Qt/C++ community, the target audience of Qt Bridges are developers who 
have no Qt knowledge at all but are looking for a UI framework solution.

It’s expected that seasoned Qt developers will fall into the trap of 
trying to achieve the same they have been doing for a long time with 
Qt/C++ in Qt Bridges, but the most likely outcome is that it will not be 
possible. However, we invite you to share your ideas with us so the 
use-cases can be considered once we are evaluating new API.


# Why is this project aimed at being inside the Qt Project?

We believe this project will be a good way to introduce new developers 
to the Qt Project, and in some cases, they will get more familiarized 
with what we have and maybe explore the Qt/C++ offering we have, or at 
least being aware of so we could enable Qt Bridges to include further 
functionality.

Another important aspect is the introduction of new languages to the Qt 
Ecosystem, by establishing a way of continuing to expand them, following 
similar integration patterns.


# Is this aimed to be a new module for Qt?

No, this is not aimed at being an official submodule for the current 
qt5.git repository, but its own project. The releases are not planned to 
follow the Qt release schedule, nor interfere with the Qt releases.


# What’s the license for this project?

Even though Qt Bridges is not a Qt sub module, we wanted to still follow 
a similar license scheme, so we are planning to release Qt Bridges under 
LGPLv3 and Qt commercial licenses.

One of our objectives is that this can become part of the KDE Free Qt 
Agreement as well, to secure the Open-Source aspect of the project.


# Why does each language bridge need a separate repository?

So far, the project has been developed internally, on a mono repo, which 
has shown not to be the right solution, because in some languages, the 
root of the repository needs to contain certain files and configuration. 
For example, Swift requires a ‘Package.swift’ file; Python needs a 
‘pyproject.toml’ file.  For C#, work was already underway, based on a 
separate qt-labs repository, and with a broader scope than the current 
approach of Qt Bridges, such as allowing C++ code to call into existing 
.NET libraries.

We aren’t ruling out adding more languages in the future, so having a 
separate one is the best solution we found after some internal discussions.

We are using a meta repository qt/qtbridges to bring all the language 
submodules together for people that wants to develop accessing different 
languages bridges, and for the common project’s documentation (currently 
a snapshot can be found here: 
https://doc-snapshots.qt.io/qtbridges-dev/index.html ).


# How is this being released?

Since the goal is to approach different languages communities, our goal 
is to prepare packages/plugins and release them on their specific 
platforms (crates.io for Rust, Maven Central for Java, NuGet for C#, etc.).

Additionally, since we are aware the Qt users might still want to give 
this a try, we are settling the details for people to also download the 
project with mainstream Qt Installation process (from the 
Installer/Maintenance tool).


-- 

We really believe this is the right direction for extending our 
ecosystem and transforming Qt into an amazing language agnostic framework.

Cheers

-- 
Dr. Cristian Maureira-Fredes
Principal R&D Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--