Crux: Cross-platform app development in Rust | Hacker News Reader

Crux: Cross-platform app development in Rust

redbadger.github.io

186 pointshomarp117 comments

It would be interesting to see, in a real world app developed this way, how much weight is actually being carried by the Rust portion. I feel like it might not be much? The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic.

And while can see the advantage of having a crossplatform layer for that stuff.. even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript.

But I'm willing to be convinced.

  > The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic.

its true, though it doesn't necessarily have to be that way (view models (or even bff) if done properly)

speaking from experience, i think the big issue is how will your dev team be structured... will android/ios people be able to write idiomatic rust (or whatever language) or should that core be a completely separate team? now you cant just hire any dev, they need to understand how it's going to be used by multiple client languages specific to that cross-platform system

though this framework looks like its pre-baking the architecture which means it probably wont look idiomatic from the client-side, so now your hiring for ui needs to take that into account... and now you have multiple teams that need to communicate adding overhead.

using cross-platform sounds simple and easy in the beginning but its a big commitment with multiple facets

i'm not sure what the real answer is... my guess is "it depends: what are you actually trying to do?"

This is a good point. I remember about 2005 time frame and probably even after everyone thought the front end was easy and the "real" work was on the server. What a joke.

Arrogance (trying to hide low self-esteem) has many faces.

> even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript.

