The last time I checked Rust didn't support .frameworks creation, didn't support Bitcode and calling the main thread from Rust wasn't easy.
I would love to hear if these issues have been resolved.
From a purely "how do I get something I can link to" perspective, you can still build a cdylib and a header for it, Xcode will let you include the header in your Objective-C code or in the Swift bridging header, and then you can link to the cdylib and copy it into the "Frameworks" subdirectory in the bundle at build time. I've been doing that in an OS X app for several months and it works out very well.
> calling the main thread from Rust wasn't easy.
If you want to schedule code to run in the main queue/thread/runloop, that's an Apple-specific thing Rust wouldn't be aware of by default, but I did find a wrapper for libdispatch/GCD, and it seems to support calling things on the main queue which should do what you want.
https://crates.io/crates/dispatch
You can also have your app provide a C callback to the Rust code (even a Swift closure with captured variables, with some clever workarounds since you can't do that by default), and then in the callback you can schedule code to run on the main queue/thread if you want.
What would be the difference though, why make the distinction?
> Dynamic libraries outside of a framework bundle, which typically have the file extension .dylib, are not supported on iOS, watchOS, or tvOS, except for the system Swift libraries provided by Xcode.
https://developer.apple.com/library/content/technotes/tn2435...
>You can also have your app provide a C callback to the Rust code
That's exactly what I'm doing, however callbacks become cumbersome after a while, and I don't like that pattern. I need to do MVVM where the View is a thin iOS/Android layer, and the VM is in Rust. Right now there are significant hurdles to keep references from Swift to Rust and vice versa.
Thanks.
Bitcode is tough, see https://github.com/rust-lang/rust/issues/35968
In general, we'd love to get this into better shape, but need some help from people with the time and expertise to hack on it.
To be fair to Rust, it does perfectly what it's supposed to do as a language on iOS/Android. I have a fully multithreaded toy Rust+Swift app that works fine, and the performance is pretty good. Most of the problems I described are due to the differences in the paradigms between Swift/Java and Rust. (OOP vs Functional), and I'm sure things will be fine with time.
Do you have any better approach to JNI calls other than Djinni, SafeJNI, SWIG, RPC-like with bulk of work on Java side?
I use this homegrown solution on an Android app of mine which integrates with the CPython interpreter: https://github.com/joaoventura/pybridge/
It is RPC-like, but the code is quite simple: https://github.com/joaoventura/pybridge/#how-it-works. In the java-side, you just create a JSON object, send it to Python-land and get the result. Here's the java example in the code (https://goo.gl/sw4JLt) and here's the python function that it calls (https://goo.gl/hgbqVR).
Don't know if it's what you're looking for, or how it compares to the solutions you mentioned above, but I had someone from dropbox contributing a fix, and mentioning that going forward with a solution like this he would need something similar to djinni regarding error handling: https://github.com/joaoventura/pybridge/pull/3#issuecomment-...
On my specific case it is more weekend programming, mainly focused on graphics and multimedia, so I can bare the ocasional pain for reading image files, being called as a service or interacting with the network related hardware.
Just wanted to have some heads up on other possibilities that I could be missing, from people that do it professionally.
We use Djinni extensively and it does what it advertises. We've to be careful with retain cycles and Djinni proxies create strong retain cycles if didn't configure correctly.
I'm actively looking into libdispatch for threading. I've heard of people having success with long polling of file/socket and dispatch_source to update main threads from BG on iOS/Android. I'll probably write a blog post if I succeed (and that's a big IF).
Not really, but I am aware of that pattern as it is the approach taken by SDL.
Thanks.
my only concern is bitcode support, not feasible now due to a version mismatch between apple's llvm and rust's llvm (you can emit bitcode with rustc). which means currently you can ship apps for iOS, but not watchOS or tvOS.
(my use case of rust is DSP / audio synthesis)