We've been working on bridging Qt Quick to Swift and we're at a very early stage of development right now. Things are rough around the edges and features are limited, but at this point, we're mainly trying to gather some feedback from people who enjoy experimenting with new tools. We're very much testing the waters and trying to learn from real users before going further.
If anyone’s interested in testing it and sharing some thoughts, we’d really appreciate it!
HI I've been very eager to try it out ever since its announcement and have been tinkering with it when it came out.
However I noticed that currently it only supports Apple Silicon. Am I correct in assuming the main reason for this is because qtforswift provides the libraries as binary artefacts via xcframeworks?
I wondered how much effort it'd be in getting it to work on linux so I gave it a shot. SPM has experimental support for xcframeworks on linux via
swift build --experimental-xcframeworks-on-linux
in newer versions( I tested with main-snapshot-2026-01-09). So by essentially just adding linux binaries alongside the macOS ones (i.e) :
Now this might not be the ideal solution, but to me it shows that getting it working is relatively trivial.
AFAIU, the point of that flag is as a means to transition to SE-0482, which notably should also support Windows. There might also be considerations around whether the binaries should be provided via qtforswift or linked from the user's system Qt installation.
This is all to say: are there any actual plans to officially support qtbridge-swift on other platforms outside of Darwin?
Also, on another tangent—would it be possible to get CMake support for qtbridge-swift?
Can you speak a bit about why you chose the Quick/QML route, rather than having Swift integrate directly with Qt's C++ API? I've played around with some of the other Swift/Qt experimental projects (like GitHub - kkostov/QwiftUI: Experiment to create a Swift UI library based on Qt6), and it seemed to work fine in principle.
It feels to me like this would be an ideal application of Swift's C++ interop capabilities.
Hey! Thank you very much for looking into this and for the input :) We really appreciate it!
For the alpha version, we decided to go with Apple Silicon only, but we definitely want to add other platforms as well!
Am I correct in assuming the main reason for this is because qtforswift provides the libraries as binary artefacts via xcframeworks?
Yes, but we might be able to follow your steps to add Linux support. Thank you again :)
There might also be considerations around whether the binaries should be provided via qtforswift or linked from the user's system Qt installation.
We were considering using a .systemLibrary target instead of xcframeworks, but faced a few problems with that:
We rely on private Qt API for the Qt Bridge implementation, and it seems we cannot easily expose additional private header paths. For example: <QtCore/private/qmetaobjectbuilder_p.h>
QmlEngine needs to load runtime plugins, and it is also unclear for now how to load them correctly from the system Qt installation. For now, we simply put them in the qtforswift package, but this is also not a perfect solution.
Are there any actual plans to officially support qtbridge-swift on other platforms outside of Darwin?
Yes, there are plans to do that in one of the next versions! Thank you for the interest in this
Also, on another tangent, would it be possible to get CMake support for qtbridge-swift?
This is actually something we have not discussed yet, but we will consider this for the future releases Would it be more convenient to use CMake instead of SPM?
Private Qt libraries are just another CMake target - or, in this case, shared library object. You should be able to import this, however API stability isn’t guaranteed since it’s a private API.
Really excited for this! I can finally replace my shitty C++ codebase with Swift! Can I do something to help with the development of this? I only have Windows/Linux though
To broaden the context, The Qt Bridges project is targeting multiple languages, not only Swift. While for Swift an impressive job has been done when it comes to C++ integration, the story is more complicated with other languages. By focusing on QML, we reduce the surface of C++ interaction that is required.
There are also couple more reasons for that choice:
Quick is a modern UI framework for today’s user experience expectations, while Qt Widgets is a great imperative framework that however doesn’t meet modern requirements for UX designs or programming paradigm. So while widgets still has a compelling feature set for desktop applications, Quick is a better fit for both mobile and embedded.
We have a quite a lot of value-add on top of QML (with e.g Figma to Qt, 3D tooling, etc.). That tooling works with “pure QML” files, so can be easily reused in the context of Qt Bridges. For Widgets, we have of course “Qt Designer” as a trusty tool, but that only really works with C++, or (thanks to a larger amount of work) with Python. Porting it to all other languages would have been quite an undertaking.
While it is possible to have a well-defined split between the UI and backend code with Widgets, it’s more strictly enforced with QML/Quick. That also means our documentation for QML is mostly C++ free, and can be reused without much porting in the context of Bridges.
I hope this clarifies our choice a bit, and I’m happy to discuss it further if you’d like :)
Private Qt libraries are just another CMake target - or, in this case, shared library object. You should be able to import this, however API stability isn’t guaranteed since it’s a private API.
We don’t support CMake yet, only Swift Package Manager. SPM’s .systemLibrary target relies on pkg-config files that provide include paths and linker flags. Currently, there are no .pc files that expose the private include paths for Qt modules.
Can I do something to help with the development of this?
Yes, contributions are welcome!
Development is ongoing in this repository: https://code.qt.io/cgit/qt/qtbridge-swift.git/
Contributions to the Qt project are handled through the Gerrit code review system. Please read the Qt Contribution Guidelines to learn more :)
Also, please note that development is still at an early stage, and things may change or even be removed later. If you plan to contribute a larger patch, it’s best to synchronize with us on Discord.
Currently, the implementation does not use or depend on SwiftUI. The frontend in our solution is UI code written in QML and using the Qt Quick framework. QML is a declarative language for building user interfaces, conceptually similar to SwiftUI’s declarative approach.
The goal of the Qt Bridge for Swift is to provide a simple API that makes it much easier to integrate Swift backends with a Qt Quick UI, removing the need to write or deeply understand various Qt APIs. Even though we don’t provide full Qt bindings, many Qt features and tools can still be accessed through QML.
I was a tad worried that this would just be stuck on Darwin indefinitely. It's a delight to hear there are plans for expansion
This is actually something we have not discussed yet, but we will consider this for the future releases Would it be more convenient to use CMake instead of SPM?
On this topic I think reasons can be put forward that range from nice-to-haves to more compelling that tend to centre around cross-platformness.
@keeshux has written some very thorough blogs on porting his passepartout project to Android and one of the main things was that, currently, SwiftPM just isn't there yet.
Similarly, there's other hiccups when it comes to Windows and, at that point in time, The Browser Company built all their stuff with CMake because of it.
We were considering using a .systemLibrary target instead of xcframeworks , but faced a few problems with that:
I'm not extremely familiar with Qt's private API but I would assume those two issues are things that SwiftPM isn't well equipped to solve at this moment. But, as noted above, CMake can link with these removing the need for binary artefacts.
Of couse, SPM is evolving rapidly. With the new build-system being put in place and a fewpitches and discussions. There could be a world where QtForSwift is a cmake project that just gets imported in Qt Bridges
Other conveniences are the usual helping incremental adoption in projects
Really excited for this! I can finally replace my shitty C++ codebase with Swift!
A lotta swiftlang projects like swift-syntax(which is coincidentally a dependency of QtBridges) support both SPM and CMake etc.
I fear I could go on and on but I think I've said enough as is.
I've been working on adding cmake support in my own branch and it successfully works on macOS and Linux(tested on Ubuntu and Fedora) with the system's Qt installation and should in theory work fine on Windows or other platforms like OpenBSD or FreeBSD. Is this feature something you'd be happy with being upstreamed?
@zaph Thank you for the detailed and thoughtful response! Of course, we’d be happy to merge your patch with CMake support. I’ve tested your branch on macOS for now, and we can also test it on Windows and Linux
Thanks a lot for contributing!
Would it be possible to add your changes as a Gerrit review? Unfortunately, we can't merge changes on GitHub. You can check the Qt Contribution Guidelines for detailed instructions. Some of the steps there apply only to the main Qt repository, though, and we’re working in a separate one. If you run into any issues, please feel free to reach out to us on Discord in the 'swift' topic :)
I just wanted to add to @Magdalena’s reply a general note about Qt Bridges. Using QML and Qt Quick is a part of the concept. Qt Bridges considers languages and their frameworks as "headless” backends implementing the application logic, and Qt Quick as a pure frontend layer. Qt Bridges is also not a yet another binding for the entire Qt. It is just only what it name tells: a bridge between the application logic and frontend. Yes, this brings some limitations, but also several benefits, especially that you do not need to refactor your backend code to connect it to the frontend. This is actually the case for almost all binding-based languages integrations. And if the app uses some of the modern, MVVM-alike approaches, using Qt Bridges would not be a big change at all.
Would it be more convenient to use CMake instead of SPM?
I was a tad worried that this would just be stuck on Darwin indefinitely. It's a delight to hear there are plans for expansion
but I think I've said enough as is.
