The runtime-wry-ffi (https://github.com/velox-apps/velox/blob/f062211ced4c021d819...) file which is 3.2K lines long and has close to a 100 unsafe calls, isn't that just interacting with wry which has it's own crate you could use instead? I'm not 100% sure, but seems to be basically the same as wry itself but without the cross-platform stuff, is that the purpose of that file?
Together with the author's distaste for Rust, it seems awfully dangerous instead of pulling in a crate made by Rust developers, but I might misunderstand the purpose of the file here.
> Together with the author's distaste for Rust
As someone who understand the sentiment, I wouldn't call it distaste for Rust. It feels more as Rust not being the right tool for the job and to be honest I have the same feeling here. Rust is great for a bunch of problem domains, but it doesn't feel to be the best tool for this specific problem domain. It's always about the choices a programming language makes, it make it good for some use-cases and bad for others and there's nothing wrong with it. Also as a cautionary tale about panacea programming languages, Java once tried it with great success to be "the one" language to rule them all and we can see that even though it was a popular choice in many domains, slowly other fitting solutions to specific problem domains took over. Proving that there is no such a thing, unfortunately for us, but some languages gets closer than others (Rust being one of them).
I believe that is wrapping the Wry crate (and a few other crates) in a C API that can be accessed over FFI (which can then presumably be called directly be Swift code).