Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y.
For example, in macOS Cocoa, textboxes have universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful.
Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings.
Another example of this directly benefiting users is the addition of tabs in macOS Sierra.
macOS Sierra added tabs to Cocoa apps, and applications could get the feature without additional modification. I can use tabs in any application, with the same look-and-feel, in all apps.
Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!)
Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
Nah, it ain't. At all! I used to believe it did. That's what we geeks think. And on mobile it doesn't matters for us either - keybings working consistently doesn't matter you're only using touch...
Same thing with React Native, everyone thought it's awesome because native UI controls. But users never care about that. For touch UIs it's more user friendly to have you app be friendly by being unique. The thing that "users prefer native" was just because users like fast and responsive UIs, if Flutter can provide fast and responsive UIs, nobody cares if it isn't native.
Even on desktop, the best UIs I've ever seen (take the new Blender's 2.8 widely appreciated UI) just use OpenGL and draw their own widgets.
People say they care about "coherence" or "consistency" when they are too clueless to figure out what's actually broken about their UIs, so they assume this is the issue. An awesome UX/I is one that would keep being awesome even if each and every button would have a different and inconsistent style, what matters is higher level. Let us stop bitching about things being incoherent or inconsistent when the actual issue is the lack of ability to figure out what is so wrong with a UI that it hinders users!
(Oh, and everyone will always want custom branding and styles, whether we like it or not... We need technology that can embrace uniqueness and incoherence and inconsistency and make it work properly and shippable in time!)
I see developers push for non-native UI all the time because they think their users are too stupid to tell the difference. They're not.
All of my experience as a user and developer points me the other way, so I'll need some proof to be convinced.
Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
From a few years ago, Twitter and Facebook were famous examples. They pushed so hard to try and build their apps using web technology but kept running into performance issues (thanks to infinite scrolling). After spending fuck knows how much they finally admitted that maybe native components are better.
But this is Facebook, who have so much resources they can afford to build their own version of PHP three times over. I just don't understand why they put so much effort into trying to fit a square peg into a round hole instead of just going with native development.
But, I'm not an insider, I don't know the thought processes behind it. Long story short, IMO people overestimate how complex it is to build multiple native apps in parallel.
- implementation of the platform specific layer, supporting all the quirks of the target platform
- testing setup
- build system (some platforms have a lot of weird details to take in account)
The cost-benefit can be ok or terrible depending on the project. But for example for games, where you will draw your own UI anyway, that’s very common, and as far as I know that’s also what Microsoft is doing for their Office applications: common core in C++, then platform specific C#/Java/Objectice-C UIs.
A solution used by plenty of commercial desktop software as we moved from Assembly as main application language for desktop apps during the 16 bit days.
Yeah, that's true. I'm looking forwards to React Native (AFAIK it uses the native JS engine + native toolkits) and libui.
I'm also hoping for declarative UI frameworks like SwiftUI so that the underlying framework/runtime can generate the appropriate UI for the exact target platform.
I'm working with C++/Qt/QML/Javascript. No need to maintain 5 codebases.
Just a single codebase compiles to at least 9 platforms: Linux, Windows, macOS, iOS, Android, *BSD, Raspberry, QNX and WebAssembly.
So probably React Native's approach (the approach itself, not React Native) is a really good idea, where you can:
1. Sharing code if you don't like re-writing n times. 2. Not sharing code if you want to have different native stuff for different platforms. 3. Mix 1 and 2 at any percentage as you wish. Typically reuse all the business logic, and separate view components.
It helps when sometimes there isn't any options to start with.
I use Slack as job requirement, outside work I keep my PC Electron free.
Same applies to VSCode, only because of TypeScript and Rust, otherwise it wouldn't be on my computer.
It wasn't always this way. Before Win8, most apps used native controls on Windows.
When it became apparent GPU rendering is the way forward, MS re-implemented them in WPF. It does draw everything from scratch, because the backend is now DirectX 9. But it was a first party reimplementation, the UX is good.
Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. Now windows phones are shut down, but UX on PCs still suffers the consequences. The new GUI framework is better then ever, but there's no consistent UX on top.
Yeah, it's true but the problem is that the native controls were very limited. There was no central notification system so every Windows messaging app reinvented notifications(unlike macOS which converged to Growl and later, the Notification Center), no standard Ribbon Menu widget (at least when it was first introduced, I'm not sure about the current status) so everyone reinvented it, e.g.
> Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX.
This is so true... Windows 8/10 has a such mixed up UX that some system components are using the new 'metro' style while some others are old Win32 ones that don't support HiDPI... And, (while currently not true) Windows 10 had two settings app that worked differently for a few years. :-(
> Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!)
and on next line you say
> Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
The first thing you said is the reason why we need something like Flutter. There might be a standard way of doing things on Mac but on Windows and Linux there isn't. Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base. That isn't bad thing.
well, no, it just adds another standard. QtQuick already allows the exact same thing that Flutter (one UI, shared across all platforms both in terms of code and looks). (QtWidgets instead is more geared towards applications that fit in the host platform's guidelines).
Quote from CTO Connected Company at BMW
“By combining Dart and Flutter we have the first true cross-platform mobile toolkit; we feel it is a game changer to ensure feature parity for digital touchpoints and IoT. By moving forward with world class tooling, automation and modern functional programming patterns we can improve feature cycle time, security, and cost of delivery of features for the business.”
https://www.youtube.com/watch?v=80pRyn7fZRk&feature=youtu.be...
Also on Desktop, macOS is the only one that even has a single official "native" toolkit.
I used to write for WINAPI/GDI and I used to loathe it; I mostly disliked the way messages were handled by default: huge switch statements. After switching to Linux and checking out the many "toolkits" I find myself craving for some GDI-esque toolkit. GDI was bad, outdated when I started writing it (circa 2009) but things "just worked", looks were consistent and controls would do the same across applications. The GNU/Linux counterpart is a mess: drag & drop sometimes works across toolkits, sometimes it does not; some toolkits are unwillingly to standarize with each other; the looks are all different, the functionalities too. Need an IME? Well here's one for KDE and another one for GTK. And if you use a different toolkit, chances are there's no IME for you. Right clicking on text-boxes and getting the same default options is great, so is being able to extend the same text-boxes systemwide. This is simple on Windows, but GNU/Linux requires one implementation per widget type per toolkit. It's all fragmented and no one cares. I miss GDI, I crave for a simple standard X11-wide widget system. Users do care about widgets working the same on different applications and they don't care about which toolkit is being used, specially non-tech savvy people. I believe those issues are more linked to the meme of "year of the desktop Linux" never arriving than anything else, really: UX should be consistent.
Well now I'll end my rant.
If you’re talking about macOS, then I agree with you, that’s something I cared about when I was using Apple’s OS. Recently I moved to Windows for my personal machine, on this system you really don’t have coherence between applications, even between things developed by the same company or for applications tightly coupled with the OS! It’s just a big mess where each interface has its own set of rules incompatible with others. I would understand if people more familiar with Windows don’t care at all about the overall coherence given how random things seems to be.
Unfortunately the web stack is very bloated with years of legacy and this requires these shell projects to embed a full browser engine making these apps bloated as well.
Flutter is an approach at making a new shell that provides rendering and host OS interaction without all the web bloat.
Yes.
The problem with that is that it requiere experience * each toolkit and that is pain-full for many.
This cause a FORCED split (when multi-platform):
- You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options
- You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????)
----
This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts.
And it not need to be this way.
I think today we already have a good idea in how truly a good toolkit must be done: https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh...
- A lot can be actually cross-platform: Layouts, Units, colors, fonts calculation...
- Widget definition with a DSL (like SwiftUI) This allow:
- Real-time drawing of widgets AND easy drag-drop UI creation like Delphi or HyperCard (this is where HTML beat almost everything)
The above are candidates for cross-ui then you need:
- Rendered by each toolkit. With native controls
- Some way to communicate the backend to this front-end
I think this is alike a game engine:
1- You define the UI:
<Window title="hello"><UIButton if="iOS"> <Button if="the others">
UI derived from BaseUI..
//customize it for my project or create a new platform
UI.register(UIButton...
UI.register(UIWindow for "Window"
//Attach listeners..
UI.listen(...)
//Run the UI
UI.run(the UI directory)
---
To be clear:
This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc.
The space of multi-platform mobile apps toolkit is already occupied by several well established players (React Native, Qt, Xamarin and a dozen of other more or less popular tools, sometimes well entrenched in their niches, like Unity for games).
Flutter comes with rather obscure language and is late in the game, so it will have to provide something truly game-changing to succeed and I am not sure if that what it offers now is sufficiently appealing.
Popularity of Flutter increases steadily: https://trends.google.pl/trends/explore?cat=31&date=today%20...
Yet Flutter fills an important gap in the market: pure native experiences are slowly dying because native look and feel is increasingly meaningless now that so many apps use non native UI kits. Also, supporting multiple UI teams developing for different platforms is a huge risk for small companies and a lot of hassle even for those teams that can afford it. We need more cross platform stuff but I don't believe Flutter is the solution here because of its architecture, which is a combination of "our way or the highway" and vendor lock in. I'd say there is a big risk of Apple doing something smart with Swift on Android and web. I actually know of a few Android developers using Swift on Android already. This is becoming a thing. Like Kotlin, Swift is perfectly positioned to start targeting cross platform via LLVM. Also WASM is becoming a thing. IMHO, Google needs to make U turn here and rip out whatever it is that prevents Flutter from being driven from Kotlin (jvm and native) and other llvm languages.
All that's missing is a proper cross platform UI toolkit that actually works properly in that ecosystem. Things like QT and GTK are obviously usable in that space but a bit clunky/ugly on mobile.
Popularity does not translate in money nor projects, specially with a niche language designed for doing UIs only, lacking libraries left and right.
I reviewed Flutter but got put off by the levels of abstraction.
React Native just keeps breaking things, like for example at something like 0.56 the textinput just broke on Android beyond usable and was stuck at that for like half a year.
I don't particularly like Dart as a language but as an SDK Flutter just feels a lot more solid than RN.
It's different in a few key ways:
- Draws native components (Flutter draws every pixel)
- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`)
- Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned)
- Ability to use both Angular and Vue to structure your app (there's also projects out there like Svelte-Native, which is extremely promising from the performance perspective)
- More community driven project (with Progress standing behind, following the open-source & extra features business model)
I've used Nativescript on client projects, and it is fantastic for prototyping, with well demarcated paths to performance optimization. Since you can easily use native screens/controllers/etc with it, at the very least you can use it for fast prototyping then drop all your custom code in.
Do you know of any hybrid frameworks that are not running JS code on the main thread by default? And by JS code I assume you mean display-related code, because Flutter suffers from this same issue, do too much hard work on the main thread and it stalls (as anything would). Even on android itself[1] you need to do some extra work to make sure your UI-related heavy lifting happens off the main thread:
> However, when the main thread’s messaging queue contains tasks that are either too numerous or too long for the main thread to complete the update fast enough, the app should move this work to a worker thread
[0]: https://docs.nativescript.org/core-concepts/multithreading-m...
[1]: https://developer.android.com/topic/performance/threads
Of course you do need to make sure that everything that could be even slightly expensive is shipped out to a background thread. JS is weak in that respect.
Moving everything to a background thread does fix that problem, but I think it’s overkill. A lot of mobile apps would be faster and more responsive if they used the main thread more. You just have to use it right.
Here's a talk from 2 years ago:
https://www.youtube.com/watch?v=ELemwZXJZVg
I personally prefer Nativescript-Vue and I find their docs to be very good:
https://nativescript-vue.org/en/docs/introduction
Some more video resources:
https://www.youtube.com/watch?v=DcCSq2Y9bow
https://www.youtube.com/watch?v=qR1ESQTALI0
I personally think the best way to learn it is to get your hands dirty and use it to build something, so I'd recommend that, but there are certainly resources out there as well.
Happy to help if you are stuck on any issue with Flutter. Our background is native application development, so far this is the best Cross-Platform Development toolkit available.
Phonegap, Ionic & others are web wrappers. PLEASE let Flutter grow!
Although React Native shows Native elements, they vary slightly across different; devices, platforms, OS's etc.. this can create many weird edge cases, which makes it unreliable in some cases.
Just tried Flutter and React-Native yesterday for the first time, and I'm sorry to say both were sorely disappointing.
Flutter was easier to install and get working, but Dart seems to be as verbose as Java with some JavaScript style syntax mixed in. The main dart file was as verbose as a boilerplate native SDK Activity.
RN was worse, though I expected it to be simpler. Something called metro server nearly froze the entire machine on every attempt. Had to power off and restart about 5 times. Then, based on GitHub discussions, built something else called watchman from sources. The official docs don't mention that watchman is critical. That improved it for a while but then the system wide near-freeze came back again. I wasn't even able to display a simple hello world app because of installation and deployment problems.
So far, Kivy seems to be the only alternative that is both simple to code and to deploy. Its file sizes are massive, but given that I already find Android SDK so frustrating to design and implement quickly, I don't want alternatives that are equally frustrating.
In the beginning of a devs experience framework code appears to eclipse app code in size and complexity, but over time the app will tend to grow to overwhelm the framework.
All of the with the bonus that C#, JavaScript and C++ actually have lots of market demand, Dart remains a possible CoffeScript.
For me having to deal with Dart, a programming language without any other purpose than Flutter, it rules out any advantage over Xamarin.
With Xamarin I have C# and the whole .NET ecosystem available.
Qt is pretty good, and QML has decent animation support but I think their mobile implementation is still very alpha, and since being acquired (again) they've kind of refocused on embedded devices like cars where they actually make money. Also it's not free. And QML is a bit less elegant than Flutter. It practically forces you to write spaghetti code.
I don't know how you'd use "C++ with native views" on Android, and I've only heard bad things about Xamarin Native.
You use a JNI generator and follow the so called hamburger architecture.
Microsoft and Dropbox have several sessions done at CppCon.
While the author's confusion is understandable, because most of the people posting in the linked Github issue have the same confusion, it's always been possible to build a 64-bit APK (and a 32-bit APK). The linked issue is actually about building a single "fat" APK with both 32-bit and 64-bit native libraries in it, which Google Play Store then repackages to have just the needed library for the device it's being downloaded to.
Shipping two separate APKs has always been possible and gives the same end result for just a little more build process work, which is (/should be) automated anyway.
I've been shipping an app like this for some time now, and it's really not a hardship in any way, certainly not one that justifies the amount of hand-wringing in that Github issue.
It must have been either low priority (except the Play Store has been strongly encouraging fat binaries for some time now) or there were additional complications (which makes me more suspicious about the stability of the framework).
As an example I've created an alternative to Nissan's Connect EV app. It's basically a way to control and monitor your electric vehicle from Nissan. The official app is I’m very disappointed by; it’s slow and full of wrong decisions.
My alternative is called "My Leaf" and its available on Google Play and the App Store; https://play.google.com/store/apps/details?id=dk.kjeldsen.ca... https://apps.apple.com/us/app/my-leaf-for-nissan-ev/id143670... It's completely open source.
OP has some valid points for sure, but fact is that any framework is going to have issues. Just part of the game.
It refers to other solutions as well, but the hands-on example is with provider (starting in the "Simple app state management" chapter)
Not using Android Studio, so not sure how easy it is to miss the massive performance difference of optimized vs. debug builds in that workflow.
I really don't understand the complaint about setup. If expanding an archive and setting an environment variable are that daunting, wait til you try mobile development...
Snark aside, remember phonegap/cordova? Pine for those glory days of low friction?
in what ways?
A friend described it to me as "Unity for apps", which I think is pretty positive and accurate.
There's a number of Photoshop alternatives that use native controls that are reasonably popular (they're also generally cheaper, too).
- Overclomplicated syntax. - Material Design doesn't look as good as the native. Feels like imitation in many cases. - no vector drawable, PDF or Lottie support - I had to create special code for iOS to match certain patterns and components. - Typopraphy done wrong.
Flutter maybe something good to start with, but once you want to reach good app design/code maintain that would be painfull and you will feel faster and more organized if you do things in their native realms.
The difficulty for newcomers is anticipating where the pain points might be. Detailed articles like this are rare and a huge help with assisting with decisions on whether to invest time into it.
But, it's not like other companies are much better at this. At React Native they just autoclose them after some time. While Apple most likely has more open issues than Flutter but the data is not public.
Author expects bugs in open source projects to get fixed for free, by someone else.
We need to support open source maintainers instead of shaming them. I'm excited about Open Collective and made a monthly donation to a project I use.
There are quite a few things missing, and I personally found it quite hard to get going (but that might just be a general lack of skill at getting tooling set up), but there's an awful lot to like if you want to dive into getting something set up on-device quickly.
However I would say where it excels at is in creating a fully custom-branded experience rather than sticking to the native elements. I reckon https://reflectly.app/ is the poster child for this.
All it does is let you write iOS UI code in Java or Kotlin, and target both iOS and Android from a single project.
It uses the actual underlying iOS API, and simply provides Java wrappers for them, that map one-to-one.
I keep wondering, and don't know why it hasn't gained much traction. It is so much better than Flutter, is obviously reliable since it's a simple 1-1 mapping/translation layer. (There is more work involved with it, as you have to write the UI lawyer twice, but that's about it.)
My biggest issue is that there is still this "uncanny valley" feeling when using a flutter app. It feels much better than a react native or Cordova app, but something still feels off.
Right now it seems great for prototyping. For iOS however, I've been playing around a bit with SwiftUI which currently (even in its beta state) provides an astronomically better dev experience and user experience.
i know they were considered experimental a few years ago but wonder what’s the status today.
Also it seems like he is complaining that the Flutter team actually uses a public bug tracker. Does he really prefer Android's bug tracker? The place where bug reports go to die. A year or so ago they gave up on it and basically closed every bug as obsolete.