6 ms·

I might be a minority here, but can someone please update me on there state of Rust on iOS? I develop C++ cross platform iOS/Android apps and would love to use

I might be a minority here, but can someone please update me on there state of Rust on iOS? I develop C++ cross platform iOS/Android apps and would love to use Rust if possible. 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.

agmcleod 10y ago
I haven't seen much on it. Doesn't mean solutions don't exist, but I regularly read updates on reddit and what people are working on, and I haven't seen much there. I feel like Swift is more likely to fill that role by coming to android.
- pjmlp 10y ago
  I imagine just like with Objective-C, it will only happen with forks of the NDK, as Google has always removed it from clang builds.
steveklabnik 10y ago
I hadn't heard of the .frameworks or "calling the main thread" problems; do you know if there are issues open? Bitcode is tough, see https://github.com/rust-lang/rust/issues/35968 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.
- FlyingSnake 10y ago
  Hey no worries, you guys are doing great! 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.
pjmlp 10y ago
Sorry for stealing the thread, on my case is Android/UWP. Do you have any better approach to JNI calls other than Djinni, SafeJNI, SWIG, RPC-like with bulk of work on Java side?
- FlyingSnake 10y ago
  Have you tried Loopers for Android to update main thread from NDK BG thread? I've seen people have success with that, but I personally didn't try it. AFAIK if you want to use MVVM pattern, there's no option than to use JNI. 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).
  - pjmlp 10y ago
    > Have you tried Loopers for Android to update main thread from NDK BG thread? Not really, but I am aware of that pattern as it is the approach taken by SDL. Thanks.
- jventura 10y ago
  > 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/ https://github.com/joaoventura/pybridge/ It is RPC-like, but the code is quite simple: https://github.com/joaoventura/pybridge/#how-it-works 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 https://goo.gl/sw4JLt) and here's the python function that it calls (https://goo.gl/hgbqVR 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-281893234 https://github.com/joaoventura/pybridge/pull/3#issuecomment-...
mrsteveman1 10y ago
> The last time I checked Rust didn't support .frameworks creation 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 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.
- FlyingSnake 10y ago
  I'm aware of long polling of file/socket and libdispatch.dispatch_source to update main threads from BG on iOS/Android. I'll have to try that out and find if it works. >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.
- conradev 10y ago
  You can't use dynamic libraries on iOS because they fail iTunes Connect validation. The only dylibs it allows are the Swift standard library. You can, however, use clang to take a static library and throw it into anything you want (framework, dylib, executable).
  - mahyarm 10y ago
    If you can avoid using a dylib on iOS, I would do it. It effects startup performance time. Just make a static version and compile it into the binary?
conradev 10y ago
I use Swift, Rust, tokio and lwIP in an iOS app to proxy traffic through Tor and they work very nicely together: https://github.com/icepa/icepa https://github.com/icepa/icepa
- FlyingSnake 10y ago
  This looks great, I'll check it out. Thanks.
- deleted 10y ago
  [deleted]
hashmal 10y ago
for me it works great, a few quirks to configure xcode at first (like with most things in xcode when you need more than a 100% cocoa app), then now the workflow is unobtrusive. debugging also works from xcode, minus coloring of rust code. 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)

agmcleod 10y ago

I haven't seen much on it. Doesn't mean solutions don't exist, but I regularly read updates on reddit and what people are working on, and I haven't seen much there. I feel like Swift is more likely to fill that role by coming to android.

pjmlp 10y ago
I imagine just like with Objective-C, it will only happen with forks of the NDK, as Google has always removed it from clang builds.

steveklabnik 10y ago

I hadn't heard of the .frameworks or "calling the main thread" problems; do you know if there are issues open? Bitcode is tough, see https://github.com/rust-lang/rust/issues/35968 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.

FlyingSnake 10y ago
Hey no worries, you guys are doing great! 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.

pjmlp 10y ago

Sorry for stealing the thread, on my case is Android/UWP. Do you have any better approach to JNI calls other than Djinni, SafeJNI, SWIG, RPC-like with bulk of work on Java side?

FlyingSnake 10y ago
Have you tried Loopers for Android to update main thread from NDK BG thread? I've seen people have success with that, but I personally didn't try it. AFAIK if you want to use MVVM pattern, there's no option than to use JNI. 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).
- pjmlp 10y ago
  > Have you tried Loopers for Android to update main thread from NDK BG thread? Not really, but I am aware of that pattern as it is the approach taken by SDL. Thanks.
jventura 10y ago
> 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/ https://github.com/joaoventura/pybridge/ It is RPC-like, but the code is quite simple: https://github.com/joaoventura/pybridge/#how-it-works 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 https://goo.gl/sw4JLt) and here's the python function that it calls (https://goo.gl/hgbqVR 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-281893234 https://github.com/joaoventura/pybridge/pull/3#issuecomment-...

mrsteveman1 10y ago

> The last time I checked Rust didn't support .frameworks creation 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 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.

FlyingSnake 10y ago
I'm aware of long polling of file/socket and libdispatch.dispatch_source to update main threads from BG on iOS/Android. I'll have to try that out and find if it works. >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.
conradev 10y ago
You can't use dynamic libraries on iOS because they fail iTunes Connect validation. The only dylibs it allows are the Swift standard library. You can, however, use clang to take a static library and throw it into anything you want (framework, dylib, executable).
- mahyarm 10y ago
  If you can avoid using a dylib on iOS, I would do it. It effects startup performance time. Just make a static version and compile it into the binary?

conradev 10y ago

I use Swift, Rust, tokio and lwIP in an iOS app to proxy traffic through Tor and they work very nicely together: https://github.com/icepa/icepa https://github.com/icepa/icepa

FlyingSnake 10y ago
This looks great, I'll check it out. Thanks.
deleted 10y ago
[deleted]

hashmal 10y ago

for me it works great, a few quirks to configure xcode at first (like with most things in xcode when you need more than a 100% cocoa app), then now the workflow is unobtrusive. debugging also works from xcode, minus coloring of rust code. 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)