Product Launch
anonymous
151 points
76 comments
Posted12 days agoActive7 days ago
Iced
github.commvplibrarydevelopers
Key Features
Android app development using RustIced GUI integrationwgpu and winit support
Tech Stack
Rust
Key Features
Tech Stack
https://www.tomshardware.com/software/linux/linux-dev-swatte...
Murderous, vile Rust proponents will censor, downplay and distract from this.
So what do we think is more likely here? Jumping the gun due to your own dislike of some groups it seems.
Slint uses the NativeActivity by default, but it supports IME by implementing the IME support in Java in the Slint's android backend.
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'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 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 hate 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 I do not like Java (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
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. But I'm always on the lookout.
> I dislike Swift and find it to be an unpleasant language.
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.
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.
many company literally just give up use web wrapper instead because its just so much work
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.
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")
* 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.
There's a (Curry-Howard) analogue here with formal verification and counter-examples.
That makes no sense to me either, to be honest.
> 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...
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.
Rust gives you the same performance as C++ with much nicer language to work with.
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++.
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.
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.
See, both of us can make comments in that same condescending style, pretending to be polite.
I'd love to see something better here. I suspect it's possible.
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.
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.
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.
Not at the level of JVM/ART, or even C++ on VS and Live++.
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).
Still, I can see that they could eventually improve those issues.
There were no good examples for how to do this but once it was set up it worked extremely well.
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
I'd like to try iced, but switched to egui on the official Android support.
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!
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.