I would love to help, but the time I can afford to spend on this is unfortunately quite limited at this point.
I can try to add more modules and see if it works, but this post here made me think this might be a somewhat of a dead-end approach.
There’s talk of “modern CMake”. I never worked with CMake and so I have no clue how to pick this up, my focus is on Swift and I have some interoperability code to be able to use VTK through C++.
In the thread I linked there was talk of XCFrameworks. These are a sort of container that packages a binary library for multiple architectures, and their associated headers.
So potentially you could have an XCFramework for each module, and have all architectures in there. That’s a very versatile solution for the Apple ecosystem, much nicer to work with than VTK installed through Homebrew or otherwise.
I tried buildling XCFrameworks, but the issue I encountered was that I’d have to partition the headers according to their modules (otherwise I get errors of duplicate headers), and that didn’t seem to be feasible.
Somewhat of a tangent but for macOS there’s a Homebrew installation of VTK. It’s common for Homebrew installations to include a pkg-config file. The Swift Package Manager uses these files to locate “system libraries”. That’s really the only way other than XCFrameworks to include a C++ library in a Swift project that has C++ interoperability enabled. I tried writing one on my own and saw some success but I got stuck on something else that I don’t recall now.
The alternative to using Swift Package Manager is the way the macOS example project is set up, more or less. It’s really hardly ideal to mix these approaches, but that’s the only way I could things working for macOS.
But really I’d like to first understand what “modern CMake” means in this cross-compile context. If we could just get all or most of the modules built for more Apple platforms, the way we’d package them to make it easier on Apple platforms would be the icing on the cake.