HN

Comments (60)

• yoan9224
  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.
• Menu

  denverllc
  Will apps built with this framework be compatible with accessibility features?
• Menu

  nicoburns
  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.
• Menu

  coldstartops
  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).
• anon
  undefined
• Menu

  vlovich123
  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.
• Menu

  NoboruWataya
  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.
• Simplita
  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.
• Menu

  serial_dev
  You gotta check Crux: Cross-platform app development in Rusthttps://github.com/redbadger/crux
• Menu

  androidinlimbo
  Android is in limbo, we need better free open source alternative.
• madduci
  I would like to get a benchmark of this against an app made with C++/Qt
• bbkane
  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.
• Menu

  zwnow
  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.
• Menu

  RicoElectrico
  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.
• anon
  undefined
• Menu

  jbfdrt7t
  [flagged]
• nubinetwork
  Just in time for google to block sideloading and blocking new apps unless you pay them 6 figures...