Swift bindings

[Stefterv]

I have started writing bindings for Swift over at https://github.com/Stefterv/filament/tree/swift_bindings
Is this somethings I could contribute to the project or is it out of scope for now? Like mentioned in #4111

The current state is that I have got the repo working as a Swift Package.
I have added an early attempt at writing the bindings themselves. They were written with my specific project in mind so they are in no way complete yet, the plan is to improve from here.

[prideout]

Thanks, this is awesome, but it will need to be in a fork or separate project. Maintaining our current set of language bindings is already difficult since our team is so small, this would be out of scope for now.

[Stefterv]

I can write/have written the majority of the updates that need to be made to the build/publishing system, I will just need some guidance how to do it neatly as I'm not familiar enough with CMake

[bejado]

It's not clear to me why our CMake files would need to be modified. I'm reluctant to do this because anything that goes into our repo we need to support, and as @prideout mentioned we're a small team and our release process is already complex.

It sounds like the bindings would be separate from our project, but even supporting Filament without bindings as a SwiftPM Package might be too involved for us.

[Stefterv]

The changes that need to be made are in this commit: Stefterv@47e7c36. It involves generating .framework first and secondly .xcframework files alongside the .a files as the output of the cmake process, resulting in the out/ios-release/filament/lib/universal folder. SwiftPM doesn't support the inclusion of .a binary targets as Cocoapods does, so I had to create an adaption for that.
I suspect it can even be improved to the point where it doesn't need a giant list of the .binaryTargets in the Package.swift meaning even if the libraries/targets within Filament change there needs to be no change made to the Swift Package.

I am also advocating for this change as the main part of the project as it will make including Filament into any iOS project much easier (in XCode click file->Add Package... and paste the url) which I think is neat.

As for the effort it would take to maintain it, I took a look at the commit history of the .podspec file and apart from version bumps, it has only been changed 5 times since its creation. I suspect the SwiftPM setup to very similar or even less work. I'm happy to do the initial bulk of the work of setting it up.

I do understand that with any systemic change to a build process there is always the risk of unintended side-effects, the uptick is though that the iOS release process of Filament might be easier and more future proof according to this article

[Stefterv]

I revisited the bindings this weekend and I found a way to generate the necessary files without modifying the original repo and finished most of the bindings: https://github.com/Stefterv/filament_swift the example should work apart from the skybox bug mentioned in #7151

[Stefterv]

Oh and almost forgot to mention Mixing Swift and C++ Swift/Apple are working on direct C++ interoperability, I also played around with it but most of the Filament classes are not compatible and it's still in pretty early stages so I decided to finish the Swift -> ObjC -> C++ bindings