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.<p>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.<p>For example, in macOS Cocoa, textboxes have universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful.<p>Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings.<p>Another example of this directly benefiting users is the addition of tabs in macOS Sierra.<p>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.<p>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!)<p>Adding Flutter or any other UI library that draws everything from scratch is a <i>bad</i> idea.
> it took them almost a year to add support for 64 bit in APK<p>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.<p>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.<p>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.
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.<p>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.<p>My alternative is called "My Leaf" and its available on Google Play and the App Store;
<a href="https://play.google.com/store/apps/details?id=dk.kjeldsen.carwingsflutter" rel="nofollow">https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...</a> <a href="https://apps.apple.com/us/app/my-leaf-for-nissan-ev/id1436701776" rel="nofollow">https://apps.apple.com/us/app/my-leaf-for-nissan-ev/id143670...</a> It's completely open source.
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.<p>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.<p>Phonegap, Ionic & others are web wrappers. PLEASE let Flutter grow!
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.<p>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...<p>Snark aside, remember phonegap/cordova? Pine for those glory days of low friction?
The question is: if Flutter will not get traction that Google expects, what will happen with the project?<p>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).<p>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.
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.<p>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.
Tip: For anyone trying out Flutter, please remember to evaluate it based on release builds of your app. Scrolling and animations can feel a bit "off" when running the default debug builds. The 60 FPS butter is only really applied when that `--release` flag gets tacked on.<p>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 have a couple of android app PoCs in mind but didn't want to go down the Android SDK way which IMO is becoming more and more complicated and verbose with every release.<p>Just tried Flutter and React-Native yesterday for the first time, and I'm sorry to say both were sorely disappointing.<p>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.<p>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.<p>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.
> Why should someone ever need to offer a bug-fix bounty!?<p>Author expects bugs in open source projects to get fixed for free, by someone else.<p>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.
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).<p>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.
This seems like a fairly biased post (as he admits himself). Flutter has a lot of problems, but if you've used any other <i>cross-platform</i> system, you know it's a hard problem to solve.<p>A friend described it to me as <i>"Unity for apps"</i>, which I think is pretty positive and accurate.
For those who are looking for an alternative to Flutter/React Native, please check out Nativescript @ <a href="https://docs.nativescript.org" rel="nofollow">https://docs.nativescript.org</a>!<p>It's different in a few key ways:<p>- Draws native components (Flutter draws every pixel)<p>- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`)<p>- Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned)<p>- 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)<p>- More community driven project (with Progress standing behind, following the open-source & extra features business model)
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.<p>OP has some valid points for sure, but fact is that any framework is going to have issues. Just part of the game.
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.<p>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 <a href="https://reflectly.app/" rel="nofollow">https://reflectly.app/</a> is the poster child for this.
I am not sure if users care about controls being "native". Examples from desktop: Photoshop used non-native controls, and nobody cared. MS Office always had non-native looking menus. DAW (digital audio workstation) apps all look non-native.
A solid alternative is Intel's Multi-OS Engine: <a href="https://multi-os-engine.org/" rel="nofollow">https://multi-os-engine.org/</a><p>All it does is let you write iOS UI code in Java or Kotlin, and target <i>both</i> iOS and Android from a single project.<p>It uses the actual underlying iOS API, and simply provides Java wrappers for them, that map one-to-one.<p>I keep wondering, and don't know why it hasn't gained much traction. It is <i>so much</i> better than Flutter, is obviously reliable since it's a simple 1-1 mapping/translation layer. (There <i>is</i> more work involved with it, as you have to write the UI lawyer twice, but that's about it.)
Flutter is not that bad. It is a step in the right direction but there are some paradigms that makes simple things hard. Animations are harder than necessary and building non default layouts requires a bit of thinking to get right.<p>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.<p>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.
Even though my experience is basically the same as the author's (8y using java/kotlin toolchain), the article still seems to be written by someone with a hammer frustrated with screws for not working properly. His points can be summed up as "Flutter isn't as stable as the java toolchain that has existed for over a decade" and "I want Flutter to work the way I am used to work".
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.<p>i know they were considered experimental a few years ago but wonder what’s the status today.
My experience working with Flutter:<p>- 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.<p>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.
I still don't see any big advantages over Xamarin Native, Qt or plain C++ with native views, when going through this route.<p>All of the with the bonus that C#, JavaScript and C++ actually have lots of market demand, Dart remains a possible CoffeScript.
So mostly this is just complaining about bugs. Does he think that native Android doesn't have bugs? One could easily write the same article for <i>any</i> UI framework.<p>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.
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.
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
Last major discussion and conclusions about Flutter:<p><a href="https://news.ycombinator.com/item?id=19853247" rel="nofollow">https://news.ycombinator.com/item?id=19853247</a>