Build Android apps using Rust and Iced(github.com)
github.com
Build Android apps using Rust and Iced
https://github.com/ibaryshnikov/android-iced-example
88 comments
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.
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
(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 have no idea why people would want to write UI in Rust when Swift, Kotlin and Dart are much better suited for the job.
At least for me:
* I don't trust Swift on Android to be well supported, either now, or in the future. I would never want to rely on something Appley on a non Apple platform
* I dislike Swift and find it to be an unpleasant language. This is personal pref of coures, just like preferred flavors of ice cream
* Dart looks interesting and like a good option, though I don't want to learn a new language and Dart doesn't appeal to me because it feels like they took javascript and made it more like Java, and Java is in about the middle of my list of preferred langs (see above comment about preferred flavors of ice cream). Flutter is a killer app though and might be enough to sway me.
* Kotlin is a nice language, though not nice enough to where I'd want to use it outside of Android. The ties to the JVM-world tooling/dependency management is very offputting to me.
Overall I have a strong desire to use my preferred language(s) for everything if possible, so things like this are quite attractive to me for that reason. Now that said, when I write Android apps right now, what I typically use is Kotlin or Java because I've found I always end up having to write at least part of the app in those, so might as well keep it simple and consistent in one lang. But I'm always on the lookout!
* I don't trust Swift on Android to be well supported, either now, or in the future. I would never want to rely on something Appley on a non Apple platform
* I dislike Swift and find it to be an unpleasant language. This is personal pref of coures, just like preferred flavors of ice cream
* Dart looks interesting and like a good option, though I don't want to learn a new language and Dart doesn't appeal to me because it feels like they took javascript and made it more like Java, and Java is in about the middle of my list of preferred langs (see above comment about preferred flavors of ice cream). Flutter is a killer app though and might be enough to sway me.
* Kotlin is a nice language, though not nice enough to where I'd want to use it outside of Android. The ties to the JVM-world tooling/dependency management is very offputting to me.
Overall I have a strong desire to use my preferred language(s) for everything if possible, so things like this are quite attractive to me for that reason. Now that said, when I write Android apps right now, what I typically use is Kotlin or Java because I've found I always end up having to write at least part of the app in those, so might as well keep it simple and consistent in one lang. But I'm always on the lookout!
> I dislike Swift and find it to be an unpleasant language.
One of the reasons for me personally is a rich selection of packages from crates.io. For example if you are writing a server in Rust, and use something like https://crates.io/crates/reqwest for http requests, then you can reuse it in your mobile app. Also there's serde. You don't need to write the schema for your data if you have Rust on both server and client. Just make a shared crate and use serde to encode/decode the data. It really saves a lot of time if you don't have to use swagger or similar tools. And there's a documentation out of the box with `cargo doc`
You shouldn't use reqwest on mobile devices, you should be using the built-in platform-specific HTTP libraries.
On Android this appears to be less of an issue, but on iOS there's documentation floating around that you really want to use e.g NSURLSession for battery/radio reasons. Spotify even went so far as to write a cross-platform lib for this kind of thing some years back.
On Android this appears to be less of an issue, but on iOS there's documentation floating around that you really want to use e.g NSURLSession for battery/radio reasons. Spotify even went so far as to write a cross-platform lib for this kind of thing some years back.
It’s kind of the same argument as that for Node: having a singular language for everything you do lets you have “thick” tightly coupled packages that do everything, which you can compose or decompose in a safe(r) refactor as business needs change.
Once you start using JNI or Objective-C++ to hand off “computationally expensive” work to common C++ (now Rust) libraries, you end up needing to become an expert across a lot of areas.
If 95% of your competitive advantage lies in doing things everywhere with low memory, then taking on an additional 2-3 stacks (SwiftUI + React + Compose) as well as all the bindings and build system and etc overhead can be pretty gnarly.
If 95% of your value add is in your web-based UI, consolidating to a single JS stack of React + React Native + Node can greatly reduce your idea-to-market time, I’d imagine a full Rust stack could do the same if your value add requires maximum performance and only a little UI iteration.
Once you start using JNI or Objective-C++ to hand off “computationally expensive” work to common C++ (now Rust) libraries, you end up needing to become an expert across a lot of areas.
If 95% of your competitive advantage lies in doing things everywhere with low memory, then taking on an additional 2-3 stacks (SwiftUI + React + Compose) as well as all the bindings and build system and etc overhead can be pretty gnarly.
If 95% of your value add is in your web-based UI, consolidating to a single JS stack of React + React Native + Node can greatly reduce your idea-to-market time, I’d imagine a full Rust stack could do the same if your value add requires maximum performance and only a little UI iteration.
One language vs 3 or 4? And some folks REALLY like Rust
They are slow and memory-hungry.
I would love to see RustActivity in Android one day, this would make the life much easier.
There is https://github.com/rust-mobile/android-view, although it's not currently being actively developed.
I've seen it too recently, looks interesting.
NativeActivity is already a thing and can be implemented in Rust
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
many company literally just give up use web wrapper instead because its just so much work
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?
I think it is handled by the OS (backend renderer)
https://docs.slint.dev/latest/docs/slint/guide/backends-and-...
But, I have only used it with Romanian and English.
Try here: https://slintpad.com/. (just replace the Text with TextInput) and see if it works.
https://docs.slint.dev/latest/docs/slint/guide/backends-and-...
But, I have only used it with Romanian and English.
Try here: https://slintpad.com/. (just replace the Text with TextInput) and see if it works.
slintpad.com uses the wasm port to run on a browser and is not the same as when using Slint to build a "native" app, especially on mobile.
Slint does support decent text input and IME. Including text selection with the native handle. As a demo for android you can try the demo from https://material.slint.dev/ ("Download APK")
Slint does support decent text input and IME. Including text selection with the native handle. As a demo for android you can try the demo from https://material.slint.dev/ ("Download APK")
+1 for Slint! I worked with it for a while and enjoyed it quite a lot. Florian was working on a more glossy compinent library, not sure what has been made of it.
The DSL was pleasant but still had some rough edges. I think they made some nice QoL improvements in the latest releases, but I've not kept up with it. The compile times were quite something, though you can use the previewer tool to prototype faster.
Definitely worth giving Slint a shot, they learnt a lot from QML imo
The DSL was pleasant but still had some rough edges. I think they made some nice QoL improvements in the latest releases, but I've not kept up with it. The compile times were quite something, though you can use the previewer tool to prototype faster.
Definitely worth giving Slint a shot, they learnt a lot from QML imo
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.
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.
I've done business logic sharing where the engine was written in Rust, WASM for web with React for UI, uniffi-rs for Android and iOS with Kotlin Compose for Android and SwiftUI for iOS, Tauri for desktop.
There were no good examples for how to do this but once it was set up it worked extremely well.
It uses tokio for Android/iOS/desktop and even embeds a web server for fake API for end to end testing (even on mobile)
https://github.com/koofr/vault
There were no good examples for how to do this but once it was set up it worked extremely well.
It uses tokio for Android/iOS/desktop and even embeds a web server for fake API for end to end testing (even on mobile)
https://github.com/koofr/vault
The problem this (and Dioxus Native) solves is that someone might prefer Rust anyway.
Most of times it's just a personal preference, but sometimes it's due to using Rust libraries or already having code written in Rust that can be reused. There is Rust <-> Kotlin FFI (also Rust <-> Dart) but sometimes people don't like it
Most of times it's just a personal preference, but sometimes it's due to using Rust libraries or already having code written in Rust that can be reused. There is Rust <-> Kotlin FFI (also Rust <-> Dart) but sometimes people don't like it
Rust also has good IDE support and hot reloading. Mobile tooling and libraries for mobile APIs are definitely where it's still lacking atm.
Hot reloading where?
Not at the level of JVM/ART, or even C++ on VS and Live++.
Not at the level of JVM/ART, or even C++ on VS and Live++.
https://docs.rs/subsecond for hotpatching general Rust code Live++ style.
Many of the UI frameworks have domain-specific hot-reloading on top of that (e.g. Dioxus can hot-reload CSS assets and RSX without resorting to binary patching) which covers the common case of wanting to quickly iterate on design details.
I've found the domain-specific stuff to be completely instant (even faster than a typical browser hot-reload). The hotpatching is typically around 0.5-2 seconds for me, but that does partially depend on project size (and of course hardware - I'm running an Apple M1 Pro).
Many of the UI frameworks have domain-specific hot-reloading on top of that (e.g. Dioxus can hot-reload CSS assets and RSX without resorting to binary patching) which covers the common case of wanting to quickly iterate on design details.
I've found the domain-specific stuff to be completely instant (even faster than a typical browser hot-reload). The hotpatching is typically around 0.5-2 seconds for me, but that does partially depend on project size (and of course hardware - I'm running an Apple M1 Pro).
From How it works section, it appears to be with a quite yes and buts kind of limitations.
Still, I can see that they could eventually improve those issues.
Still, I can see that they could eventually improve those issues.
Also accessibility.
Will apps built with this framework be compatible with accessibility features?
No. Iced has no accessibility support built in. It's a pretty hard thing to do, so it's not surprising that something more hobby driven doesn't have it.
I hope that System76 invest into adding accessibility support into Iced, because they are using it to build Cosmic (the official desktop environment for Pop_OS).
They've committed to adding accessibility features. Iirc COSMIC right now has screen reader, magnification, and high contrast/invert colors support.
There is a really long way to go though, and accessibility on mobile comes with its own challenges as well. It will take a long time.
There is a really long way to go though, and accessibility on mobile comes with its own challenges as well. It will take a long time.
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)
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 think it’s important to note that the “native renderer” is still an HTML/CSS portable, render engine, not what would typically be called a native renderer.
https://github.com/DioxusLabs/blitz
https://github.com/DioxusLabs/blitz
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 has this idea stuck that it's webview only. They're actively working on (and ship at least in some form of alpha or beta) a native-renderer backend.
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.
How so?? JVM bytecode should be much easier to bind to, as the existence of JVM alternative runtimes for nearly every language shows.
Unless you're using a language that's specifically compile-to-jvm (e.g. Java, Kotlin or similar), almost nobody is using those JVM alternative runtimes. They're usually second-class runtimes that don't run the entire ecosystem of the target langauge. React Native runs JavaScript in a separate JS VM, Flutter is compiling Dart to native code with emdedded runtime, and Rust UI code also compiles to a native binary.
The "lingua franca" for language bindings is the C ABI which every other OS's platform libraries (Win32/Cocoa/GTK) support.
The "lingua franca" for language bindings is the C ABI which every other OS's platform libraries (Win32/Cocoa/GTK) support.
> The "lingua franca" for language bindings is the C ABI which every other OS's platform libraries (Win32/Cocoa/GTK) support.
Which is more like half of an API, it doesn't specify lifetimes so basically anything behind a pointer is unusable in itself. That's why we have "hacks" like gobjects and such, and why using most of the bindings is only possible if you have a decent binding library.
Which is more like half of an API, it doesn't specify lifetimes so basically anything behind a pointer is unusable in itself. That's why we have "hacks" like gobjects and such, and why using most of the bindings is only possible if you have a decent binding library.
Account created one hour ago just to make this comment. Make it on your real account.
Have you considered that people may join HackerNews who were not already on it?
And in particular, people might lurk for a long time without an account until one day a thread makes them want to comment so much that they go ahead and create an account to comment.
Although, the username they picked in this case does seem a bit specific to the topic of the single comment they wrote. So it remains to be seen if this particular case was a throwaway account only used once, or if they will keep it.
Although, the username they picked in this case does seem a bit specific to the topic of the single comment they wrote. So it remains to be seen if this particular case was a throwaway account only used once, or if they will keep it.
Also usernames/handles can be surprisingly hard. It seems reasonable to me that people would pick something related to what they are thinking about at the time.
What's way more likely is that they've created a sock puppet account though.
Have you considered googling what a sock puppet is?
See, both of us can make comments in that same condescending style, pretending to be polite.
See, both of us can make comments in that same condescending style, pretending to be polite.
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.
That will always be the case, some folks cannot get over that Android userspace is Java/Koltin, and the NDK use cases are officially real time audio, 3D rendering, writing native methods, reuse of existing C and C++ libraries and nothing else.
Everything outside those use cases is gated behind JNI calls, and Google has no plans to ever change it.
Naturally many with GNU/Linux mindset, and because Android runs on the Linux kernel, try to work around these restrictions, however Google isn't going to move an inch to make it easier.
Everything outside those use cases is gated behind JNI calls, and Google has no plans to ever change it.
Naturally many with GNU/Linux mindset, and because Android runs on the Linux kernel, try to work around these restrictions, however Google isn't going to move an inch to make it easier.
It doesn't, and I had to write some Java to support clipboard.
I see, still a really cool project! Is accessing the internals simply not possible or just really hard to pull off programmatically? I am wondering about that because I never found anything in the android space to enable that without resorting to Kotlin/Java components.
You can call into to the JVM via FFI (e.g. using the jni crate in Rust), but it's not very nice. And most of the abstractions people have written thus far seem to be primarily (or solely) targeting the "Java calls into native code" use case rather than the "native code calls into Java" use case.
I'd love to see something better here. I suspect it's possible.
I'd love to see something better here. I suspect it's possible.
It's limited to what NativeActivity / GameActivity can provide. And as @nicoburns mentioned, you'll have to use FFI if you want to access some Android functionality. But it doesn't always go smooth. For example, all my attempts to fix issues with software keyboard didn't work.
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.
You gotta check Crux: Cross-platform app development in Rust
https://github.com/redbadger/crux
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?
I would like to get a benchmark of this against an app made with C++/Qt
[deleted]
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.
I'd like to try iced, but switched to egui on the official Android support.
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.
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.
* 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.
> 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.
Not if I don't know what I'm doing because it's something new. The way I'm learning how to do it is by building it. So I want to build it quickly so that I can get in more feedback loops as I learn. Also I want to learn by example, so I actually want to get runtime errors, not type system errors. Later when I do know what I am doing then, sure, I want to encode as much as I can in my types. But before that .. Don't get in my way!
Not if I don't know what I'm doing because it's something new. The way I'm learning how to do it is by building it. So I want to build it quickly so that I can get in more feedback loops as I learn. Also I want to learn by example, so I actually want to get runtime errors, not type system errors. Later when I do know what I am doing then, sure, I want to encode as much as I can in my types. But before that .. Don't get in my way!
Yeah it is a fair point that runtime errors are sometimes easier to understand than compile time errors. They're still a much worse option of course - for the many reasons that have been already discussed - but maybe compile-time errors could be improved by providing an example of the kind of runtime error you could get if you didn't fix it (and it hypothetically was dynamically typed). Perhaps that would be easier to understand for some people or some errors.
There's a (Curry-Howard) analogue here with formal verification and counter-examples.
There's a (Curry-Howard) analogue here with formal verification and counter-examples.
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.
Rust gives you the same performance as C++ with much nicer language to work with.
Used to be written in C++, and usually trace back to the 1990's when C++ GUI frameworks used to rule.
Nowadays most are written in managed languages, and only hot paths are written in C++.
There is hardly anyone still writing new GUI applications on macOS, Windows in pure C++, even Qt nowadays pushes for a mix of QML, Python and C++.
Nowadays most are written in managed languages, and only hot paths are written in C++.
There is hardly anyone still writing new GUI applications on macOS, Windows in pure C++, even Qt nowadays pushes for a mix of QML, Python and C++.
I don’t understand the question. Why would rust be confined to real-time applications?
No the question is why you would use a systems language that necessarily lacks certain ergonomics such as automated garbage collection, for writing GUIs.
That makes no sense to me either, to be honest.
That makes no sense to me either, to be honest.
Why is automatic garbage collection necessary for UI? I’ve been writing UI apps for 25 years without using a garbage collector. In any case, the borrow checker often (though not always) obviates the need for garbage collection at all.
This is a good summary of the problem with rust I think:
> Pretty much all UI can be modeled as a tree–or more abstractly as a graph. A tree is a natural way to model UI: it makes it easy to compose different components together to build something that is visually complicated. It’s also been one of most common ways to model UI programming since at least the existence of HTML, if not earlier.
> UI in Rust is difficult because it's hard to share data across this component tree without inheritance. Additionally, in a normal UI framework there are all sorts of spots where you need to mutate the element tree, but because of Rust’s mutability rules, this "alter the tree however you want" approach doesn't work.[1]
[1] https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-ha...
> Pretty much all UI can be modeled as a tree–or more abstractly as a graph. A tree is a natural way to model UI: it makes it easy to compose different components together to build something that is visually complicated. It’s also been one of most common ways to model UI programming since at least the existence of HTML, if not earlier.
> UI in Rust is difficult because it's hard to share data across this component tree without inheritance. Additionally, in a normal UI framework there are all sorts of spots where you need to mutate the element tree, but because of Rust’s mutability rules, this "alter the tree however you want" approach doesn't work.[1]
[1] https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-ha...
If I’m being charitable that is an oversimplification, and I suppose I should be charitable at Christmas. But the Scrooge in me is screaming that this analysis is deeply flawed.
Rust makes ownership and mutability explicit. Concurrent editing is very dangerous no matter what stack you are using. Rust just doesn’t let you get away with being a cowboy and choosing YOLO as your concurrency model.
Shared mutable state isn’t any harder in Rust than other languages. In fact, writing correct, bug-free and performant code is easier in Rust than almost any other language in common use, because the tooling is there. It’s just that the other compilers let you ship buggy code without complaining.
To the specific example, there are ways of sharing mutable state, or encapsulating changes throughout a UI tree. I’ve written a UI framework in Rust that does this. It is difficult to get right. But this is true of ANY language - the difficulty is intrinsic to the data type, if you actually care about doing it correctly.
That difficulty does not need to be exposed to the user. There are plenty of Rust UI libraries that take react-like lambda updaters, for example.
I still fail to see the connection to garbage collectors.
Rust makes ownership and mutability explicit. Concurrent editing is very dangerous no matter what stack you are using. Rust just doesn’t let you get away with being a cowboy and choosing YOLO as your concurrency model.
Shared mutable state isn’t any harder in Rust than other languages. In fact, writing correct, bug-free and performant code is easier in Rust than almost any other language in common use, because the tooling is there. It’s just that the other compilers let you ship buggy code without complaining.
To the specific example, there are ways of sharing mutable state, or encapsulating changes throughout a UI tree. I’ve written a UI framework in Rust that does this. It is difficult to get right. But this is true of ANY language - the difficulty is intrinsic to the data type, if you actually care about doing it correctly.
That difficulty does not need to be exposed to the user. There are plenty of Rust UI libraries that take react-like lambda updaters, for example.
I still fail to see the connection to garbage collectors.
End-to-end types and a single(-ish) binary simplifies a lot of things. Plus you can always just .clone() and .unwrap() if you want to be lazy/prototype something.
[deleted]
jbfdrt7t(2)
Just in time for google to block sideloading and blocking new apps unless you pay them 6 figures...
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 current post.
What about iOS? As far as I know it should be similar or maybe simpler compared to Android. I haven't built it yet, but the next time I have a sizeable amount of free time, I'll try to make it work. The plan is the same: pick winit, wgpu, iced integration example, mix it together until it works. It'll require the same trick to load fonts, and maybe something else, but no visible blockers as of now.
Once again, thanks to all the people who made it possible and I wish you have a great time building mobile apps with Rust!