Remix.run Logo
yoan9224 3 hours ago

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.

lukax 2 hours ago | parent | next [-]

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

nextaccountic an hour ago | parent | prev | next [-]

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

nicoburns 3 hours ago | parent | prev | next [-]

Rust also has good IDE support and hot reloading. Mobile tooling and libraries for mobile APIs are definitely where it's still lacking atm.

pjmlp 2 hours ago | parent [-]

Hot reloading where?

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

nicoburns 2 hours ago | parent [-]

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

evereverever 41 minutes ago | parent | prev [-]

Also accessibility.