Yes (from the README)

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.

> 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)

> So in case of slint, I would check how they solved the text inputs.

Slint uses the NativeActivity by default, but it supports IME by implementing the IME support in Java in the Slint's android backend.

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

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)

There is https://github.com/rust-mobile/android-view, although it's not currently being actively developed.

NativeActivity is already a thing and can be implemented in Rust

One language vs 3 or 4? And some folks REALLY like Rust

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 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`

They are slow and memory-hungry.

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.

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.

> 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!

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.

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++.

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.

Have you considered that people may join HackerNews who were not already on it?

Iced is the Elm architecture. Dioxus is more akin to modern React/whatever you want to call it.

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.

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.

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).

Hot reloading where?

Not at the level of JVM/ART, or even C++ on VS and Live++.