Eh. Crossplatform isnt the problem here; Xamirin is. There’s a host of next gen cross platform frameworks like Flutter, React Native, Blazor that save you having to maintain two distinct apps; something that’s only going to add a bunch of developer burden
Personally, beyond a few material-like components I always prefer it when an app goes for its own system-agnostic design language like Spotify does. On desktop I’m definitely more picky if I can get away with it; Qt dor KDE and GTK for GNOME etc
I have given up on the fight a long time ago. On the desktop the only line I draw is that the app must respect system font configuration and use system-provided file dialogs.
Same with Compose even though it’s ironically considered native in the Android dev community.
The easiest way to tell that the app is not native is tooltips (those that appear when you long press on a button in a toolbar). For some reason UI frameworks just can’t agree to display them in the same way, even if they use material design. Compose’s ones are especially bad (some apps like Play store actually have different kinds of tooltips on different screens, meaning they use multiple UI frameworks in the same app).
Agree. Will it be as performant as native? No. But will it be plenty performant for a password manager, yes.
The only thing I wish RN and Flutter would figure out is bloat. File sizes are huge compared to native. A shame there can’t be a shared model in mobile apps for the core system.
Flutter is native. It gets compiled to an executable, it just takes a render plane from the underlying OS and renders everything in it’s own engine. They’re working on a new render system that will make it go even faster.
React Native is just a fancy web browser wrapping with some helper APIs.
RN is native too I think, at least it advertises itself as a way to compile some kind of XML syntax into native widgets on either platform. An improvement to PWAs even if I despise typescript
yeah, it displays native widgets but there is still a js engine (browser) running in the background. So the basically made a layer between native components and Javascript. But the code which is running is js and js is slow.
JS by itself is very fast (it’s one of the fastest dynamic languages). It’s interop with platforms APIs that is slow, at the fact that each React app spins up its own instance of Chromium also doesn’t help.
I guess smaller apps would be nice but that’s also a thing that can be helped - I have a handful of flutter apps on my phone right now (that i know of) and they run in at:
18MB - Nextcloud recipes client
50MB - Spotube (Youtube music client with spotify integration)
100MB - My job - a savings and investments app, with half a dozen third party API integrations.
So depending on your scope and stuff you can really build an app to whatever size. Cant account for react native or blazor but the idea is usually just abstract native graphics APIs instead of using a browser runtime.
Eh. Crossplatform isnt the problem here; Xamirin is. There’s a host of next gen cross platform frameworks like Flutter, React Native, Blazor that save you having to maintain two distinct apps; something that’s only going to add a bunch of developer burden
I always recognize Flutter apps on Android as being non-native and avoid them because of this.
I think it is because they seem to never use the system font but Quicksand instead and all the animations feel slightly off.
Personally, beyond a few material-like components I always prefer it when an app goes for its own system-agnostic design language like Spotify does. On desktop I’m definitely more picky if I can get away with it; Qt dor KDE and GTK for GNOME etc
i love having all my apps match my system, gtk or qt for desktop mui for android
I have given up on the fight a long time ago. On the desktop the only line I draw is that the app must respect system font configuration and use system-provided file dialogs.
Same with Compose even though it’s ironically considered native in the Android dev community.
The easiest way to tell that the app is not native is tooltips (those that appear when you long press on a button in a toolbar). For some reason UI frameworks just can’t agree to display them in the same way, even if they use material design. Compose’s ones are especially bad (some apps like Play store actually have different kinds of tooltips on different screens, meaning they use multiple UI frameworks in the same app).
With Compose apps I actually never had this problems yet.
It looks mostly the same as XML views but some components look and behave wildly different for no apparent reason (tooltips are one of those).
Agree. Will it be as performant as native? No. But will it be plenty performant for a password manager, yes.
The only thing I wish RN and Flutter would figure out is bloat. File sizes are huge compared to native. A shame there can’t be a shared model in mobile apps for the core system.
Flutter is native. It gets compiled to an executable, it just takes a render plane from the underlying OS and renders everything in it’s own engine. They’re working on a new render system that will make it go even faster.
React Native is just a fancy web browser wrapping with some helper APIs.
React native is not a browser. It uses native components.
RN is native too I think, at least it advertises itself as a way to compile some kind of XML syntax into native widgets on either platform. An improvement to PWAs even if I despise typescript
yeah, it displays native widgets but there is still a js engine (browser) running in the background. So the basically made a layer between native components and Javascript. But the code which is running is js and js is slow.
JS by itself is very fast (it’s one of the fastest dynamic languages). It’s interop with platforms APIs that is slow, at the fact that each React app spins up its own instance of Chromium also doesn’t help.
yeah the JS/TS was always a killer for me ngl
I guess smaller apps would be nice but that’s also a thing that can be helped - I have a handful of flutter apps on my phone right now (that i know of) and they run in at:
18MB - Nextcloud recipes client
50MB - Spotube (Youtube music client with spotify integration)
100MB - My job - a savings and investments app, with half a dozen third party API integrations.
So depending on your scope and stuff you can really build an app to whatever size. Cant account for react native or blazor but the idea is usually just abstract native graphics APIs instead of using a browser runtime.