HN Explorer

Build Android apps using Rust and Iced (github.com)

173 points by rekireki ↗ HN
Some time ago I decided to try building an Android app using Rust. After a few weeks I got it working. There was a new iced release recently, so I've just updated the example to new iced and wgpu. I'd like to share my experience to attract more attention to Rust on Android.

First things, I want to thank all the people who work on the foundational crates and tools such as: - https://github.com/rust-mobile/android-activity - https://github.com/jni-rs/jni-rs - https://github.com/gfx-rs/wgpu - https://github.com/rust-windowing/winit - and many others

When I started I had to learn what tools and examples already exist. Luckily, there's a good set of examples using both NativeActivity and GameActivity: https://github.com/rust-mobile/rust-android-examples

The basic approach is that we take android-activity, winit and wgpu and that's it. On top of that you can find a few egui examples in the rust-android-examples repo.

Alright, so after I've got the basic examples running, I wanted to combine them with iced. Iced is a crossplatform gui library focusing on desktop and web. The mobile support is explicitly a non-goal, as far as I can tell at the moment of writing. Yet, there's an issue where some people posted their experiments. That's how I knew it was possible: https://github.com/iced-rs/iced/issues/302

There's a way to integrate iced in wgpu applications, so called integration example: https://github.com/iced-rs/iced/tree/0.14.0/examples/integra...

Above I mentioned that using winit and wgpu in combination with android-activity is enough to build the app. Putting together 1 + 1 I got 2: let's use iced integration example with android-activity. It was quite easy to compile with almost no errors. First issue I encountered is that there was no text rendered. I solved this by loading fonts the way it was shown here: https://github.com/pop-os/cosmic-text/issues/243#issue-21899...

Then I patched a few widgets to add touch support. And that's it. My role here was to take all the prior work and combine it together in a way that there's a working example.

Some other ways of building Android apps using Rust: - xilem has an explicit goal to support mobile https://github.com/linebender/xilem - egui supports mobile https://github.com/emilk/egui - game engines such as Fyrox and Bevy support mobile: - https://github.com/FyroxEngine/Fyrox - https://github.com/bevyengine/bevy - pretty much anything built on top of winit and wgpu

All of the above is related to building native apps using either NativeActivity or GameActivity. I'm leaving webview out of scope of curr...

17 comments

[ 4.8 ms ] story [ 40.6 ms ] thread
[deleted]
(comment deleted)
bbkane
Super impressive, can you link to this post in that issue?

I'd like to try iced, but switched to egui on the official Android support.

nubinetwork
Just in time for google to block sideloading and blocking new apps unless you pay them 6 figures...
vlovich123
How does this compare for you with slint and dioxus? Dioxus uses web views but still a small app (based on Tauri which uses the OS web view instead of shipping the browser) and slint is native, but may have some slightly more unique license terms than typical Rust projects.
nicoburns
There is a huge amount of potential for shared infrastructure for "native integrations" for Rust UI projects. Think: React Native modules but in Rust.

I'm hoping this can be a reality sooner rather than later. But we're definitely lacking in manpower willing or able to work on the more foundational pieces. Winit in particular is sadly undermaintained. 1 or 2 people working full time on Winit and/or other platform integration pieces would do wonders for the ecosystem.

coldstartops
Also on this topic I want to make a shout out to slint.dev ! (I've fiddled with it, and the syntax is extremely easy to grasp - very react-ish). Can use Rust/C as a binding language, and you can even choose the rendering engine (for example QT).
RicoElectrico
Not downplaying your project but a general related question. What's the deal with writing non-real-time application software in Rust? The stuff it puts you through doesn't seem to be worth the effort. C++ is barely usable for the job either.
androidinlimbo
Android is in limbo, we need better free open source alternative.
NoboruWataya
Is there a reason you didn't mention Dioxus (other than not being familiar with it)? It explicitly has Android support as a goal, though (like all Rust GUI crates) it's a work in progress. I made a very simple app with it that works well in an Android emulator, I haven't tried actually side load it yet.
zwnow
Does this support native components like camera access and stuff like that? I've learned with most libs like this I never have access to the android internals (Flutter as an example) and I'll always have to fallback to writing Kotlin components with broadcast channels or whatever.
Simplita
This matches my experience too. Rust really shines once the app grows beyond simple flows. The upfront friction pays off later when debugging and concurrency issues would otherwise start piling up.
madduci
I would like to get a benchmark of this against an app made with C++/Qt
denverllc
Will apps built with this framework be compatible with accessibility features?
[deleted]
(comment deleted)
yoan9224
This is technically impressive but I'm skeptical about real-world adoption. The fundamental question is: what problem does this solve that Kotlin + Jetpack Compose doesn't? Compose already has declarative UI, excellent tooling, and first-party support. Rust's memory safety benefits matter less in app-land where performance bottlenecks are typically network I/O or image processing, not memory management.

The compelling use case would be sharing business logic between iOS/Android/desktop/web. If you can write core logic in Rust once and have thin UI layers per platform, that's valuable. But Iced's UI abstraction needs to be good enough that you're not fighting platform-specific behaviors constantly. Flutter tried this approach and succeeded commercially but still gets criticized for "not feeling native" on either platform.

Performance is where this could shine. Rust + Iced should theoretically have lower memory overhead and faster startup than the Kotlin runtime + Compose. For apps that manipulate large datasets locally (photo editors, video editors, CAD tools), avoiding GC pauses matters. But for typical CRUD apps that are 90% API calls and list scrolling, I doubt users would notice the difference.

The real barrier is developer experience. Kotlin has incredible IDE support via IntelliJ/Android Studio, instant hot reload, comprehensive documentation, and thousands of libraries. Rust's mobile tooling is immature by comparison. Unless you're already a Rust shop building a performance-critical app, the learning curve probably isn't justified. I'd love to be proven wrong though - more competition in the mobile development space would be healthy.