UI libraries aside, Rust is better language and has better tooling, which overall contributes to productivity. TS/JS as a language for tooling is brittle and slugish (unless it's rewritten in Rust, where significant amount of tools is already heading), and I am happy for it to be replaced.

> UI libraries aside

I mean the rest of your comment may be 100% correct but we could stop reading at this point. Obviously the biggest pain point of Rust GUI app development is UI library.

True, it will take time. Tauri/Dioxus and others are still new and far from being mature. If you want to deliver project right now, Rust is not there, but moving in the right direction quickly.

Normally I agree with you on the tooling issue for JS/TS, but just look at the boilerplate you need for this Rust tool. I think it's very close in terms of obscure config files and tooling, complete with multi step build and generation processes.

I think Rust isn't a great frontend language for mobile platforms. Mobile applications are full of weak references because of how they can be unloaded or cached at any moment when the user switches to another application. The native APIs dance around this issue, but Rust can't. Of course you can use weak reference in Rust, but I find that this leads to very ugly code full of macros that aren't very Rust looking.

Boilerplate and process: This in part is a matter of tooling maturity and can easily be solved, and in part will be hidden in some github action, so I am not bothered (as long as solution is maintained). With amount popularity Rust tools have and increasing amount of money invested, I am not concerned here.

As for macros - yes, you will have them. Doesn't seem to be any more special than react or any other js framework where some magic is performed for you.

For mobile it may be very important performance for some cases (too repetitive or just heavy load) so using Rust allows to compile to the specific mobile architecture. The same is not possible with typescript which just run in the JSVirtualMachind

It's still mostly in the presentation layer. This framework is pointless and solves an already solved problem.

It depends on the application. If your app just displays data from a REST or GraphQL API it does not really make sense. But if your app is self-contained (it's mostly logic inside the app) it makes sense to have a shared core for models and business logic.

Matrix (primarily developed by the Element company) is rewriting its mobile apps based on a common SDK and rich text editor written in Rust:

https://github.com/matrix-org/matrix-rust-sdk

https://github.com/matrix-org/matrix-rich-text-editor

The apps themselves are written in Swift and Kotlin respectively, but it’s notable that they can now do this duplicate work much more sustainably because the bulk of their app code lives in a unified Rust layer.

I do this already, but with Flutter and Rust, via the FFI package flutter_rust_bridge. You can write your logic in Rust and transparently call the functions from the Dart side. The benefit is that you get rock solid business logic that can be compiled everywhere as well as a "write once, run everywhere" solution in Flutter. I don't see why you'd need or want to write even the UI layer from scratch every time.

If I can tell that your app is a Flutter app — and unless I’m stuck on an Android phone, I can always tell — your app is being uninstalled. Flutter looks wrong and behaves wrong and is just Google's modern reincarnation of Swing, which at least had its own display shape.

I will especially never use your web app if it is based on Flutter.

There's a reason that Electron apps get more grief from users of macOS than anything else, and Flutter is at least two steps worse than Electron IMO.

Good for you, but most people can't tell nor do they care, given that I've shipped Flutter apps across thousands of users, both consumer and enterprise, whom we collect feedback from. Not once did anyone complain about the app visuals or performance itself, just about the lack of features that they are looking forward to. For that kind of developer experience to consumer satisfaction ratio, Flutter is unbeatable. At least Flutter compiles to machine code instead of shipping a browser per app.

At least in the enterprise space, users are well accustomed to terrible design and UX, because the people with the purchasing power aren't the users, and the users have no purchasing power. Think JIRA, or Epic EHR, or SAP - everyone loves to hate it, but it is the go-to solution because it does what the people paying for it want.

The bar is so obnoxiously low in that space that your app literally just needs to work, and people are happy with it.

Same goes with a lot of prosumer software. People complain about missing features they need, because having a slick UI is very much a secondary concern, well after "is this actually doing everything I want it to do?" and "does it have all the features I want to accomplish my goals".

> People complain about missing features they need, because having a slick UI is very much a secondary concern, well after "is this actually doing everything I want it to do?" and "does it have all the features I want to accomplish my goals".

Well, yes, that is the point of software (and any technology in general), to accomplish the goal that the user wants to accomplish. I'm also not talking about prosumer apps per se, although I've made those too, but true consumer apps as well, no one has really complained about the UX, in fact they actually like that I'm able to make slick animations inside the app for quite a cheap computational cost. Since Flutter is basically a 2D game engine, it's optimized for those operations. I'm never gonna write 5 different apps for 5 different OSes anymore, it's a monumental waste of human labor.

I work in the enterprise software space and the last thing regular users want is a flash modern ui. They want familiarity, because enterprise software is like an extension of a user's mind and they want it to stay the same until they retire. I have seen first hand how a auto factory worker can capture data in a green screen terminal plastic covered keyboard faster than using a flash web UI and a mouse. Speed and familiarity are the orders of the day.

Indeed, it's akin to why some programmers like Vim and other terminal editors over GUI based ones. It's the exact same concept.

> most people can't tell

Hard disagree. I'd take the sibling comment about enterprise users getting used to poor UX and take that a step further: most users anywhere expect poor UX and expect to be ignored.

Take the Github UI refresh (yes it's not an "app", but hear me out). They've literally reinvented the text display widget in the browser. One of the core things that a browser does and Github reinvented it.

Public feedback has often been quite harsh. After a long public beta, it still choked on multibyte characters, it's laggy, it doesn't respond to keystrokes the way a native app (or even the browser itself) does, sometimes it displays spurious characters, and in some cases creates blurry text. Users have had to point out how to deal with multibyte characters Javascript, someone recently complained of excessive eye strain because text is so blurry.

What has Github done in the face of that feedback? They've doubled down on their custom widget and largely ignored the reported issues.

> For that kind of developer experience to consumer satisfaction

Again I strongly doubt you're getting an accurate measure of customer satisfaction if you think folks don't notice non-native apps. Earlier today I was actually trying to think of larger mac-native apps released by not-Apple and couldn't think of anything. The closest I could think of was Fusion 360 and that uses Qt.

As much as I notice how janky VSCode and Signal are, I'm not going to bother providing feedback that Electron sticks out like a sore thumb. With Fusion, the only feedback Autodesk ever responded to was the whole "hey you're pointing customers at staging resources" thing. It's a bit of sunk cost fallacy and a bit of "good enough". By and large once a company has picked a tech stack they're not going to move away from it without some serious motivation.

HN, GitHub and other such sites heavily skew towards developers who can tell, yes. I am talking about the vast majority of people who, I guarantee you, would not be able to tell a native component from a non-native one. The teams I have been on have done user testing for precisely this, comparing native vs cross platform frameworks as we were evaluating whether to use them or not. Literally 99% of the people we talked to did not notice or care, which actually falls in line quite nicely to how much of the US population are software engineers, ~1%.

If you doubt my results, talk to your non-technical friends and show them apps that are native vs those that aren't and hear what they say.

  Literally 99% of the people we talked to did not notice or care

Or they've decided there are better things to do than try to convince someone who's got a vested interest in defending their current tech stack. The text rendering problems with e.g. Github are something even a blind person could see – yet you're dismissing them as highly arcane things that only a developer would notice.

Actually, a blind person would also likely notice your non-native app because it almost certainly doesn't integrate well (if at all) with operating system accessibility features.

We didn't have a "vested interest" in any tech stack, this was all preliminary testing before we built out anything. If you want to take any evidence of what people empirically care about as being somehow a bias or flaw in testing methodology on our part, then do your own user testing and likely come to the same conclusions as us.

You've reduced the problem from something apparently everyone can readily see to now the blind (again, blind who? Blind developers). Accessibility is important which is why every cross platform framework of note has accessibility solutions, the web is not the only user interface that implements accessibility. This says nothing about how much people who are able-bodied care, which, again, is the vast majority of people who simply do not care. Just because one observes some problem to exist does not mean that everyone else feels the same, however much one would like to be vindicated of their experience of the problem.

  You've reduced the problem from something apparently everyone can readily see

And you've dismissed this as something only a developer would notice:

https://user-images.githubusercontent.com/1002257/248511013-...

https://user-images.githubusercontent.com/440661/246317472-a...

https://user-images.githubusercontent.com/128169473/23926115...

You're greatly overestimating how willing people are to take the effort to complain. At the end of the day non-native toolkits have lowered folks expectations to the point that (save for the occasional "why are computers so fast and apps so slow" comments) they're quite likely to accept a low quality app.

If you've got 99% of any group agreeing on anything subjective there's a problem with your measurement.

Sure, that's an egregious example, maybe GitHub did mess up, I won't deny that, but that one example is not indicative of the entire class of cross platform frameworks being useless.

> If you've got 99% of any group agreeing on anything subjective there's a problem with your measurement.

Okay, do your own testing and measure it however you want, then get back to me about methodological errors. Because as far as we can tell, most users do not care. In fact, we received messages about how happy they are with the apps and how slick the UX and UI are. You can make good and bad apps in any framework.

I have never seen this problem on GitHub, which platform does this happen in?

People care about battery drain: https://github.com/flutter/flutter/issues/59327

I have turned pessimistic on Flutter after they failed to fix this catastrophic issue for years, and I'm not someone who is ideologically opposed to cross-platform UI technologies in general.

Imitating native user interfaces takes a huge and continued effort. It's always a step behind and in danger of falling further behind. How long until it gets defunded?

It does suck that Flutter doesn't have as much bandwidth for people working on it as I'd like, but I'm not sure there's much one can do short of directly contributing and sending PRs, which it seems the author of that issue has done for a temporary fix.

The "temporary" fix is to allow developers to disable the cursor animation, i.e deviate from the native look & feel.

After almost four years of saddling every Flutter app that uses text input with anywhere between 5% and 20% CPU usage, this is what they have come up with.

What this tells me is that it is neither possible nor beneficial to imitate native UI toolkits using a completely different technology stack. It's simply the wrong architecture.

Well, I guess there's no free lunch after all. At least it's better than Electron in that it's compiled code, and that it works on 6 different OSes.

I disagree. Web technologies are highly optimised for what they do (i.e text field uses 0% of CPU), run compiled code on all platforms and don't waste resources on chasing this unachievable and pointless native fetish.

I don't understand your position. You're saying (correctly I think) that most users don't care about native. But then you turn around and choose an immature technology that spends a significant share of its budget on trying and failing to imitate native.

The bug I cited betrays the priorities of the project. They chose to prioritise chasing "native" over fixing a critical bug for many years.

Also, look at the large amount of investment going into web technologies - WebAssembly, WebGPU and many others. Even much criticised Apple is putting in a lot of work. I don't think the completely isolated Flutter/Dart team will ever be able to compete.

And how are those web technologies going for the bloat of Electron? There is no free lunch.

Flutter binaries and runtime are orders of magnitude smaller and faster than web technologies. True, they shouldn't be chasing native, but it's still better than what we have currently with trying to cover 6 OS with web technologies.

Not sure why you keep harping on Electron. It's not even available on mobile and choosing to distribute an entire browser engine with every single app is not the same thing as choosing web technologies in general. The Dart runtime isn't any faster than V8 either.

My point is that web technologies are quite poor for building multi-platform apps, something which Flutter excels at, even as it has its own issues. I consider those a worthwhile trade-off. I don't understand the points you're making, first you talk about battery drain, fair, then you talk about native, but it seems like you're missing the fundamental benefit of why some devs choose Flutter, which is that it works everywhere you need it to, and fairly fast, too. People use Electron for this generally, so that is why I brought it up, and I am saying that Flutter is a better alternative to Electron and other web technologies, and I am not sure exactly what you mean by web technologies, but I colloquially understand that to mean HTML, CSS, and Javascript. They are good at things like text rendering at 0% CPU precisely because they've been honed over decades, something which Flutter has not yet been able to.

The compiled code from Dart is faster than V8, even simply by virtue of being AOT compiled instead of JITed, not sure where you saw that it wasn't any faster. Also, web technologies do not run compiled code on every platform, they don't run compiled code on any platform, I'm also unsure of where you're making that claim from, unless you're talking about WASM which is still a ways away, and something that Flutter leverages too already (see their work on pushing WASM GC as well as their experimental build of Flutter Web with WASM GC), so it's not unique to web technologies like HTML, CSS, and Javascript.

It's incorrect to say AOT is always faster than JIT (without profile guided optimization). And it's reasonable to call jit-eligible code sometimes compiled.

That is true, I (and the parent) should not have made claims either way about their respective speeds without thorough benchmarks.

Client apps are most of the time not long running processes where JIT could reach steady state performance and startup time is important. So in practical terms, AOT is faster than JIT majority of time in this use case.

Also, look at this benchmark where native image PGO is now outperforming JIT in peak throughput: https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee0117...

>My point is that web technologies are quite poor for building multi-platform apps, something which Flutter excels at, even as it has its own issues. I consider those a worthwhile trade-off.

I have come to the exact opposite conclusion starting out with an open mind just like you. Flutter seems like a quixotic effort to me. Bugs like the one I linked to are a confirmation of that.

>Also, web technologies do not run compiled code on every platform, they don't run compiled code on any platform, I'm also unsure of where you're making that claim from.

JIT compiles to native code. WebAssembly is another option.

>not sure where you saw that it wasn't any faster

https://programming-language-benchmarks.vercel.app/dart-vs-j...

How would you make cross platform apps using web technologies, including mobile, desktop and of course web? I've tried a lot of web-based frameworks like Capacitor, Ionic, Cordova and even React Native (which isn't necessarily web tech as it's just a DSL to call out to native components), and I haven't really been impressed with either the performance or UX of any of them. They all feel (except RN) like you're using a website, not a native app, which is because that's basically what you're doing.

Thanks for the benchmarks, seems they're about even.

>They all feel (except RN) like you're using a website, not a native app, which is because that's basically what you're doing.

I mean, it really depends on the specifics of your app. For most apps it wouldn't hurt one bit if they were just good mobile websites or PWAs (possibly packaged for app store distribution).

For computation heavy code WASM is becoming a viable complement to JavaScript. WebGPU is on the way. And Figma has just sold iself to Adobe for $20bn after annihilating native competitors (I realise I'm painting in very broad strokes here).

I think there is a niche for mostly client side, offline-first apps that still have no need for deep integration with the native platform and are not games. But it's a small niche getting smaller.

The technogies living in this space will forever be changing, falling out of favour only to be replaced by the next attempt. It's been going on like this forever (Java Applets, Swing, Flash, Xamarin, ReactNative, Flutter...) It's not something I want to build a business or a career on.

But I guess if Flutter works for you and your users right now then why not.

Technologies like Flutter, Blazor, Rust GUIs that similarly draw to the canvas etc also are all leveraging WASM and WebGPU too though, so I'm not sure how much benefit there is on using the pure web for stuff like this. Even Figma's main canvas editor is written in C++ and some Rust, it's not using Javascript. I expect that if WASM and WebGPU become mainstream, people will simply use their programming language of choice and render to a canvas via WASM, and be able to port that to mobile and desktop. This is basically what Flutter does anyway so it's ahead of the curve of what you're predicting.

True, some apps could be packaged websites, but you will always be able to tell. The Twitter app is one example, and it's definitely not as smooth as 3rd party native apps, or even those made by React Native or Flutter. I simply consider PWAs a bad user experience based on the many I've tried.

I've had a decent experience building a webapp that can be used on the browser, and with some light packaging on the desktop and on mobile without being a full on electron app (webview instead).

At the moment it's a different tech stack for packaging mobile vs desktop app, but I'm waiting for Tauri to implement support for mobile to migrate everything to Tauri (I'm using a go webview library for desktop and capacitor for mobile).

Note: I know devs are usually allergic to multiple techs far various targets, but it was pretty much a one-off time cost, 99% of the dev time is spent working on the webapp itself.

> What this tells me is that it is neither possible nor beneficial to imitate native UI toolkits using a completely different technology stack. It's simply the wrong architecture.

IMHO, UI toolkits based on low level technology stack are the future. It just that they are massive undertaking. It's not impossible to implement cursor animation with low CPU usage.

> People care about battery drain: https://github.com/flutter/flutter/issues/59327

Yes, but this is a completely different topic.

Not if the topic is choosing a technology stack for mobile development. Battery usage is an absolutely key consideration. It's the one thing that many users will notice even if they don't care about tiny UI differences.

Except you were posting on a sub-thread discussing the importance of those “tiny UI differences”.

Also, battery usage isn't a native vs portable UI toolkit thing, it's an issue when using Flutter but can also be an issue when using SwiftUI.

>Except you were posting on a sub-thread discussing the importance of those “tiny UI differences”.

Not true. The sub thread was about whether or not users can tell the difference between native and cross platform apps, specifically Flutter, and whether they care.

satvikpendem wrote this:

"Good for you, but most people can't tell nor do they care, given that I've shipped Flutter apps across thousands of users, both consumer and enterprise, whom we collect feedback from. Not once did anyone complain about the app visuals or performance itself"

The context is everything and anything that users could notice and provide feedback on, not just visuals.

Also, I think you may have missed the link in my argument between battery usage and the attempt to imitate native visuals.

Sigh … It's 2023 and somehow some people still don't know how to use internet discussion boards… Come on, you've been lurking in there for the past 16 years!

The original messages in the sub-thread [1] and the message you were responding to[2] were about UI/UX. Had you responded to the even higher level comment you are referring to[3], then you'd have been on-topic…

The same way, if you started to criticize Crux (the topic of the OP) at this point of the thread, you message would be completely off-topic as well.

[1]: https://news.ycombinator.com/item?id=37699475

[2]: https://news.ycombinator.com/item?id=37699571

[3]: https://news.ycombinator.com/item?id=37699185

I do not accept that discussing battery usage in a debate about cross platform technologies is-off topic just because the direct parent comment didn't mention it.

The parent comment claimed that users don't notice the difference between native and cross-platform. I responded saying that even if they didn't notice the visual difference, they will surely notice the battery drain directly caused by the attempt to achieve accurate visual parity.

This is not off-topic by any reasonable standard. This is merely addressing a closely related and very relevant aspect of the same topic.

My statement wasn’t merely about UI. It’s about a lack of respect for conventions. It’s about many things that are inherently wrong with Flutter’s pretend-to-be-native approach, which happens to include UI boondoggles.

Flutter would have been better off with an entirely separate UI convention and stop trying to pretend to be like native apps. I’d still hate it because it really adds nothing to the story that wasn’t in Java+Swing two decades ago, but at least they could start paying attention to how poorly Flutter apps work in their intended contexts instead of trying to keep up with the Joneses.

The abysmal macOS System Settings, with how it cribs from iOS design language, seems to be doing what Flutter is accused of. Though perhaps that is less the fault of SwiftUI, and more of Catalyst.

> Good for you, but most people can't tell nor do they care

Yeah, Apple diehard fans like to repeat how consistent the experience is on MacOS, how incredible it feels compared to any other platform. But in practice very few people care: Windows has zero consistency anywhere (even in the OS settings themselves) and nobody cares, and even on MacOS nowadays, most people are using electrons apps daily, which breaks the conventions so even MacOS isn't homogeneous either in practice anymore (and Electrons app get a lot of flak on all platforms, but it's mostly about RAM usage and overall mediocre performance, and even then it's mostly nerds like us who complain).

> I can always tell — your app is being uninstalled.

I find this very hard to believe given how many big apps are written in flutter and life is made a lot harder without them.

Very weird hill to die on too.

No dog in the fight.

Which big apps are written in Flutter?

A few of the Google apps are. Google Pay (the new one), Google AdWords, and Google Classroom are big ones. Stadia and Grasshopper were both done with Flutter but are gone now. Toyota, BMW, eBay, Tonal Fitness, HERE Maps are all using Flutter.

YouTube Create, a competitor to TikTok's CapCut, is also in Flutter.

I have exactly none of those installed. The only Google app that I have installed on my phone is Meet, and I wish I didn’t have to have that installed because it’s the worst meeting app on my phone, but the company uses Google Workspaces.

I will go without an app rather than a Flutter app.

> I find this very hard to believe given how many big apps are written in flutter

I don't find it particularly hard to believe. Non-native apps easily stick out, but in cases where they're the most popular option their quality is irrelevant.

> life is made a lot harder without them.

That's a bit of a false dichotomy there, eh? If there were no easy way to create subpar cross platform apps, and the app itself were useful enough, surely someone would pick up the slack, no? The easy way out sucks, but it's just too tempting to resist.

you fairly easily tell on Android as well.

Imagine being so full of yourself that you think people care whether you uninstall their app or not.

Ditto, I can tell an app is flutter based on the slow launch times and inexplicable crashes. Example: McDonalds app

I can tell you’re just hating because Swing was awesome, and the de-facto standard for university HCI in my day (a day when HCI was the term for UX).

What’s an app *supposed* to look like?

I liked Swing, and I liked the "native" Swing look better than the "platform" skins that were offered (they just looked wrong everywhere). Swing failed for a lot of reasons, mostly because Java performance on the desktop just wasn’t where it needed to be.

Flutter feels to me like a half-assed rebaking of Swing's basic ideas with worse HCI/UX and an insistence on pretending look like the target platform even if they consistently get it wrong and perform slower than molasses in January. Flutter is something that only an Enterprise Developer could love.

That’s a fair assesment of Swing; Java really held it back.

It’s definitely not easy to nail the target platform, and that may be Flutter’s downfall. Even without those native-lookalikes, Flutter still has a very robust rendering engine, and easy to write ffi for native binaries. It can survive on its own.

Most users don't care.

As a counterpoint, the most thoughtfully designed and responsive task management app I've ever used is a Flutter app (http://quire.io) Maybe check it out and see if it changes your mind about what's possible with Flutter.

The biggest problem with cross platform phone programming is simply that it is phone programming, and I can't get any of the goddamn OSes to quit molesting my app.

"Oh, you want to do work? Oh, no, that's not allowed as that might actually use the battery for something other than serving ads, and we just can't have that."

Yes, I want to do this work. Yes, I want to do it on a thread. Yes, I want it in the bloody background. No, I don't want it randomly shot out from under me.

That's hard enough with a native framework. Good luck doing that on any of the cross platform frameworks.

Yes, that's always annoying. Cross platform frameworks just FFI into the native functions for keeping the app alive anyway, so it's functionally identical, that's actually one of the main things you can't fault cross vs native platforms for, in my experience.

This is an interesting project. The docs mention WebAssembly as a target on the Web side. And I wonder if there are plans to go further on this Wasm track. With Component Model and WASI maturing, polyglot component-oriented development also is within reach. A lot of this is working today.

As example look at wasmCloud [0] actor-based application framework which also separates business logic from capabilities / NFR's a la hexagonal architecture. And Cosmonic have built a capability-provider for event sourcing, called Concordance [1]. Everything in this setup is compiled into wasm modules that can be composed into larger components and deployed on any host you spin up.

[0] https://wasmcloud.com

[1] https://cosmonic.com/docs/oss/concordance/

This is an interesting architecture, but on at least two of the three target platforms, specifically Android and web, I think it would be better to use Kotlin Multiplatform [1] than Rust. Because Kotlin compiles to JVM bytecode (and ultimately to Dalvik bytecode) on Android and can compile to JS for the web platform, it means that for both of those platforms, the whole application can be compiled and linked together in a single type of object code, leading to lower overhead and a smaller bundle. There's also no need for serialization and deserialization when going between cross-platform and native code, further reducing bundle size; deserialization in particular requires heavy glue code.

But I don't yet have any experience with Kotlin Multiplatform, especially Kotlin Native for iOS. Does anyone know whether Rust has any particular advantages over Kotlin for any of the three target platforms?

[1]: https://kotlinlang.org/docs/multiplatform.html

this is pretty neat. I'm building a cross-platform project with yew and this should make things much smoother

I am, however, having trouble getting the examples to work. some issue with installing `aarch64-apple-ios` using `stable-aarch64-apple-darwin`

    error: failed to install component: 'rust-std-aarch64-apple-ios',
    detected conflict: 'lib/rustlib/aarch64-apple-ios/lib/libaddr2line-8a8c95c7e51dcc3f.rlib'

my rust-foo is limited, so I'll keep digging, but if anyone knows of a solution, I'm all ears and deeply grateful

I’m not convinced that this is a better approach than using Svelte 5 + Tauri. Web is here to stay and I’d rather not learn Swift and Kotlin. I know they say the native UI layer will be as thin as it can get but it still necessitates knowing those 2 langs.

You say that, but there's a lot of pushback against the electron apps for a while now. Tauri improves on that only a little bit. I'm going to go out of my way and lose some features happily is it means I'm using a native app these days, and I know other people do as well.

> I'm going to go out of my way and lose some features happily is it means I'm using a native app these days, and I know other people do as well.

People say this all the time, but in the real world, whether or not an app is native matters very little compared to everything else about it: features/content, design/UX, etc. And if using web technologies lets you build the app, say, twice as quickly, that means it will have that many more features or be that much more polished than the hypothetical native version, and that could mean the difference between having actual users and not having an app in the first place.

How do you feel about react native?

As a career mobile developer I honestly can't tell the difference between a well made react native app and a true native app

React is a terrible patchwork of a solution, which literally doubles the UI logic and work needed to get it performant. But it works, it solves the issue of being straight-forward to make platform agnostic by following tutorials.

I don't see any other way to go trully multi platform without making separate UI for Android and iOS. Or if you are going desktop, without using a platform agnostic graphics engine like something on top of OpenGL/Vulcan (which, v8 under electron is. A platform agnostic graphics engine). But, you are never going to get the native feeling/snapiness, because you are literally placing a canvas (your, multiplatfom app), on top of another canvas (Native UI engine of your platform)

IMO, if you want to build a service for someone, which carries some actual, real world utillity. And you can sell it to someone. You can't go wrong with a WebPageRenderer like Electron and some frameworks if choice underneath. This way, you can easily let the customer in on the joke from whatever device they are comfortable with. And only if you are working with a tool for pro IT or you are well funded, go for experimentation with faster UI. And even then it is not a rule, of which examples are VSCode & intelliJ dev tools. Both built on top of JS & Java platforms, both hindering their true potential like a stone tied the scrotum...

Great reply. That last sentence was pure art.

> I don't see any other way to go trully multi platform without making separate UI for Android and iOS.

https://avaloniaui.net/

Isn't that because React Native literally uses native components? It's not like Flutter which renders its own UI.

It's not about how well made it looks, or if I can tell a difference. It's: can I run a browser, Slack, Spotify, etc." at the same time without swapping. Turns out on a modern machine with a few Electron / Tauri / other apps running, the answer is no.

The entire point of Tauri is to not spawn another browser process for every other app, and thus be able to run many apps simultaneously as easily as running many websites simultaneously. I think you misgeneralized here.

This helps with the binary size, but not memory usage. You still effectively need the browser initialised in your process. See their own memory benchmarks: https://tauri.app/v1/references/benchmarks/#memory-usage - it's basically in the same range as electron.

I think you’re mistaken. Electron apps bundle a specific version of the browser with themselves (which often doesn’t match the user’s version), thus loading up to twice amount of libraries and all the dependencies. This increases memory usage. Also the linked benchmark shows Tauri uses significantly less memory than Electron. 540MB vs 270MB in best test cases.

370 not 270. In the other test it loses, so it's not really conclusive.

It's true you have to load up more code for electron, but not everything in the chrome package is code and lots of it gets mmapped anyway. A large part of the memory usage for the electron/Tauri apps is the chrome heap and loaded app resources - that doesn't get deduplicated. An empty chrome (just started with no tabs or extensions) uses 350MB of RSS memory for me. That's going to be slightly lower for electron, but that value will be the lower bound for every single electron process started.

That pushback is localised to informed people (typically developers) not the public at large. They're using Electron Apps all day.

I’m a developer and I’m also using web apps or electron apps all day.

VS Code, Slack, Spotify, GitHub (for basic pre commit diff review I quite like their app), and figma are all Electron apps and are pretty good today.

So many web apps that I can’t count and many of them are passable. Still the Electron apps tend to be more polished (even their web versions).

I am so glad that Electron makes must haves for me like Signal possible.

Electron apps are great themselves. It’s when you are in a 3rd world country where all computers are old or when you are working on an underpowered machine it becomes a problem. Spawning a new browser process consumes resources like there is no tomorrow or other programs running simultaneously. This is the problem Tauri addresses.

Then that means we need to do a better job of informing the public about how wasteful our industry is being of their computers and, indirectly, their money. To do otherwise, to keep them in the dark, is disrespectful. My hypothesis is that once non-developers are informed, they'll care. They probably already feel that something is wrong but can't articulate it, and have perhaps resigned themselves to a crappy experience.

Developers can point at the issue. The less informed say "my computer is getting old" or "can you clean my laptop so it works faster". We're able to say "5 simple apps taking 24GB of ram is absurd".

How are you sold on Svelte 5 when it isn’t even released for download as a beta yet?

I saw Runes and that was what I needed to see. Svelte is continuing on its original vision to reach its logical conclusion of easy web application development.

Or else you could of course just use https://rocket.rs/

I mean, honestly. What more do you need than a simple and fun library for the API to the backend? It's 2023 and the cross-platform user interface is the web, the rest has lost, and your devs and cross-platform community is on the web. Even a biased company like Microsoft don't seem to pretend anything else these days as they base their large scale (Office, Teams) apps on... YEP you guessed it, the web.

That looks like a backend web framework to me. Did I miss something?

I believe the point of the original comment is that if you’d really like your business logic to be written in rust, you can already do so by building a backend service with a mature rust library & access it via web.

Rocket is borderline dead so it’s weird look for OP to suggest it.

There are several apps that just do not work on the web inside a browser. If an app is anything beyond a single page app, it effectively requires being a desktop app.

It makes no sense to me when people say desktop apps are dead and that web apps are where it's at, when web apps run in a browser which is a desktop app. It's like claiming containers won and operating systems have lost.

> I mean, honestly. What more do you need than a simple and fun library for the API to the backend? It's 2023 and the cross-platform user interface is the web, the rest has lost, and your devs and cross-platform community is on the web. Even a biased company like Microsoft don't seem to pretend anything else these days as they base their large scale (Office, Teams) apps on... YEP you guessed it, the web.

This makes it make less sense now. Office you can get in a browser, but it's terrible, and Teams is a local client-side app. Or am I mistaken? Could you make the Teams client with rocket.rs?

I thought this was going to be related to Crux[0].

[0] https://crux.nu/

Name collision with https://crux.nu/

That's the risk of using simple English (or, I guess Latin) words as your brand name.

There shouldn't be too much confusion, though. Crux is either a niche Linux distro or a cross platform build tool, or a business intelligence tool, or a finance provider for green electricity. All of these names can coexist without confusion.

what about accessing device's hardware features?

(just a wild ass guess, I don't have experience with crux)

> It splits the application into two distinct parts, a Core built in Rust, (...) and a Shell, built in the platform native language (Swift, Kotlin, TypeScript), which provides all interfaces with the external world.

The "external world" includes hardware features, camera, notifications, payment APIs, NFC, gyroscope, etc. The way I imagine it is: as long as the Rust part can talk to the native part, "everything is possible" and you can send commands from the Rust part and send the results back from the native part (or vice versa) or probably even set up streams of data (e.g. live updates to gyroscope).

Flutter has platform channels that is a similar idea. I expect it's even easier in Crux because in Flutter almost everything is written in Dart, and Crux leaves more to platform specific stuff

https://docs.flutter.dev/platform-integration/platform-chann...

Just to clarify, does "cross-platform" in this case mean only {iOS, Android, Web}?

Apparently yes. But we have installable PWAs, so…

I suppose on desktop (windows, linux, macos, ...) you could use the rust component as a normal library without the need of special stuff like on android ios and web

Windows can run APK files natively these days: https://learn.microsoft.com/en-us/windows/android/wsa/

ChromeOS runs Android apps as well.

Apple has Mac Catalyst (https://developer.apple.com/documentation/uikit/mac_catalyst) which may just work with this wrapper.

Linux can run Android through Waydroid (though doesn't work as well as on Windows).

PWAs can be installed to desktop on practically any browser that isn't Firefox to make them look like native applications with icons and protocol/share handlers and all.

So technically, it's cross-platform as in "mobile apps that will work on desktop if you like a terrible experience"

This is your friendly reminder that Spotify went out of their way to write a networking library that wraps platform specific network libraries since iOS will have special-ish behaviors that you lose if you aren’t using their stack.

I am the biggest proponent of Rust where possible but I always feel like this is worth mentioning when people bring up moving all shared logic for mobile platforms to Rust. It would be great to see it reqwest/ureq/etc could have a feature flag to use these behind the scenes:

https://github.com/nativeformat/NFHTTP

Also: if anybody from Spotify is reading I would love to know why it’s discontinued and passed to community maintenance. Alternatively, if someone from e.g Apple would weigh in on how much this still matters it would also be welcome.

I think I've seen you mention this before here, and it led me to writing a note about this topic in some documentation at work. So, thanks for the heads-up. Do you have any idea what would be required to write a URLSession backend for ureq/reqwest?

To be honest I've not looked into how tricky it would be - if anything I went the opposite route of experimenting with a reqwest-API-compatible wrapper for URLSession but didn't get too far due to other projects taking up my time. It might be the easier path though - one crate that basically uses a `reqwest`, `ureq` or `URLSession` backend since the former two would still work on Android to start.

For reqwest specifically I guess it would also depend on how badly you want `async` support or not (i.e just the blocking module API).

Thanks, sounds like your initial approach would be easier, a blocking API is fine for me. I'll look into it a little further.

On Android, this uses curl and not HttpUrlConnection so its not very native.

I'm not sure if HttpUrlConnection is still the way to go on Android. Its lack of caching providers has driven most apps to using other HTTP clients (often from Java land, but also some Kotlin native wrappers).

The Android SDK docs provide an entirely different approach to "simple" HTTP requests: https://developer.android.com/guide/topics/connectivity/cron...

It appears Google recommends CroNet, which is Chromium's network stack. I can see why (the Chromium stack is probably the most optimised stack for client-server applications that Google maintains) but even Google seems to have abandoned their Java 7 wrappers for something better.

I wouldn't have picked curl for Android myself (CroNet sure sounds like it makes more sense) but it'll work just as well and saves everyone the time of figuring out obscure errors that will undoubtably show up eventually writing wrappers like these.

Ah..thanks for the info. They have yet to update their training articles. Still demonstrate use of the old HttpUrlConnection. https://developer.android.com/training/articles/security-ssl.

HttpUrlConnection includes a response cache (android.net.http.HttpResponseCache) actually. The Android implementation has significant differences from the usual JDK implementation.

I think "they have yet to update their training articles" is a great summary of the introductory Android documentation.

They give you the basics in the form of useful guides, then tell you to use the more modern API (Jetpack and such). The Jetpack documentation often comes down to Javadocs and one or two bits of example code of very specific use cases.

This is especially annoying when there are multiple "new" libraries. Last time I tried to relearn native Android development, I got halfway through the "new" way to do things before Android Studio told me the stuff I was doing was deprecated and referred me to a whole different library without any useful training materials.

At some point Google should really just redo their documentation to get everything in sync.

You are correct; this gets brought up whenever I bring up the point. :)

I'm mostly putting it out there to make people realize that their pursuit of isolated library code is potentially missing out on obscurely documented reasons as to why one should consider the built-in APIs. I would say anything that might exist to cover this in Rust should not use `curl` under the hood either, though in practice I think that's unlikely to happen since Rust (IMO) has a stronger networking story.

Reply on news.ycombinator.com