As part of the on-going development of Qt Bridges, we are out with a new beta version of Qt Bridge for Rust, with a focus on CXX-Qt compatibility and soundness. The API surface has changed in only a handful of places compared to 0.2. Where it did change, it is mostly because we removed any API we could not make sound.

Shared Foundations with CXX-Qt

We already used the CXX-Qt build utilities to guarantee a basic level of compatibility. As of 0.3, we also use its basic types under the hood: `QString`, `QByteArray`, `QModelIndex`, the containers, the QJson types, `QGuiApplication` and `QQmlApplicationEngine`. The goal is to bundle the maintenance effort and keep CXX-Qt and Qt Bridge at equally high quality. It also moves us towards interoperability between the two, which has been on our roadmap since the public beta: we want both projects to coexist happily in the same application. The public API of Qt Bridge is not affected by this change, but we might expose CXX-Qt types where we see fit in the future. Allowing `QString` in slot and signal properties might improve performance by reducing conversions between UTF-8 and UTF-16, just to name an example.

Two practical notes: If you have trouble updating your project from 0.2, usually manifesting itself in a linker error, delete your `Cargo.lock` and `target` directory. Further, compile times increased substantially with the move to CXX-Qt. We are aware of this, and bringing them back down is on the list for a future version.

Soundness

We spent a good part of this cycle trying to break the framework, and then making it sound.

Any API we could not make sound was removed, for example the `as_qvariant()` function of `#[qobject]` user types. Internally and in generated code, many functions and traits are now marked `unsafe`, so that calling them is a deliberate act rather than an accident. We are rather confident regarding the other functions, with a few known quirks left to fix in future versions.

Failure modes got better behaved too. Emitting a signal or mutating an item model before a `QObject` is attached no longer panics. `include_bytes_qml!` now emits compile errors instead of panicking, and resolves paths correctly in workspaces with a nested `Cargo.lock`.

Ownership, Revamped

The ownership concept was completely reworked, and a registry that negotiates between Rust and QML lifetime requirements was introduced (thanks to a colleague dropping the idea during lunch!). A `QObject` is attached to `#[qobject]` user types on demand, and as a user you no longer need to call `default_with_attached_qobject()`.

The public API still bets on `Rc<RefCell<_>>` as the container and lifetime manager for user objects, so nothing changes for you there. In fact, this container's role has been strengthened considerably, and you can simply assume that an `Rc<RefCell<_>>` of any `#[qobject]` type is understood by the QmlEngine. Internally, `Rc<RefCell<_>>` is now responsible for the lifetime of user objects as well, reducing the potential for issues substantially.

We are also confident we can keep this API going forward, and we are very happy with that outcome.

Smaller Changes Worth Knowing

• `QmlRegister` is now `QmlElement`, and the user-facing instance API was moved from `QObjectHolder` into `QmlObject`.

• `Default` is only required for QML elements now, not for every exposed type.

• `#[qobject(LinkMe)]` became a crate feature.

• `invoke_method` resolves most-derived-first and matches on arguments.

• Concrete `T*` metatypes are exposed for `QObject` properties and arguments, and slot return metatypes are registered.

• `include_bytes_qml!` accepts directories.

• The minimum supported Rust version is 1.88 🦀.

Share Your Feedback with Us

Qt Bridge for Rust is still a beta, and your feedback is what moves it towards Technology Preview. We welcome any feedback in the forum, on Discord or on our bug tracker. You can of course also leave a comment here in the blog.

We will also be present at various upcomming conferences:

• KDE Akademy (19.-24.09.26),

• NDC Techtown (21.-24.09.26),

• EuroRust (14.-17.10.26),

• and of course Qt Contributor Summit (27.-30.10.26)

Catch us there to have a talk about Rust! 👋