|
As a native mobile developer of several years, I've always been somewhat skeptical of the various cross-platform solutions that have emerged over the years. The WebView-based solutions weren't fast enough and sometimes behaved differently across devices because of different WebView versions. With React Native, the impression was far better because the performance actually can be quite good. But it's still hard to abstract the UI layer away when even the native Views on Android behave differently across devices and Android versions. I had to use almost a half of a day for fixing invisible drop-down menu items on some specific Samsung device on Android 4.1.2. Not to mention when you have to abstract the UI for both Android & iOS, which brings its own set of problems. It's one of the reasons why such a fundamental thing as navigation has been so hard to get right. I feel Flutter is the first cross-platform SDK that gets something fundamentally right. Since every pixel on the UI is rendered by the framework, we as developers have better control of everything. It's going to have much better performance because there are no bridges between native and cross-platform land. Additionally, Samsung can't fuck up our UIs: once the UI works, it works the same on every device. As a bonus, they also keep tremendous care of their codebase and they have the best documentation I've ever seen. My really simple, quick 4-line fix didn't go through until I wrote 30 lines of automated tests to go with it. After all, Flutter is going to be the native SDK for developing apps for Fuchsia, and I think Google has learned not to repeat the same mistakes that happened with Android again. |
This is a deal breaker for me. It's not about the ui feeling a bit off - the drawer going over instead of pushing things or some such, it's about losing the integration with the native OS.
For example the android version of the gallery app shown elsewhere doesn't adjust to font size changes (which can be done at the system level), won't make a sound when clicking things if sound on tap is set, has no accessibility support.
Rather then marking the entire word double tapping on a word in an input-text does nothing, long pressing on the input opens a non-native menu with cut/paste/copy while a regular input has share and translate (at least for me).
And this is just a minute of tests, it probably fails to integrate into the larger ecosystem in a gazillion ways - many of them you'll find out when users complain about it once you go into production.
This was tried before (for instance Java's swing vs SWT) it almost always results in eventually outdated slow interfaces that are a pain to migrate to newer technologies.