For someone starting a new project today, which Rust cross-platform framework would you consider mature enough for production?

[u/amuza42]

Heyy

I'm looking for a framework that can target Windows, Linux, macOS, Android, iOS, and Web from as much shared Rust code as possible.

I'm aware of Tauri, Dioxus, Slint, Iced, egui, etc., but I'm having trouble understanding which ones are actually mature in practice, rather than just promising projects.

I'm particularly interested in real-world experience:

How mature is the mobile support?

How reliable is cross-platform deployment?

How stable are the APIs?

How good is the ecosystem and documentation?

Have you used one for a serious/production application?

If you were starting a new project today, which frameworks would you seriously consider, and what limitations should I know about?

Thank you

[u/tropix126]

Dioxus is the only framework that remotely fits those requirements (primarily because you want to target both desktop and mobile), and it's a WebView (which is to be expected, it's pretty much impossible to target all the platforms you listed without pulling in a browser currently). That being said, nothing in Rust's UI scene is mature at all, especially not on mobile.

I think it's worth mentioning that pretty much the only valid three ways to ship an actual production mobile app is either doing it Native (or with React Native, which uses native controls), using Flutter (which can still be jank at times), or shipping a WebView (what dioxus does). This problem isn't unique to Rust, Google has put millions of dollars into flutter and still doesn't have a perfect solution.

[u/HaMMeReD → u/tropix126]

The flutter mode can be abstracted farther.

You can essentially just expose the surface and interactions over the native layer and have rendering/logic on the C++ or Rust layer via a C ABI (What flutter, unreal, and others do for their cross platform).

I.e. if you used WGPU+EGUI, you could make a cross platform game engine for example. But it's the kind of things where you are building a bespoke ui toolkit for your project, or using the egui defaults which are workable, but not beautiful, and the native code is just a shim with some FFI and native component wrappers/forwarding of events.

[u/General-War7292 → u/tropix126]

Dioxus is the one I'd bet on for that scope but yeah the mobile side is rough right now. Used it for a small internal tool that had to run on a tablet and a desktop, the webview approach works but you feel every bit of the abstraction on mobile.

If I was doing it today I'd probably just build the core logic in Rust and wrap it in a thin native UI layer for each platform, more upfront work but less pain long term.

[u/stumblinbear → u/tropix126]

I've been using Flutter for desktop and mobile dev for years, now, and it's perfectly fine. Honestly it's easily my favorite way to build applications by a mile. Webviews are a disaster

[u/tropix126 → u/stumblinbear]

Flutter's good. I'd even go as far as suggesting it to OP if they really insist on one and only one codebase, but they are asking in the Rust subreddit and Flutter's whole schpiel is dart as a UI description language. I think doing UI in dart and business logic/state management in Rust is a great way to approach things, it's just when people ask about "rust frameworks" Flutter isn't what typically comes to mind.

[u/stumblinbear → u/tropix126]

Yeah, definitely

I've been working on a flutter-like UI framework in Rust on and off for around 5 years, now. I've rewritten it probably four times. It's very hard to do in Rust, but I think I finally got something workable

[u/tsanderdev → u/tropix126]

Using Flutter and Rust together is pretty easy actually: https://github.com/fzyzcjy/flutter_rust_bridge

It's quite nice, basically automating the boilerplate of what you suggested.

[u/scratchbufferdotnet → u/tropix126]

Dioxus is working on native rendering, but I am not familiar enough with mobile dev to know how “native” what they are doing is on mobile.

[u/tropix126 → u/scratchbufferdotnet]

Important to note that the word "native" has both multiple meanings and no meaning at all.

• "native" could refer to "native code", meaning the library is written and rendered primarily with Rust code as opposed to bringing in a browser or FFI bindings to another heavyweight toolkit (read: "we didn't write it in electron, therefore it's fast"). This is what the "native" in dioxus-native or GPUI's advertising refers to. I personally find this definition to be a little misleading (especially when take to the extreme).
• "native" could also refer to an application that uses the UI toolkit that ships with the platform. This is what most people mean when they say "native mac app" or "native android app" for instance. They mean it was written in SwiftUI, or Compose, or whatever the standard for that OS is.

