Our great sponsors
-
-
flutter_platform_widgets
Target the specific design of Material for Android and Cupertino for iOS widgets through a common set of Platform aware widgets
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
Windows UI Library
Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
Flutter has massive battery drain issues on macOS and Google appears to be saying that it's unfixable. That kills it for me unfortunately.
https://github.com/flutter/flutter/issues/59327
https://github.com/flutter/flutter/issues/59327#issuecomment...
OP here!
It wasn't that hard to handle the conditional logic for the UI components. It can also be encapsulated in a separate package, something that is already available for Flutter on mobile (iOS and Android UI): https://github.com/stryder-dev/flutter_platform_widgets
I could also not strive to make it look native, but go with the default UI (Google's Material UI). As I explained in the post, I decided to take some extra steps and use the two UI packages (macos_ui and fluent_ui), to make it adapt to the platform.
Please bear in mind that I am a single developer, with ~1 year of working with Flutter and Dart, and my main background is web development. I think that teams with more members and experience can certainly do this for even larger in scope apps.
Flutter is much closer to a "game engine" as it draws it's components using Skia [1] compared to e.g. React Native that creates platform native elements. So you are right, you won't get the underlying platform's widgets. Flutter should act as an intermediary and make this as frictionless as possible though so OS level changes will be propagated or exposed by Flutter or you app directly accesses them but I have no practical experiance in this.
This is not always so cut and dry awful as you might think though. The platform native widgets also have limitations and expectations that might not fit your vision of the app so even fully "native" apps might re-invent the wheel in a couple of places to make things work as they want. Also I've hardly ever come accross an application that works by just combining the basic platform widgets and not look and feel pretty basic.
Also cross platform apps not respecting e.g. Zoom, Resolution, Orientation, A11y, etc. is more often than not, just the developer's not implementing the required things. The framework might support all of these use-cases but not fully automatic in some cases.
React Native Web exists [0]. But I agree, having parts be third party doesn't mesh well with being a complete framework for building apps (on whatever platform you need).
I've seen the same posts you have linked and can only conclude that they've currently been using either React Native for Web or are using a React website in an Electron app, and are planning on releasing a RNW app. The current app could perhaps be using RNW but targeting win32.
But note that someone from Microsoft linked that tweet in response to a question of who uses RNW: https://github.com/microsoft/microsoft-ui-xaml/issues/6050#i...