21–30 of 95 posts
This releases fixes the #derived mess, right? Meaning we don't need to mess with weird build scripts to get serialization and json support? Edit: so it was 1.15! I've been running 1.14 on my laptop and didn't realize it!
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.
> 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…
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.
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 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.
Earlier quoted context omitted.
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?
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…
Not really, but I am aware of that pattern as it is the approach taken by SDL.
Thanks.
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.
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.
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
Thanks.
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.
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
Earlier quoted context omitted.
> 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…
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).
Probably the most significant addition in this release is the cargo check subcommand, which does all the type/safety checking part of rustc, but skips the LLVM part of generating the actual binary. If you just want to make sure you code compiles, this is the command for you. There's also a bunch of API stablilizations around Strings, Vectors etc, complete changelog: https://github.com/rust-lang/rust/blob/master/RELEA…
Earlier quoted context omitted.
> 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…
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).
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...