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.
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).
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.
I left WebView based solutions out of scope. As you can see, I'm focusing on NativeActivity / GameActivity in my post. Though WebView brings you interesting options. For example, iced is inspired by Elm, and with Dioxus you can use Elm to build mobile apps.
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.
Dioxus is WebView, as you've mentioned. Though there's an experimental native renderer mentioned in the README, I would keep an eye on it. And slint should be the same kind of solution as I wrote about. When building native apps for Android, there's usually an issue with text inputs. NativeActivity doesn't support IME, and GameActivity is supposed to solve this. So in case of slint, I would check how they solved the text inputs.
> Though there's an experimental native renderer mentioned in the README,
The native renderer should be available in 2026! (technically it's available now as a preview, but I wouldn't recommend using it until after the next release)
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.
My understanding is that this only gives you access to C++ TurboModules? Binding to C++ is already easy in Rust (and odten Rust itself is a better choice for these "cross-platform business logic" kind of modules anyway). The value here is in unlocking bindings to the native platform APIs (which are mostly Java/Kotlin/Objc/Swift)
Crux seems interesting to share app logic between platforms but I don't see how it helps actually render something. Don't you still need a gui framework that supports android or ios?
Having spent time around cross platform rollouts and development I think something like Crux is the best approach. Building a complete UI framework to rival what iOS and Android provide natively is a monumental task.
The Android Open Source Project is awesome. It's not hard to compile it yourself and run it on a pixel 9. The issue is the hardware imo. (And some of the apps in AOSP really suck, but the actual OS is great imo)
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.
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.
A lot of complex GUIs are written in C++ (or are thinish wrappers around an underlying toolkit that is C++). This is often for performabce and/or resource consumption reasons. UIs may not have hard realtime requirements, but they are expected to consistently run smoothly at 60fps+. And dealong with multiple screen sizes, vector graphics, univode text,r etc can involve a lot of computation.
Rust gives you the same performance as C++ with much nicer language to work with.
It turns out it is worth the effort. Once you have got past the "fighting the borrow checker" (which isn't nearly as bad as it used to be thanks to improvements to its abilities), you get some significant benefits:
* Strong ML-style type system that vastly reduces the chance of bugs (and hence the time spent writing tests and debugging).
* The borrow checker really wants you to have an ownership tree which it turns out is a really good way to avoid spaghetti code. It's like a no-spaghetti enforcer. It's not perfect of course and sometimes you do need non-tree ownership but overall it tends to make programs more reliable, again reducing debugging and test-writing time.
So it's more effort to write the code to the point that it will compile/run at all. But once you've done that you're usually basically done.
Some other languages have these properties (especially FP languages), but they come with a whole load of other baggage and much smaller ecosystems.
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.
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).
How does the text input work there? Does it support IME? Were you able to switch to non-latin keyboards?
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.
I left WebView based solutions out of scope. As you can see, I'm focusing on NativeActivity / GameActivity in my post. Though WebView brings you interesting options. For example, iced is inspired by Elm, and with Dioxus you can use Elm to build mobile apps.
Dioxus is a very different API model, being an implementation of the Elm architecture. It’s really comparing apples to octopuses.
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.
Dioxus is WebView, as you've mentioned. Though there's an experimental native renderer mentioned in the README, I would keep an eye on it. And slint should be the same kind of solution as I wrote about. When building native apps for Android, there's usually an issue with text inputs. NativeActivity doesn't support IME, and GameActivity is supposed to solve this. So in case of slint, I would check how they solved the text inputs.
> Though there's an experimental native renderer mentioned in the README,
The native renderer should be available in 2026! (technically it's available now as a preview, but I wouldn't recommend using it until after the next release)
I would like to get a benchmark of this against an app made with C++/Qt
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.
If you do it via React Native turbo modules, it is already possible, either using craby (1) or using uniffi-bindgen-react-native (2).
(1) https://github.com/leegeunhyeok/craby
(2) https://github.com/jhugman/uniffi-bindgen-react-native
My understanding is that this only gives you access to C++ TurboModules? Binding to C++ is already easy in Rust (and odten Rust itself is a better choice for these "cross-platform business logic" kind of modules anyway). The value here is in unlocking bindings to the native platform APIs (which are mostly Java/Kotlin/Objc/Swift)
I would love to see RustActivity in Android one day, this would make the life much easier.
I mean cross platform is just "heavy work" in general
many company literally just give up use web wrapper instead because its just so much work
You gotta check Crux: Cross-platform app development in Rust
https://github.com/redbadger/crux
Crux seems interesting to share app logic between platforms but I don't see how it helps actually render something. Don't you still need a gui framework that supports android or ios?
Having spent time around cross platform rollouts and development I think something like Crux is the best approach. Building a complete UI framework to rival what iOS and Android provide natively is a monumental task.
Yes (from the README)
Android is in limbo, we need better free open source alternative.
The Android Open Source Project is awesome. It's not hard to compile it yourself and run it on a pixel 9. The issue is the hardware imo. (And some of the apps in AOSP really suck, but the actual OS is great imo)
The userspace being tied to the JVM is a massive pain. Certainly it's a lot harder to bind to than any other OS's system libraries.
Account created one hour ago just to make this comment. Make it on your real account.
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.
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.
It doesn't, and I had to write some Java to support clipboard.
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.
A lot of complex GUIs are written in C++ (or are thinish wrappers around an underlying toolkit that is C++). This is often for performabce and/or resource consumption reasons. UIs may not have hard realtime requirements, but they are expected to consistently run smoothly at 60fps+. And dealong with multiple screen sizes, vector graphics, univode text,r etc can involve a lot of computation.
Rust gives you the same performance as C++ with much nicer language to work with.
I don’t understand the question. Why would rust be confined to real-time applications?
It turns out it is worth the effort. Once you have got past the "fighting the borrow checker" (which isn't nearly as bad as it used to be thanks to improvements to its abilities), you get some significant benefits:
* Strong ML-style type system that vastly reduces the chance of bugs (and hence the time spent writing tests and debugging).
* The borrow checker really wants you to have an ownership tree which it turns out is a really good way to avoid spaghetti code. It's like a no-spaghetti enforcer. It's not perfect of course and sometimes you do need non-tree ownership but overall it tends to make programs more reliable, again reducing debugging and test-writing time.
So it's more effort to write the code to the point that it will compile/run at all. But once you've done that you're usually basically done.
Some other languages have these properties (especially FP languages), but they come with a whole load of other baggage and much smaller ecosystems.
Just in time for google to block sideloading and blocking new apps unless you pay them 6 figures...