uniffi-rs

Do not write the bindings manually. Just use the amazing uniffi-rs library from Mozilla. https://github.com/mozilla/uniffi-rs You can generate bindings for multiple languages. It supports error handling on both sides and latest versions also support native async integration. I've used it to reuse the same Rust engine in iOS and Android apps and write native UI. https://github.com/koofr/vault

Hi Hacker News, we've just released Gobley v0.2.0! Gobley provides Gradle build integration between Kotlin Multiplatform (KMP) and Cargo for Android, iOS, and JVM. Kotlin/JS and Kotlin/WASM support is planned, so stay tuned! We also have some documentation for newcomers: - Hands-on tutorial: https://gobley.dev/docs/tutorial - Cross-compilation tips to integrate Kotlin, Rust, and C++: https://gobley.dev/docs/cross-compilation-tips - Cross-platform example app (Android, iOS, Windows API, & Linux GTK): https://github.com/gobley/gobley/tree/main/examples/app/src - GitHub discussions: https://github.com/gobley/gobley/discussions Gobley is a fork of the (now archived) uniffi-kotlin-multiplatform-bindings (https://gitlab.com/trixnity/uniffi-kotlin-multiplatform-bind...) which is built on Mozilla’s excellent (still active) UniFFI (https://github.

Limited for now, Koto's main role as an embedded language has meant that I haven't had a need, but I would like to provide bindings for other languages at some point, and to enable dynamically loaded Rust libraries. I'd start by trying UniFFI [1] which looks much simpler than the approach of manually writing a C API and using that as a foundation for higher-level language bindings. This would also likely be the starting point for a package management system (if there ends up being demand for one). Rust doesn't have a stable ABI so to make sure that dynamically loaded Rust packages are compatible, either Koto would need to be in the business of Rust toolchain management so that packages can be recompiled when needed, or an API layer would be needed. There are some projects that provide ABI-compatibility shims but I don't like the idea of h

Javascript calling back and forth to Rust which calls in to Kotlin & Swift you say? There are few pieces to put in place here, but it's something we've discussed. The current task is teaching uniffi to support multiple foreign languages at the same time: <https://github.com/mozilla/uniffi-rs/issues/2295>. But, yeah, what we're launching today takes you closer to your dream than it was yesterday. The rest, work is progressing. What we're launching today is

The article provides a very detailed exploration of all of the fun challenges you can face designing FFIs with Rust, but there's a good chance you can "get away" with simpler approaches if you think ahead a bit. In our case, we call into Rust from Kotlin using JNI [0] and Swift using swift-bridge [1]. Thankfully our use case for the FFI [2] is for non-performance-critical calls and the data structures are fairly simple, so we just serialize objects with JSON. No major issues so far. One thing I am surprised hasn't been mentioned so far is Mozilla's UniFFI [3] which seems to solve some of the issues brought up in the article. We plan to switch to that once our FFI requirements become more complex. [0] https://docs.rs/jni/latest/jni/ [1] https://github.com/chinedufn/swift-bridge [2] https://www.firezone.dev/kb/architecture/tech-stack#client

Kinda. Did a dummy project in a few languages to see what I wanted to use for the big project. Looked at Go, Swift, Kotlin MP, and Rust. I liked Kotlin tools, and small binary size. If I knew I wasn't going to need more libraries in the future I might pick it. Go is great, although binaries a bit large with the runtime packed in, and TinyGo too limiting. Rust: I couldn't find a good multi-language binding package so I skipped it... then later found https://github.com/mozilla/uniffi-rs It could be a top contender.

You can, though. From a random Cargo package I have downloaded to my computer: [dependencies] uniffi = { git = "https://github.com/mozilla/uniffi-rs" } You can also specify revision/branch/etc. Alternatively, you can do: [registries] maven = { index = "https://rust.maven.org/git/index" } [dependencies] some-package = { index = "maven", version = "1.1" } Obviously Maven doesn't host any Rust crates (yet?), this is just a theoretical example. Very few projects bother to host their own registry, partially because crates.io doesn't allow packages that load dependencies from other indices (for obvious security reasons). The registry definition can also be done globally through environment variables: CARGO_REGISTRIES_MAVEN="https://rust.maven.org/git/index". Furthermore, the default registry can be set in a g

check out uniffi for a complete workflow for FFI in many languages: https://github.com/mozilla/uniffi-rs

Mozilla's uniffi-rs is really good. You write a common IDL and the bindings are generated automatically. It supports Swift, Kotlin, Python, Ruby and JavaScript (not in the official repo). https://github.com/mozilla/uniffi-rs

Did a brief search on the rust ffi, seems that mozilla has something interesting shared on the topic https://github.com/mozilla/uniffi-rs and https://blog.mozilla.org/data/2022/01/31/this-week-in-glean-...

I've worked on some projects (private and commercial) where embedding Rust into one of those targets was required: iOS, Android, Flutter, macOS, Web. I've played around with a variety of approaches because there exist multiple solutions depending on the platform. Apart from Web/Wasm, where Rust really shines, the next best solution is uniffi by Mozilla, which has quite solid iOS/Android support: https://github.com/mozilla/uniffi-rs While this works, the bigger pain (at least on iOS) is that the Rust-Compiler LLVM and Xcode LLVM are not always in sync leading to strange bugs. Also, packaging Rust libraries into a nice XCFramework (or even SPM Module) works, but usually involves hacky shell scripts. The reason why you'd still want to do this is if there's a Rust library that has no equivalent on the Kotlin or Swift side. There're a lot of g

I think they should give up on Flutter for Web and just focus on mobile and desktop (and maybe extend use on Smart Watches, Smart TV, embedded instead). Too many people still remember Java Applets, google's GWT, Flash/Flex and how it ended. They are out of focus trying to support Web as well. I had also higher expectation regarding Dart FFI - I think with their ffigen we are still only in ctypes like python bindings territory. Nowhere near something like pybind11 [0] for c++ bindings yet. [0] https://github.com/pybind/pybind11 [1] https://github.com/mozilla/uniffi-rs

Sounds similar to https://github.com/mozilla/uniffi-rs. Hopefully Oso open source their library.