| ▲ | 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) | |||||||||||||||||
| ▲ | 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. | |||||||||||||||||
| |||||||||||||||||
| ▲ | evereverever 41 minutes ago | parent | prev [-] | ||||||||||||||||
Also accessibility. | |||||||||||||||||