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).
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).