Rust cross-platform mobile
An open-source template for sharing business logic between Android and iOS with Rust, with native UI on both platforms.
- GitHub stars
- 160+
Why
In 2020, I was exploring a familiar mobile development problem: the same networking and business logic, written once for Android and again for iOS. I wanted to share that work while keeping the native interfaces. I had already experimented with Go and gomobile; Rust was the next candidate.
Its appeal was clear: native compilation, no garbage collector, and a compiler that catches many memory mistakes. The practical question was harder. Could I use it for an ordinary mobile app without spending more effort on integration than I saved on shared code?
The examples I found didn’t go far enough to answer that. So I built a small end-to-end application around three everyday requirements: fetch data, process it off the UI thread, and pass the result back to a native screen. It gave other engineers something concrete to inspect before making the same decision.
How
Both apps display Star Wars characters loaded by the same Rust core:
- Fetch and deserialize: the shared core requests data from the Star Wars API and turns JSON into application data on a background thread.
- Connect Android: a JNI bridge lets the Kotlin app call the core and receive its results.
- Connect iOS: an FFI bridge exposes the same core to Swift through C-compatible interfaces.
- Keep the native screens: Kotlin and Swift handle presentation on their respective platforms.
I also compared the request timings with native Swift and Kotlin implementations. In this small network-bound experiment, calling Rust through the bridges made little visible difference to the timings. Server latency affected the results, so this wasn’t a measurement of bridge overhead in isolation.
I published the example and write-up in May 2020. My conclusion at the time: I’d choose Rust over C/C++, but integrating it was still more work than using Swift or Kotlin directly. The project makes that tradeoff visible, including the bridges that a simple language benchmark leaves out.