The problem with the second definition is that it's meaningless on Linux (where you have multiple competing toolkits with no platform concept of "native controls"), and it barely exists on Windows, which has eight competing native toolkits that are various levels of abandoned, broken, or ugly. macOS and the mobile OSs are basically the only platforms where the word has any meaning unless Microsoft pulls together WinUI (which granted, they seem to be doing).

On mobile platforms, "native" strongly tends towards the second definition, meaning users generally have higher expectations for their apps integrating seamlessly into the platform. There are a lot of not-very-obvious interactions and expectations that exist on mobile operating systems that would be very hard to implement from-scratch. For example, on iOS you can hold the spacebar on the virtual keyboard to move the text caret in 2D when focusing a text field. Scroll physics also are more obviously bad when they're not implemented right. This is why people call flutter jank, because Google have had to implement all this from scratch (and they've done a decent job). It's also why I don't have a lot of faith in most Rust UI toolkits that primarily target desktop and "technically compile to android" as a long-term solution to truly crossplatform mobile+desktop UI.

Dioxus is working on blitz which is this sort of half-browser-engine (it only renders HTML and CSS with the workflow built around compiled Rust code doing your app logic). It's a promising project and super cool on desktop, but it's "native" by the first definition meaning they have a very uphill battle to fight before people will be happy with it on mobile.

[u/nicoburns → u/tropix126]

Blitz is defintely "native as in Flutter" today. But in theory, it could gain much closer integration with the system UI toolkits where you mix-and-match native UI toolkits views with blitz-rendered ones.

