Get the top HN stories in your inbox every day.
cmrdporcupine
erlend_sh
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.
mdgrech23
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.
scns
Arrogance (trying to hide low self-esteem) has many faces.
andrekandre
> 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.
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?"
fiedzia
> 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.
raincole
> 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.
fiedzia
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.
jeroenhd
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.
fiedzia
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.
lukax
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.
nijaar
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
proxyon
It's still mostly in the presentation layer. This framework is pointless and solves an already solved problem.
satvikpendem
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.
halostatue
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.
satvikpendem
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.
zdragnar
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".
littlestymaar
> 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).
inferiorhuman
> 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.
wwtdtgotiatl
> 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.
inferiorhuman
> 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.
dfee
No dog in the fight.
Which big apps are written in Flutter?
Kiro
Imagine being so full of yourself that you think people care whether you uninstall their app or not.
nyanmatt
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?
halostatue
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.
vczf
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.
dingi
Most users don't care.
sunshinerag
Ditto, I can tell an app is flutter based on the slow launch times and inexplicable crashes. Example: McDonalds app
skavi
you fairly easily tell on Android as well.
bsder
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.
satvikpendem
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.
rapnie
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.
mwcampbell
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?
airstrike
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'
Aerbil313
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.
viraptor
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.
willdr
That pushback is localised to informed people (typically developers) not the public at large. They're using Electron Apps all day.
charrondev
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).
viraptor
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".
mwcampbell
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.
RussianCow
> 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.
bhdlr
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
high_priest
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...
satvikpendem
Isn't that because React Native literally uses native components? It's not like Flutter which renders its own UI.
viraptor
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.
ComputerGuru
How are you sold on Svelte 5 when it isn’t even released for download as a beta yet?
Aerbil313
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.
jug
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.
bmitc
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.
robertlagrant
That looks like a backend web framework to me. Did I miss something?
robertlagrant
> 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?
undefined
Zambyte
I thought this was going to be related to Crux[0].
[0] https://crux.nu/
blueflow
Name collision with https://crux.nu/
jeroenhd
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.
AbuAssar
what about accessing device's hardware features?
serial_dev
(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...
lainga
Just to clarify, does "cross-platform" in this case mean only {iOS, Android, Web}?
jeroenhd
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"
SushiHippie
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
Aerbil313
Apparently yes. But we have installable PWAs, so…
undefined
Klonoar
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.
jamil7
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?
Klonoar
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).
jamil7
Thanks, sounds like your initial approach would be easier, a blocking API is fine for me. I'll look into it a little further.
lenkite
On Android, this uses curl and not HttpUrlConnection so its not very native.
jeroenhd
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.
lenkite
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.
Klonoar
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.
undefined
Get the top HN stories in your inbox every day.
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.