I've recently done a bit of Flutter development and have enjoyed it quite a bit. The third party Provider API solves all the state management issues, it should become the default.
OP has some valid points for sure, but fact is that any framework is going to have issues. Just part of the game.
That sounds interesting. What would be the go to documentation for a good Provider API implementation (i.e. like a best practice guide with an example)?
Flutter is young, and there are bugs, but velocity is high and it is advancing the state of the art. It is a huge leap in accessibility and productivity.
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?
‘Mobile phone minutes’ were a common medium of exchange in parts of Africa (Kenya?) for a while (and maybe still is?)... mobility is also another commonly desirable service, so sure, why not?
Yup, it still is. Lots of that in eastern parts of Africa like Kenya, Rwanda, Uganda. I'm sure cell service providers are pretty happy with it since it turned them into banks.
> it took them almost a year to add support for 64 bit in APK
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.
What was the holdup, though? This should have been almost a trivial feature to implement (just make an APK with multiple .so files in separate directories).
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).
Maybe low priority / insufficient resources, or the issue didn't get triaged and brought to the attention of the right person to fix it quickly enough. The fix wasn't complicated at all once it was eventually in, so I don't think it was any deep issue with the framework.
I like Flutter very much. In some aspects it is much better than native iOS development. But it's far from perfect, so perhaps this post will prompt Google to hire more people to handle issues.
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.
I am working on 3 Flutter Applications & 2 of them are currently in production. On average we receive 1 major bottleneck a month, which gets resolved with 3rd Party fixes.
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!
React Native isn't a web wrapper. It uses a Javascript engine to render native iOS/Android components (unlike Flutter, which doesn't use native components, and instead renders everything from scratch).
I think this is mostly just a preference thing and may have to do whether you're coming from a React vs Native Mobile background. As a React developer, React Native was really amazing for me and made perfect sense. Flutter on the other hand, not so much.
Comparing languages is very different to compare these two SDKs. I've developed apps on both, and personally I've found Flutter significantly more solid and overall just better.
Everything is faster and just works (builds, hot reload etc.) on Flutter whereas on RN a lot of the things break constantly for no apparent reason. And all that weirdness like it might work if you rebuild a few more times in a row. Moreover, a lot of the debugging tools work exceedingly well on Flutter while trying to use even just the memory profiler crashes RN.
Because Flutter has it's own rendering engine, it's inherently more consistent in refresh rates and UI components.
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.
I'm actually investigating getting some skills on react native, but i've got the suspicion it isn't all sunshine and rainbows. From what i've seen so far, a real-world stack has many more dependencies other that react native itself, and becomes a convoluted mess.
However, i'm surprised that i haven't found a similar post to OP detailing real-world React Native pain points.
RN pain points are upgrading more than anything else. Also as a native dev I don’t understand why the JS dev ecosystem is full of disjointed tooling instead of just making the process more streamlined.
I have also developed a production flutter app for a client and am now working on a RN app for another. I like RN so much more just because I can create custom native views that use the platform toolkits. You can also share a lot of code with an SPA web app and set up a monorepo for everything pretty easily.
Flutter dev tools are incredible though and much easier to use than react native.
Snapchat like UI is definitely possible, but for the performance to be really good youd probably want to do something native. I consider that a good thing though. RN is better if you just treat it as the coordinator on top of native view components IMO.
Not as simple as that. Some people clearly manage to create things effectively with it. Newcomers can see this but understand that there will be difficulties.
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.
yeah no. i would not bet the farm on this one especially when it comes to developing for Apple devices. Google just doesn’t have the track record to inspire confidence that anything they do is going to stick around
Does anyone has a link for the market shares of cross-platform mobile development tech ( react native, phonegap, flutter, etc) vs native ? in terms of apps on the stores, for example.
i know they were considered experimental a few years ago but wonder what’s the status today.
While this has little relationship to the original article...
We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch.
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.
> Windows apps usually just re-invent all kinds of UI elements
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.
> Before Win8, most apps used native controls on Windows.
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. :-(
> There was no central notification system… no standard Ribbon Menu widget
True, but if MS wanted to, they could have added both to the old ecosystem, without jumping ship.
They had mayor parts of notification system already, Shell_NotifyIcon API from Shell32.dll. They were adding more features to NOTIFYICONDATA structure with every OS version.
I don’t work for MS but I think the reason why they did not, it was hard to do, not because they didn’t want to share.
That’s quite complex UI and UX in that control. Very likely, the office implementation is coupled too tight with the rest of the office code, i.e. very hard to refactor into a reusable control. The office is cross-platform, their implementation of ribbon has to be designed to work on OSX too, contributing to the complexity.
Given just what was visible to Office Extension Developers ("RIBBON XML", the giant pile of C++ MACROS, etc), the original Office Ribbon control was probably quite a complex beast.
On the other side: the new "Simplified Ribbon Control" that is in now in OneNote (the real one, not 2016) and Outlook (and eventually the rest of Office) is supposed to be the exact same code as the UWP/Fluent Ribbon that is eventually going to be open sourced into the WinUI library.
> Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
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 worked on Xamarin app and saw how things worked there. I also think that it's a logical conclusion from these conditions:
1. You want to support N native platforms.
2. Each of these platforms has it's own way of doing this, bugs, etc.
3. Each of these platforms is being actively developed.
4. There are differences between those platforms. One doesn't have guassian blur, the other one doesn't have right-to-left languages.
It’s great that there are a lot of cross platform solutions today. On the other hand it’s also the reason why we put up with shit apps like Slack’s desktop and mobile clients.
As a macOS and iOS user I’m sad because both platforms have a far superior native UI, but at the same time as a developer I’m glad I can quickly build things for multiple platforms because there is no way my customers would pay for separate native implementations.
Only when one doesn't use a solution like having the common logic in a portable language like C++, with bindings to native UI elements.
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.
Agreed. Mixing business logic and UI works in simple applications, prototypes, or applications intended to ever work with one platform and UI paradigm. Outside of that, you're supposed to keep your "business logic" and UI separate (isn't this exactly why people invented MVC?).
Maintaining "5 different native UI applications" should involve one codebase with the whole internal logic, and 5 separate UI layers mediating between that logic and the platform it's being run on (including UI). It should not involve rewriting the same thing 5 times.
Often you can offload the business logic to the backend. That way you don’t have to implement it multiple times for each platform and you can change it “immediately” even if users don’t update their apps.
In such cases that same backend can send an XML (or JSON if you will) DSL payload that generates such UIs on the fly using the native widgets.
Pretty easy to create such framework in something like C++ or having a scripting language that drives the native UI widgets, something like JavaScript.
UI these days is often more complex than the underlying logic itself. App logic became, to me, even secondary. Most of those issues are solved problems (databases, sql, rest, xml, json) and are mindnumbingly stupid and boring to implement. Save data record.. query data record.. validate data record, yeah, yeah, really complex.
Qt is a really good solution, but I personally always failed to build something that works with it. I find their documentation and tools really difficult to grasp.
IMO it really depends. There's a lot of big companies that have more than enough resources to be able to pay multiple dev teams to build and maintain apps across operating systems.
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.
people overestimate how complex it is to build multiple native apps in parallel.
I agree, although there are now more platforms to deal with than back in the days when it was just Mac and Windows: add iOS, Android, desktop web, mobile web.
I think it also helps when it's easy to share code between platforms, which again, used to be easier when you were just targeting the desktop (just use C or C++).
Now it's a bit harder because there are no great languages that span all platforms easily without a bit of hacking. Most languages are managed and memory-safe now; that's a good thing, but it makes them more heavyweight and less portable. They generally want to drag in their own frameworks (e.g. Flutter, React Native) rather than letting you put your own UI layer on top.
I remember the days of Apple II, TSR-80, Commodore 64, Commodore 128, ZX Spectrum, ZX Spectrum 128K, ZX Spectrum 128K +2A, ZX Spectrum 128K +3A, Atari, Atari ST, Amiga 500, Amiga 600, Amiga 1200, PC CGA, PC EGA, PC VGA, PC PS2,.....
You’re right, of course! It’s amazing to think how many 8-bit and 16-bit games got ported to a whole bunch of different computers.
I was thinking mainly of the 90s and early 2000s, I guess, and for desktop apps where the main platform of interest was Windows, followed by a long tail of Mac, X-Windows, BeOS, etc... All those platforms could “easily” (i.e. with effort, but no rocket science required) be handled by a single C/C++ codebase with platform-specific #ifdefs.
I think the equivalent for today’s platforms would have to be Javascript. Unlike the C/C++ approach, you lose direct access to platform features.
> 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.
I think in the case of something like Facebook, the sheer complexity of their product drives a need for a singular code base. It would slow their engineering organization to a halt to ensure feature parity with largely seperate code bases.
This is only true if you're working with multiple completely separate teams each working in a silo to develop their own product and then post hoc some manager decides they have to have the same feature set. If they do it the right way around, specifying the common feature set comes first and then the dev teams do the app architecture on their separate platforms. As the features are developed and change requests inevitably arrive, the same sequence applies and you have an orderly process and the same app on two or more platforms without having to graft a third party dependency octopus onto your codebase.
I assume you also do custom code for each platform inside Flutter as we do to respect iOS and Android guidelines. Some things are different and need separate code. This is a pain too. I had much better experience coding only for the platform than using Flutter.
> draws everything from scratch is a bad idea.
> re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
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 depends what you mean by “re-writing the same app”. In general you can have the core features written in C++, thus available everywhere, then write a platform specific layer on top of this. That’s a quite common approach, and if done correctly (that’s not a trivial task though) allow you to target any platform without too much effort. But yes, you still have to maintain a bunch of stuff for each platform:
- 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.
The expectation level for UIs on mobile devices has been set very high. There is a lot of detail to get right in order to deliver the experience that people expect. That UI specific work is very time consuming.
It doesn't really matter what else is going on in your app, if that work can be done more efficiently to produce a more consistent result, then that's the decision you make.
> work can be done more efficiently to produce a more consistent result
Often with frameworks like React Native or Flutter, it means inconsistent UX bugs on each platform. Why do you think Facebook and Instagram and Airbnb abandoned RN in all their primary interfaces?
The "more efficient" implementation might lead to consistency across platforms, but people are pretty tied to the phones they have. Things like dropped frames, slow scrolling, UI locks, all have a subtle effect on the user whether they can point it out or not, and you're more likely to have those problems by diving in to these frameworks without understanding the underlying platforms.
This isn't argument to share no code whatsoever. But so many people who immediately turn to these frameworks either want to ship something at the expense of UX/design, their app is so small that it doesn't matter, or they have no idea what they're getting into.
Right, but QT apps are QT apps -- they're not really native on any platform which is the same problem you run into with Flutter an Electron.
If you want an app that has platform semantics on every major platform then you need separate code bases. If you want an app that has the same semantics on every platform then you go with a cross-platform toolkit.
So you are arguing that no one "would say re-writing the same app 5 times and maintaining 5 codebases is a bad idea."?
That was my statement. You are saying it's not true. All the upvotes suggest some would say that. Therefore my statement is true.
I'm not sure why you're so confused here. This isn't at all applicable to what you are saying. You are talking about writing an app once and having one code base, which is exactly the opposite of what I was talking about. You have constructed a straw man and called it not true.
I don't understand the goal of 0% platform specific code (on a lower power device where UX is very important) or even further being able to make a whole app without having to learn about the platform, being aware of its conventions and limitations.
I've never finished a React Native app without native code. I've done a few now and I've come to believe it's not worth even trying to avoid it and sometimes worthwhile to look for places where a little native module can yield performance or UI wins. React Native is the glue or orchestration and it is, to me, extremely good glue.
I haven't seen many people beyond the tutorial level suggest otherwise. It provides a common structure (which is enormously useful), and some quick consistency wins for simple stuff like your About Us screen.
I do get that, but one is bad for developers and the other is bad for users. It’s up to you to decide which is more important for your project. Most projects I’ve worked on, the user experience was more important to the business, in which case native apps are better.
Any data backing that up? Don't forget HN users are a bubble. I'm actually pretty sure standard users don't even notice a difference between Electron and native apps. I for one sometimes prefer Electron apps over badly designed and ugly native apps.
UWP is hardly consistent. Just as a quick example, the context menu in the start menu is slightly different from the context menu for the task bar, which are both very different from the context menu(s!) which appear in the Windows Mail app. Or how the context menu in the start menu can exit the bounds of the start menu, but most popups/menus in UWP apps are fully bound to their parents.
The massive success of Electron apps shows that users don't really care about native controls. Even though electron is terrible in resource usage it enables unmatched development speed for teams. If libui or other libraries can give this experience then most teams won't hesitate using it!
Success as in being the UI for a multi billion dollar company like Slack. It's undeniably terrible but what other options do we have? I don't think any tech is gonna withhold against the web!
I'm actually willing to switch to any platform that can offer amazing development experience at the same time being super performant.
Depends a little on what you mean by “native controls”. The web platform doesn’t provide all of the controls the underlying OS provides (e.g. a list view), but it does provide some of the most important and common ones. A text box, for example, has the native look-and-feel by default—and feel is the most important part of that, for things like caret behaviour, keyboard shortcuts and touch behaviour; and you can customise its look easily. It’s not the native implementation, but what the browser implements matches the native implementation.
> 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.
> Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base
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).
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!)
Neither you nor the parent poster substantiate your assertions with sources, which made me curious of what research might have been done in this area. Some cursory searching lead me to this reasonably well sourced answer, which suggests the parent poster is right in this case:
https://ux.stackexchange.com/a/39295
Sorry, but your linked source is off-topic, ancient (2013!), and compares the wrong things (native mobile apps vs. old-generation-hybrid-web-mobile apps).
The relevant comparison here would be between:
- (1) truly native uni-platform mobile apps (native Android and native iOS apps)
- (2) cross-platform mobile apps using native widgets (not sure if there's any alternative to React Native here)
- (3) cross-platform mobile apps that draw their own ui, but NOT using web technologies: Flutter is the only obvious example (there are older things like Kivy which uses Python and OpenGL but I think it was mostly used for games and kids app, not that popular)
Web-techs-based hybrid-mobile apps are a different thing (Cordova, Ionic etc.) and, yes, there everyone agreed they feel inferior to users, just as mobile optimized websites feel inferior.
Unfortunately this is the problem here, it's incredibly easy to compare apples to oranges here, I don't blame, just saying that all sources are misleading, probably it's better to play with few things and see the "gut feeling"... it's pretty obvious that underlying tech and whether the widgets are drawn natively or not is NEVER a differentiator between successful and unsuccessful apps, it's always all the other things :)
> 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.
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.
I've often encountered this sentiment as a rationalization: these developers know their product looks and feels inferior, but they've already invested (their egos) in the "amazing" and "magical" <insert framework/technology/approach here>. Eventually, the consequences of prioritizing their comfort over their customers emerge, and the developers either defend their tools to the death or slink away to the next "slick" solution.
I guess you're right. Users do tell the difference! But they usually tell the difference between laggy (even 100ms IS noticeable!) and janky UI vs. snappy & smooth UI. It's not about the graphic styles and font widths and such. It's about being fast even on overloaded cheap devices in power saving mode, and don't doing anything too weird or non-sensical.
TBH I'm not sure Flutter can be fast and smooth enough for all... the market is full of crappy devices and even the good ones perform badly when their RAM is maxed out and CPU throttled bc of battery saving.
Maybe full native is the way to go. But not because of "perfect" shadows and font widths... Users care about consistency of stile inside one app, not app-style vs. system-style.
In a sense that already happened with the web stack. In tech like Electron developers write most of their app once and use a “shell” like Electron to interact with the host OS.
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.
Ah yes. I should have specified: a high-performance, low resource usage cross-platform UI. Flutter's a nice idea, but I somewhat suspect it will never make it out of its relatively small niche. I have my eye on the Rust UI work. It's a long way out, but it has the potential to be a really solid foundation for a universal UI platform.
Author here. Never expected it to reach here. 24k views and it's been ~14 hours since I wrote it. I agree with you. There is currently a competition between kotlin multiplatform and flutter, a shared backend vs a shared UI. Guess what, exactly what you said, it's a lot easier to share the backend than recreate the full UI like a game does. I'm not against flutter, but it feels too immature for now and the pains really show up. Apple showed up their new UI toolkit for developers, which does animations in the best way possible, Flutter team reaction was "you can make a library to improve it if you want" and "we should improve our docs" but no one will recognize there are issues in the framework that could be improved.
BMW seems happy with flutter and are opensourcing some of their flutter libs.
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.”
It feels like he could have said that about any of the relevant frameworks. They're happy they've started down the cross-platform path using one of the solid available alternatives -- good on them!
> 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.
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.
I agree with this 90%, but I'm not sure about the state of GUI apps after Windows 7. Up to Win7 though, most applications simply used native controls, sometimes wrapped by WPF or WFC.
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.
> We really should be trying to use the native GUI toolkit
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.
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)
When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic.
---
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.
Add to this Accessibility: Standard widgets normally have accessibility features built in, working well and tested to make sure apps work correctly with various assistive technologies like screen readers, zooming, key controls, etc.
I liked the way the UI was built in Flutter and of course Dart > vanilla JS. But with SwiftUI and Jet Pack around the corner there's a bit less appeal, especially since Kotlin & Swift > Dart and a lot of UX niceties come for free in iOS, like rotation / resizing or hiding the keyboard while scrolling.
This seems like a fairly biased post (as he admits himself). Flutter has a lot of problems, but if you've used any other cross-platform system, you know it's a hard problem to solve.
A friend described it to me as "Unity for apps", which I think is pretty positive and accurate.
Author here. Yeah, it was supposed to be "here are my frustrations", not like "Flutter is bad, let's burn it".. but of course, the thing grew up beyond control. 38k view so far.
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.
This sounds like an excellent bug report for their playground feedback[0] repository, I'll make a ticket for you[1], please feel free to go in and fill out more information to help them help you.
Please note that the links in the issue you submitted need to be changed because you copied the link text, which are only partial, rather than copying the link target URLs.
While it's good feedback to the respective project owners to make onboarding easier, it is a mistake to judge tools based on < 1 day of usage (which is almost entirely onboarding angst). You are only experiencing one, relatively infrequent transient story, not the steady-state one.
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 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.)
I tried Flutter a few times to have a play - really like it. Obviously a lot of the packages available hook you into the Google ecosystem (Firebase is ridiculously easy to get working).
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.
The biggest advantage is easy GUI creation, especially with animations and custom styling. Stuff that you can do with Flutter is basically impossible with native Android. You also don't have to deal with the insanity of Activities and Fragments.
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're going to have to provide a link because "hamburger architecture" returns no relevant search results and I still don't know how you mean to make an Android GUI in C++. Unless you mean you write your core logic in C++ and your GUI with Java and link them via JNI?
That still means you have to write the GUI again for every platform, and you still have to use the Android API which is a very awkward system to make GUIs with (animation is extremely difficult, Activity and Fragment lifecycles are very complicated, etc).
Speaking strictly to the Xamarin here... as someone who has worked professionally w/ Xamarin, Xamarin.Forms, and Flutter: Flutter knocks it out of the park. My experience with Xamarin was so buggy as to be nearly unusable (on Stable no less!). The documentation, _especially in Xamarin.Forms_, was sooo lacking! I wanted so hard for it to be "the next great thing", but there were just too many gotchas and pain points. In contrast, Flutter "just works", has great documentation, great community, great tooling. My development in Flutter, especially with the hot reload they support, has sped up immensely. I can pause the debugger, change code on the fly, continue the debugger, no hiccups. It has been nothing short of wonderful. My anecdotal two cents.
- 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.
Are you a native iOS dev? I feel Flutter is a major upgrade over React Native, but perhaps native devs just feel it still falls short on a lot of accounts.
I simply love Flutter for Android and iOS development and have been using it since alpha. I haven't tried the web application part; I'm pretty sure I never will. Here's my opinion. I've created several apps with Flutter and every time I enjoy it. The UI is easy to make beautiful and the resulting code easy to read. It feels like all what the current Android SDK is missing. The current Android SDK is old and quite frankly painfull to work with. You just can't create beautiful apps with ease; it's always a hassle. It's also messy and not easy to read the resulting code. The way the whole way the framework is structured entails ugly code in my opinion. This all becomes evident when you use different apps on Google Play. You get the sense that every app reinvented their UI; there is no real UI continuity. Google became a freeloader after JetBrains created Kotlin and marketed it will. The thing is Kotlin made just a little better; in terms of boilerplate stuff; the framework I still hate compared to Flutter. What I really like about flutter is the framework and “it’s all a widget” idea. You can basically do crazy things in UI with ease and on the other hand just use the standard UI components with a great result.
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.
@tobiaswk - good job with your apps! I completely agree with Android and UI design which is painful. Flutter is far from perfect but a non designer can create something pretty decent. Users appreciate the experience.
Yep, React Native has horrible dev experience... this is what drove me to Flutter. Dart may be ugly but after you get used to it it's mostly "Typescript done right" imo ;)
...ok, tbh TS has a much more powerful and expressive typesystem then Dart, otoh it also works with the constraint of being a superset of JS hence some things are forced to be the way they are since they sit on the foundation they sit.
I don't really like Javascript as a foundation so I'd almost be inclined to throw away a superior type system in order to have the bedrock be something else, opinions might vary though, I know.
And probably we'd all have loved to have Kotlin instead...
> And probably we'd all have loved to have Kotlin instead...
For what it is, I quite like Kotlin (particularly when placed against Java, of course), but I would not want to give up structural typing for much of anything in 2019. It makes writing obviously-correct code significantly easier.
Unfortunately the fact that TS is another layer on the top of JS makes the system more error-prone. This was one of the issues I encountered when fiddling with React Native. Too many moving elements in the stack would lead to frequent configuration problems, or the transpilation breaking debugging in weird ways, etc. And once things finally clicked in place, some component was updated, and the vicious circle would start again.
I've written one app in flutter and the experience was good. It was very easy to get started, and the dev experience was on par with web development with very fast hot reload.
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.
187 comments
[ 3.9 ms ] story [ 246 ms ] threadOP 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)
https://github.com/rrousselGit/provider
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?
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).
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.
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!
Everything is faster and just works (builds, hot reload etc.) on Flutter whereas on RN a lot of the things break constantly for no apparent reason. And all that weirdness like it might work if you rebuild a few more times in a row. Moreover, a lot of the debugging tools work exceedingly well on Flutter while trying to use even just the memory profiler crashes RN.
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.
However, i'm surprised that i haven't found a similar post to OP detailing real-world React Native pain points.
Do you have more info ?
I have also developed a production flutter app for a client and am now working on a RN app for another. I like RN so much more just because I can create custom native views that use the platform toolkits. You can also share a lot of code with an SPA web app and set up a monorepo for everything pretty easily.
Flutter dev tools are incredible though and much easier to use than react native.
Say you’d like to implement a snapchat-like UX with RN, would that be possible without relying heavily on native custom components ?
Snapchat like UI is definitely possible, but for the performance to be really good youd probably want to do something native. I consider that a good thing though. RN is better if you just treat it as the coordinator on top of native view components IMO.
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.
https://news.ycombinator.com/item?id=19853247
i know they were considered experimental a few years ago but wonder what’s the status today.
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.
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. :-(
True, but if MS wanted to, they could have added both to the old ecosystem, without jumping ship.
They had mayor parts of notification system already, Shell_NotifyIcon API from Shell32.dll. They were adding more features to NOTIFYICONDATA structure with every OS version.
They did release ribbon widget; it just took them a few years. Introduced in Office 2007, the widget is from Win7 i.e. 2009: https://docs.microsoft.com/en-us/windows/win32/windowsribbon...
That’s quite complex UI and UX in that control. Very likely, the office implementation is coupled too tight with the rest of the office code, i.e. very hard to refactor into a reusable control. The office is cross-platform, their implementation of ribbon has to be designed to work on OSX too, contributing to the complexity.
On the other side: the new "Simplified Ribbon Control" that is in now in OneNote (the real one, not 2016) and Outlook (and eventually the rest of Office) is supposed to be the exact same code as the UWP/Fluent Ribbon that is eventually going to be open sourced into the WinUI library.
Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
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.
This may seem like a good idea, but it's not. What you will get is a leaky, lowest common denominator API that will break on each new OS version.
1. You want to support N native platforms. 2. Each of these platforms has it's own way of doing this, bugs, etc. 3. Each of these platforms is being actively developed. 4. There are differences between those platforms. One doesn't have guassian blur, the other one doesn't have right-to-left languages.
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.
Maintaining "5 different native UI applications" should involve one codebase with the whole internal logic, and 5 separate UI layers mediating between that logic and the platform it's being run on (including UI). It should not involve rewriting the same thing 5 times.
Pretty easy to create such framework in something like C++ or having a scripting language that drives the native UI widgets, something like JavaScript.
UI these days is often more complex than the underlying logic itself. App logic became, to me, even secondary. Most of those issues are solved problems (databases, sql, rest, xml, json) and are mindnumbingly stupid and boring to implement. Save data record.. query data record.. validate data record, yeah, yeah, really complex.
A good fancy UI however... good luck.
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.
I agree, although there are now more platforms to deal with than back in the days when it was just Mac and Windows: add iOS, Android, desktop web, mobile web.
I think it also helps when it's easy to share code between platforms, which again, used to be easier when you were just targeting the desktop (just use C or C++).
Now it's a bit harder because there are no great languages that span all platforms easily without a bit of hacking. Most languages are managed and memory-safe now; that's a good thing, but it makes them more heavyweight and less portable. They generally want to drag in their own frameworks (e.g. Flutter, React Native) rather than letting you put your own UI layer on top.
Platform fragmentation exists since ever.
I was thinking mainly of the 90s and early 2000s, I guess, and for desktop apps where the main platform of interest was Windows, followed by a long tail of Mac, X-Windows, BeOS, etc... All those platforms could “easily” (i.e. with effort, but no rocket science required) be handled by a single C/C++ codebase with platform-specific #ifdefs.
I think the equivalent for today’s platforms would have to be Javascript. Unlike the C/C++ approach, you lose direct access to platform features.
This problem is already solved by virtualized lists available in any decent framework. Why people don't use it is beyond me.
I think in the case of something like Facebook, the sheer complexity of their product drives a need for a singular code base. It would slow their engineering organization to a halt to ensure feature parity with largely seperate code bases.
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.
- 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.
It doesn't really matter what else is going on in your app, if that work can be done more efficiently to produce a more consistent result, then that's the decision you make.
Often with frameworks like React Native or Flutter, it means inconsistent UX bugs on each platform. Why do you think Facebook and Instagram and Airbnb abandoned RN in all their primary interfaces?
The "more efficient" implementation might lead to consistency across platforms, but people are pretty tied to the phones they have. Things like dropped frames, slow scrolling, UI locks, all have a subtle effect on the user whether they can point it out or not, and you're more likely to have those problems by diving in to these frameworks without understanding the underlying platforms.
This isn't argument to share no code whatsoever. But so many people who immediately turn to these frameworks either want to ship something at the expense of UX/design, their app is so small that it doesn't matter, or they have no idea what they're getting into.
If we know so much about what they expect, why is it still hard?
I wonder if all the trend chasing is really just making busy work and getting in the way of truly standardized and dumb simple building of software.
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.
If you want an app that has platform semantics on every major platform then you need separate code bases. If you want an app that has the same semantics on every platform then you go with a cross-platform toolkit.
What's not true? You just agreed with my statement. ¯\_(ツ)_/¯
That was my statement. You are saying it's not true. All the upvotes suggest some would say that. Therefore my statement is true.
I'm not sure why you're so confused here. This isn't at all applicable to what you are saying. You are talking about writing an app once and having one code base, which is exactly the opposite of what I was talking about. You have constructed a straw man and called it not true.
I've never finished a React Native app without native code. I've done a few now and I've come to believe it's not worth even trying to avoid it and sometimes worthwhile to look for places where a little native module can yield performance or UI wins. React Native is the glue or orchestration and it is, to me, extremely good glue.
I haven't seen many people beyond the tutorial level suggest otherwise. It provides a common structure (which is enormously useful), and some quick consistency wins for simple stuff like your About Us screen.
Also on Desktop, macOS is the only one that even has a single official "native" toolkit.
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.
> 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).
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!)
The relevant comparison here would be between:
- (1) truly native uni-platform mobile apps (native Android and native iOS apps)
- (2) cross-platform mobile apps using native widgets (not sure if there's any alternative to React Native here)
- (3) cross-platform mobile apps that draw their own ui, but NOT using web technologies: Flutter is the only obvious example (there are older things like Kivy which uses Python and OpenGL but I think it was mostly used for games and kids app, not that popular)
Web-techs-based hybrid-mobile apps are a different thing (Cordova, Ionic etc.) and, yes, there everyone agreed they feel inferior to users, just as mobile optimized websites feel inferior.
Unfortunately this is the problem here, it's incredibly easy to compare apples to oranges here, I don't blame, just saying that all sources are misleading, probably it's better to play with few things and see the "gut feeling"... it's pretty obvious that underlying tech and whether the widgets are drawn natively or not is NEVER a differentiator between successful and unsuccessful apps, it's always all the other things :)
Computer programming is a hell of a drug.
All of my experience as a user and developer points me the other way, so I'll need some proof to be convinced.
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.
Wash, rinse, repeat.
TBH I'm not sure Flutter can be fast and smooth enough for all... the market is full of crappy devices and even the good ones perform badly when their RAM is maxed out and CPU throttled bc of battery saving.
Maybe full native is the way to go. But not because of "perfect" shadows and font widths... Users care about consistency of stile inside one app, not app-style vs. system-style.
Do you have a source for this claim? This conflicts with the results of some UX studies I've seen.
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.
https://github.com/revery-ui/revery
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...
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.
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.
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:
2- You have a driver that launch the UI: When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic.---
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.
A friend described it to me as "Unity for apps", which I think is pretty positive and accurate.
https://www.nativescript.org/
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.
Installed the Playground app. When I try to open any of the examples from https://market.nativescript.org/?tab=samples&framework=all_f..., Safari says “Safari cannot open the page because the address is invalid”.
For example, https://play.nativescript.org/?template=play-js&id=h9CNcL&v=... tries to open nsplay://boot?pKey=pub-c-a303d41e-5c6b-4030-8151-c056278a7944&sKey=sub-c-2d2f1312-4f78-11e7-ab90-02ee2ddab7fe&template=play-js&sessionId=h9CNcL_3542
Running iOS 12.3.1 on an iPhone X. Is anyone else having this issue?
[0]: https://github.com/NativeScript/playground-feedback/issues
[1]: https://github.com/NativeScript/playground-feedback/issues/1...
Please note that the links in the issue you submitted need to be changed because you copied the link text, which are only partial, rather than copying the link target URLs.
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 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.)
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.
All of the with the bonus that C#, JavaScript and C++ actually have lots of market demand, Dart remains a possible CoffeScript.
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.
That still means you have to write the GUI again for every platform, and you still have to use the Android API which is a very awkward system to make GUIs with (animation is extremely difficult, Activity and Fragment lifecycles are very complicated, etc).
CppCon 2014: Zaika Antoun "Microsoft w/ C++ to Deliver Office Across Different Platforms, Part I"
https://www.youtube.com/watch?v=3HROqnw-nf4
CppCon 2014: Zaika Antoun "Microsoft w/ C++ to Deliver Office Across Different Platforms, Part II"
https://www.youtube.com/watch?v=MGMoRu5yrVc
CppCon 2015: Jacob Potter & Andrew Twyman “Bridging Languages Cross-Platform..."
https://www.youtube.com/watch?v=K-k-axW2utc
CppCon 2017: Stephen Spann “Cross-Platform Apps with Dropbox’s Djinni...”
https://www.youtube.com/watch?v=ssqhz_1pPI4
CppCon 2014: T. Grue & S. Kabbes "A Deep Dive into 2 Cross-Platform Mobile Apps Written in C++"
https://www.youtube.com/watch?v=5AZMEm3rZ2Y
Naturally the native UI has to be used.
Are we talking about having a good user experience here, or having the easy lazy path for the developer?
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.
- 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.
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.
I don't really like Javascript as a foundation so I'd almost be inclined to throw away a superior type system in order to have the bedrock be something else, opinions might vary though, I know.
And probably we'd all have loved to have Kotlin instead...
For what it is, I quite like Kotlin (particularly when placed against Java, of course), but I would not want to give up structural typing for much of anything in 2019. It makes writing obviously-correct code significantly easier.
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.