That's a great writeup. However, am I correct in understanding that the UI packages are not bindings for SwiftUI or UIKit? Would this "native" package then truly benefit from OS integration of keyboard shortcuts, accessibility settings etc.?
The biggest downside of Electron (or Cordova/Capacitor for mobile apps) is not necessarily performance (as proven by VSCode), but the non-standard implementation of UI controls.
For example, if I change some accessibility settings on the OS level, all UI elements in all apps implementing truly native UI components would inherit the OS-level settings. The toggle button on iOS could be set to have an I and an O for the ON and OFF state. A web-based app would not respect that setting.
So, if we talk about native, the most important part is OS-level integration of the UI. I'm not sure if Flutter really is an alternative, if the only thing you get is a bit less memory consumption and a smaller download size.
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 your 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.
No, you are right. Flutter isn't really native since it uses Skia to render native platform look-alike components (as opposed to react-native which really use the platform)
As I’d guess most people spend most of their time in Chromium browsers and electron apps probably a case to make that ‘native’ in the sense you imply is Chromium!
> For example, if I change some accessibility settings on the OS level, all UI elements in all apps implementing truly native UI components would inherit the OS-level settings. The toggle button on iOS could be set to have an I and an O for the ON and OFF state. A web-based app would not respect that setting.
There's no reason (in theory) that electron shouldn't support something like that, and it could (and should) be fixed at the electron layer, which would be ideal!
The biggest downside of Electron (or Cordova/Capacitor for mobile apps) is not necessarily performance (as proven by VSCode), but the non-standard implementation of UI controls.
For example, if I change some accessibility settings on the OS level, all UI elements in all apps implementing truly native UI components would inherit the OS-level settings. The toggle button on iOS could be set to have an I and an O for the ON and OFF state. A web-based app would not respect that setting.
So, if we talk about native, the most important part is OS-level integration of the UI. I'm not sure if Flutter really is an alternative, if the only thing you get is a bit less memory consumption and a smaller download size.
Please correct me if I'm wrong.