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
.systemLibrarytarget instead ofxcframeworks, 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 few pitches 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?