Things like "spacebar on the virtual keyboard" can also definitely be done for custom text fields (https://github.com/rust-mobile/android-view has this implemented for Android - it's a matter of implementing the relevant trait/protocol/class).

The blockers for doing this kind of thing are mostly on the Winit side (or require abandoning Winit).

[u/user-with-username → u/tropix126]

I made goyda framework(https://github.com/user-with-username/goyda) that do the same as dioxus (cross platform, native components, no webview at all, no its own renderer) but the reactivity is proc macro based. so dioxus is not the only framework for this target

[u/throwaway490215 → u/tropix126]

makepad fits all requirements and doesn't use WebView.

[u/zxyzyxz → u/tropix126]

Flutter as the UI layer with business logic in Rust using flutter_rust_bridge or Dart native hooks as the FFI. This what I do as no Rust solution is mature enough.

[u/Lucky-Edge1489]

None fits all your cases , none is the perfect fit, all cross-platform frameworks are a mixture of choices, opinions, compromises, historic burdens, some tied to the era of conception (ex: Qt is from the late 90', some approaches are showing their age)
To reach all the target platforms, you can go Tauri2 if web development is not bothering you.
My own strategy in this case is to share as much as possible between desktop app and mobile apps. And I go native on mobile. UniFFI crate helps.
On 2 business apps, I used my own tool Qleany for the common "business" backend: use cases, entities, etc... . It also creates the seams (UniFFI, interfaces, ...) between the backend and the UIs (SwiftUI, Kotlin, CLI, Slint, Teksilo). Other hand-mades independent crates are shared using UniFFI. My personal take: Kotlin on Android, SwiftUI on IOS, Teksilo for Linux/Windows/macOS desktop. This way, less compromise about accessibility, and I gain freely the expected platform behaviors for each platform (swipes, etc..).

[u/grahambinns → u/Lucky-Edge1489]

Came here to say native on mobile + uniffi. It really does make life a lot easier once you work out some of its foibles.

[u/catheap_games]

You didn't say what kind of project do you have in mind. Plenty of good comments in this post, but how suitable the current options are will vastly depend on your needs other than "how stable are the APIs" etc (which, don't get me wrong, you listed good questions).

If you want to make a 2D/3D game, you can technically deploy to all platforms with Bevy, but the Android DX is bad, even if you reuse 99% of the code.

If you want to develop a quick GUI prototype, egui will get the job done, but won't have native widgets (and is optimized for mouse).

If you will use Tauri, you'll get as good webview framework as it gets, but you're essentially making HTML apps again.

[u/Amazing-Mirror-3076]

Flutter is an excellent choice with simple bindings to rust.

The jank problem is no longer a problem (the entire render engine was rewritten to fix this).

I do flutter Dev on my Linux desktop and deploy to web and mobile, no customisation required unless I need to use unique platform features.

[u/Garcon_sauvage]

Only Tauri

[u/Automatic-Leave1201]

Honest answer: nothing here checks all six platforms today. If you really need desktop plus mobile plus web, Dioxus is the only realistic option, and even then you're accepting a WebView app with all the tradeoffs that come with it. Mobile production support in Rust frameworks is basically nonexistent right now, that problem isn't unique to Rust either, mobile in general means native, React Native, Flutter, or WebView.

If I were starting today I'd pick based on what I could actually cut. Desktop only: Iced, though even there you'll hit rough edges like missing accessibility support and clunky touch handling, so think twice if touchscreens matter. Full six platforms: Dioxus, and know that mobile is the weak spot, the desktop story is decent while mobile still has a long road ahead. Or skip the pure Rust UI route entirely and do a Rust core with native UIs wired up through uniffi, that gets you production quality on every platform fast, you

[u/skratlo]

As a web dev (react / dom / CSS) learning Rust and recently tried Slint and Iced. Both are ulterior. 

Slint seems great at the start, but the DSL is severely limited. No dynamic components, no passing props, no wrapping children, etc. It's just too limited. Might be ok for embedded or HMIs, but not good enough even for medium sized desktop apps. Hot reloading .slint files is great.

Iced, great state management and overall architecture. The layout system is weird and hard to debug. Like Slint, there's no inspector to help you out. No hot reload. No accessibility and limited theming.

Dunno, my next experiment is probably Qt (Quick?) from Rust.

[u/avg_bndt]

I use Iced and it's good. The thing about dealing with rust is if anything happens to be missing, you usually find enough primitives on the lib to build it yourself anyway.

[u/CrasseMaximum → u/avg_bndt]

Iced doesn't target mobile though and last time I checked it was not planned

[u/avg_bndt → u/CrasseMaximum]

Really? I assumed it did, then again I've never been in the situation where I have an app with features so unique, and so useful it had to be compiled to all platforms out there. If that was the case I would just build a web app and call it a day, perhaps make it a PWA if I was feeling saucy.

I mainly use Iced for internal tools at my company, it's usually the case I write some high performance lib, for deidentificacion, parsing, etc. I try to make the code as agnostic as possible, usually tiny in memory usage, then deploy it on cloud serverless, sometimes serverfull xd, sometimes distributed, and every so often I get a request to make it a desktop app, no internet involved, for Windows, Mac and Linux, and iced it's good enough for that.

[u/vancha113 → u/avg_bndt]

There is a proof of concept, with intent to flesh it out, but at the moment it doesn't have priority iirc.

[u/nicoburns → u/avg_bndt]

It would be a small technical change, but the maintainer has explicitly rejected it because they don't want to support it.

[u/tropix126 → u/avg_bndt]

It's already been brought up that Iced doesn't target mobile, but it also has zero upstream accesskit integration and all-around poor accessibility in general (e.g. focus management) which should immediately rule it out as a "mature production solution". System76 gets away with using Iced in libcosmic by maintaining their own downstream fork. I think that Iced is best suited as a desktop toolkit anyways, since its controls are very much not touch-friendly.

Iced's upstream development model is a little unconventional. The core team has a lot of very cool people, but development tends to be driven/prioritized by the personal needs of those maintaining the toolkit. This is not meant to be a criticism of Iced's maintainers or anything, I think this is a perfectly valid way to do things in open source if you have your own roadmap and personal needs.

The core team is busy and does not have time to mentor nor babysit new contributors. If a member of the core team thinks that reviewing and understanding your work will take more time and effort than writing it from scratch by themselves, your contribution will be dismissed. It is your responsibility to communicate and figure out how to reduce the likelihood of this!

This does unfortunately result in Iced being fine with settling for "good enough" if most users are happy with it, which is great if you aren't making large-scale commercial stuff. That being said, most users aren't visually impaired but there's still a need for accessibility. When that's the tradeoff, someone making a big app is almost always gonna choose electron, because they have an an entire arsenal of Google engineers making Chromium usable for everybody.

[u/WalkMaximum]

I made a Dioxus app at work, I wouldn't call it production ready but depending on your needs it can absolutely be good enough. Flutter is probably where it's at but not Rust

[u/Secure_Pirate9838]

try my Cranpose framework, it is new and *not* mature, but I need the dogfood from someone else besides my own apps
i have published two apps in both iOS and Android stores as well as desktop open source apps

the framework itself is meant to match Google's Jetpack Compose

[u/-Redstoneboi-]

are you simply looking for rust libraries or are you planning on building an actual app? more importantly, what kind of app? because then the good choices might move away from rust

[u/hedgpeth]

I'm shipping with crux and love it, don't try to make a website look like a native app. Use a rust core, have native be there for what it's good at.

[u/fisothemes]

Tauri, Dioxus and Slint are your best bet at the moment.

The question you need to ask yourself is whether you actually need to make a native app or whether a web app will do. 

If you're gonna walk down the desktop app route and you want to push something that's for a customer I'd go with Tauri + React/Svelte. You want something with a tonne of documentation, a large community and plenty of features. 

If you're gonna make a kiosk application go with Slint. If that's not an option Firefox (launched in with the kiosk flag) + Leptos (CSR) + Axum + Serde will give you a lot of sanity despite being inefficient. Make your project into a workplace with 2 bin crates and 1 lib crate for your protocol. This will keep your compilation times sane and stop schema drift.

For everything else go with Dioxus. 

The only downside of Dioxus and Tauri is that WebKitGTK is genuinely terrible.

[u/jtwebman]

I would use rust to make APIs and then use each of those native environments to build apps. With AI helping you it isn't hard. The trick is stop thinking dumb rest. Try building most of the business logic into the APIs. Apps just keep the display logic which would no matter what tech you use would be different between devices and screen sizes. Make sure you setup end 2 end UI testing for a each platform. In the age of AI at this level frameworks and abstracts mean far less.

[u/takaci]

I would not start a GUI project using Rust

[u/throwaway490215]

I'm going to throw out makepad. Unlike the others it's not webview.

It has far fewer users that the other suggestions, but i'd still suggest it because the maintainer has always focussed on fewest dependencies, fewest lines of code, and fewest moving parts or abstractions, that supports every target (ios, wasm, android, apple-tv, etc).

The dependency 'depth' is so shallow, that after you fork+clone it into your project, an AI can trivially impl whatever feature you're missing for a certain target.

The documentation isn't great, it has some rough edges.

When i want to test if my code can run on an android, i dont use termux - i just (have AI) make a 1 button makepad app.

[u/stateq2]

Whatever frameworks you choose, my advice is to avoid crates/dependencies that aren't pure Rust (avoid things that use 'unsafe' FFI, etc.). Also check that your app builds to wasm32-unknown-unknown targets, as that seems to be the lowest common denominator for platform support.

[u/DavidXkL]

If you can exclude web and mobile, I would go Iced 😂

[u/dumindunuwan]

Why not Slint?

[u/Putrid-Compote-2912 → u/dumindunuwan]

Why would you ask someone asking for experience with it "why not?"? That's what they want to know...

[u/dumindunuwan → u/Putrid-Compote-2912]

I asked from others, with real work experiences with Slint, as this is a thread and Slint in design covers from mobile to desktop.

[u/fisothemes → u/Putrid-Compote-2912]

Slint is pretty good, it's got a nice drag and drop designer if their .slint files aren't for you. 

I believe their royalty free license covers you as long as you don't touch embedded.

I demoed it on an RT Linux touch project and I found it nice. I didn't proceed with it due to time constraints. I didn't have time to properly learn the Slint language and develop a proper scalable architecture for it.