Cross-platform frameworks that don’t use native controls have suffered from problems... - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) - they don’t get updates to native c…
I share your concern regarding text fields. That's the one area where I never want to mess with native behavior. The search results for "flutter ios text field copy paste" aren't encouraging.
> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
To be fair, just because bigs use their own frameworks doesn't mean they produce great UX. There's an added learning curve to any non-native app that users incur when this happens - things are out of place, don't work as expected, features don't exist, etc. For example: - Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable)…
It depends on what you mean by best.
For us, we want to use the web stack so our stuff works across all platforms. So we use Cordova. We realize that over 90% of users just want to use the main interface and not some fancy OS feature. All our effort goes into making the product rock solid stable, engaging and easy to use. We aren’t actually interested in making it feel exactly like a native iOS or Android app.
> as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not. On iOS, the extent of "branding themes" end up is often limited. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? There is no Chrome on iOS. So Flutter is different from everything else out there. >…
Chrome on iOS exists. I think you meant to say it uses WebKit (and native font rendering) instead of Blink.
A Java fork failing to keep up with standard Java, winning on where Microsoft failed (aka Google J++), thus forcing Java library authors to either write two versions or constrain themselves to the common subset. Meanwhile, there are plenty of other Java vendors that are able to create their own Java implementations and play ball with the rest of the eco-system.
Maybe that's not that bad, considering the fraction of Java libraries that used simultaneously in Android and Java ecosystems isn't very large. OTOH if Fuchsia wins, we loose the open source mobile OS, the major one, the only one, with tons of apps and ways to ungoogle.
On the other hand, we'll finally have an empirical resolution to the Tanenbaum-Torvalds debate!
To be fair, just because bigs use their own frameworks doesn't mean they produce great UX. There's an added learning curve to any non-native app that users incur when this happens - things are out of place, don't work as expected, features don't exist, etc. For example: - Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable)…
It depends on what you mean by best. For us, we want to use the web stack so our stuff works across all platforms. So we use Cordova. We realize that over 90% of users just want to use the main interface and not some fancy OS feature. All our effort goes into making the product rock solid stable, engaging and easy to use. We aren’t actually interested in making it feel exactly like a native iOS or Android app.
Well, such things are causing subtle annoyance for users. This works as long as the value you provide is good, but the more and app is just a bad we view the more likely it becomes that people uninstall it or look for alternatives. Unsurprising consistent behavior is a value.
Cross-platform frameworks that don’t use native controls have suffered from problems... - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) - they don’t get updates to native c…
> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
Agreed - I never could quite understand that argument and what is so intuitive and familiar with native UI controls when looking from perspective of a new app to the user. Depending on the app functionality, achieving good UX could be very hard and sub-optimal using only native controls, and impact of a well-thougth-out flow through the app, specialized controls where helpful and polished design should not be underestimated...I'd say that, if someone puts enough attention into it, custom design / controls are probably mostly superior to the native UI, in terms of UX. Not to mention how often people want something different and fancy over "boring" bland look of native controls...Granted, there are a lot of small usability aspects and behaviors to consider, as pointed out by others.
Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make." The comment from pzo points out an even worst of an adoption showstopper.
Here's some of the explanation about why they chose Dart: > There’s a lot of nice properties of Dart, we talk some about this on our website at our frequently asked questions. One of the nice properties of Dart is that it has a really fast garbage collector, one of the choices that we made in Flutter was to have this reactive style system where it’s very common to allocate thousands of objects in a – if not, tens of…
This actually makes it sound like native OCaml (maybe with the ReasonML syntax) would have been a good fit for Flutter. OCaml has a super-fast compiler, super-fast GC, and has (pardon the pun) reasonably good native interop.
Try to download it from qt.io. You will have to go through several screens saying "Are you sure you are able to comply with the LGPL? Wouldn't you rather get the commercial version for peace of mind?". If that isn't an implied threat, i don't know what is.
Does anyone have a feel for how good flutter's documentation for canonical approaches to common use cases are now? The last time I tried it, even a simple task like changing the UI when returning from a login screen was unknown territory for many developers. The examples in the documentation were all for single screen simple apps. Has this changed? Or is the community still trying to figure out best practices?