Building cross-platform Rust for Web, Android and iOS – a minimal example(artificialworlds.net)
artificialworlds.net
Building cross-platform Rust for Web, Android and iOS – a minimal example
https://www.artificialworlds.net/blog/2022/07/06/building-cross-platform-rust-for-web-android-and-ios-a-minimal-example/
6 comments
A handy feature of NSURLSession comes to mind: You can configure requests to enqueue „forever“ (eg when offline) until they are finally successful. No retry mechanism necessary, or exponential backoff which can add nontrivial idle time.
Features like this one are certainly not available when using an alternative networking stack.
Features like this one are certainly not available when using an alternative networking stack.
There is for instance a KMP module which relies on OkHTTP on Android and wraps NSURLSession on iOS - while exposing a common interface in Kotlin. The name escapes me at the moment. No reason you can't do that with Rust, but there's no reason to do that either, in my opinion. I agree that this probably isn't the right boundary at which to do your code sharing.
On the other hand your shared code can parse or generate data and pass it to/obtain it from a platform specific networking layer.
On the other hand your shared code can parse or generate data and pass it to/obtain it from a platform specific networking layer.
I’ve mentioned this in /r/rust before but it always seems to fall on deaf ears.
That said, people should look to Spotify’s wrapper as a target to clone, as I believe they managed to work around this.
That said, people should look to Spotify’s wrapper as a target to clone, as I believe they managed to work around this.
This problem hasn’t been solved yet, but I think it is solvable. I’ve been writing a lot of cross-platform Rust and think these would help a lot:
- Add an NSURLSession backend to reqwest. The abstractions match well, and Obective-C interop is pretty solid
- A Tokio API compatible networking implementation using the Network framework’s C API. Not quite sure how well this would work, but I think it’s possible.
I will try to build these at some point
ktor.io successfully does the first thing for Kotlin Multiplatform, multiplexing all of OkHttp, NSURLSession, fetch and others
- Add an NSURLSession backend to reqwest. The abstractions match well, and Obective-C interop is pretty solid
- A Tokio API compatible networking implementation using the Network framework’s C API. Not quite sure how well this would work, but I think it’s possible.
I will try to build these at some point
ktor.io successfully does the first thing for Kotlin Multiplatform, multiplexing all of OkHttp, NSURLSession, fetch and others
It’s early and it will get figured out.
It’s just nice to see Rust and WebAssembly mature little by little.
It’s just nice to see Rust and WebAssembly mature little by little.
It _has_ been figured out, it's just not something anyone's done in Rust yet: https://github.com/nativeformat/NFHTTP
Awesome thanks. I don’t know what I’d do without HN to discover all these GitHub repos with some amount of curation.
Doesn't really seem to have been figured out for Android
Given that the README literally has Android support and build instructions, it would be helpful if you qualified your comment with more than a one-liner like that.
Can you detail, say, why curl as a backend isn't necessarily sufficient here?
Can you detail, say, why curl as a backend isn't necessarily sufficient here?
Apologies. I was going by the fact that the README has Android support listed as Beta. It doesn't even seem to support HTTPS https://github.com/nativeformat/NFHTTP/issues/29
I spent some time doing exactly this a couple of months ago, and I agree, Mozilla's UniFFI is really cool. It's also what I'd probably recommend at this time if you're trying do Rust code sharing across higher-level platforms like iOS and Android.
You do have to write an export header spec in 'UDL' (a Mozilla authored interface definition language with a JetBrains plug-in to make it easier to write) - but in exchange, you get proper (idiomatic) Kotlin, Swift, Ruby and Python bindings for your Rust modules. It's nice that for instance the Swift bindings are actually 'native' instead of implemented via Objective-C interop (which would have arguably been simpler).
[edit] I should note that the Kotlin bindings are a little wonky for non-scalar types because they're exported as AutoCloseable resources, and care must be taken to use them correctly. [1]
[1] https://mozilla.github.io/application-services/book/howtos/u...
You do have to write an export header spec in 'UDL' (a Mozilla authored interface definition language with a JetBrains plug-in to make it easier to write) - but in exchange, you get proper (idiomatic) Kotlin, Swift, Ruby and Python bindings for your Rust modules. It's nice that for instance the Swift bindings are actually 'native' instead of implemented via Objective-C interop (which would have arguably been simpler).
[edit] I should note that the Kotlin bindings are a little wonky for non-scalar types because they're exported as AutoCloseable resources, and care must be taken to use them correctly. [1]
[1] https://mozilla.github.io/application-services/book/howtos/u...
I found https://github.com/antoniusnaumann/cargo-swift pretty nice for iOS. It uses UniFFI under the hood but automates the other pieces with building an xcode project.
Macroquads can also nicely build cross-platform. For Web, Android, Windows, Linux and from what I understand there also work being done for iOS.
I personally like it and use it because it clicks with how I think, so there isn't much extra additional learning to be done.
I personally like it and use it because it clicks with how I think, so there isn't much extra additional learning to be done.
UniFFI is pretty amazing productivity-wise for sharing common components across clients and teams. I haven’t really figured out the WASM side yet though or if it’s even really feasible.
There's also this too:
https://github.com/DioxusLabs/dioxus/
Not sure how it compares but it looks interesting.
Not sure how it compares but it looks interesting.
The reason for this is because iOS has a multitude of device specific optimizations built into the native networking stack to my knowledge is opted out of with the usage of cross platform networking. This includes features coalescence of calls across apps to occur when the antenna is already awake (to save power) and transparent management of multi-connection situations (e.g. when the phone has both wifi and cell available). The result is more power used and less fluidity in some situations.
I don't think this is as much of an issue on Android where third party networking libs like OkHTTP are the norm anyway.
With this in mind I believe the best functionality to put in a shared core is generic common logic which does not have platform optimizations.