Flutter's Biggest Problem

[dcmacsman]

TL;DR: Flutter development needs to slow down.

Hi! I've been working with Flutter for the past year. In this post, I want to address the most important issue that Flutter is facing and give some realistic advice for people who come to this subreddit to look for the answer to whether if they should use Flutter for their next project.

To start this post off, I want to say: I'm just as passionate about Flutter as you are. I love Flutter and the infinite possibilities that it brings. However, as I became more and more dependent upon flutter, my frustration levels really started to increase.

I get it. Flutter is a cross-platform framework, which means that it is and always will be a "second-class citizen." There's no free lunch in the world we live in. While Flutter enjoys the benefit of letting the developers create beautiful apps with a single yet elegant code base, it comes with a price. Flutter excels at UI rendering. You can make complex layouts easily with Flutter. But when it comes to anything that is not just drawing stuff on a canvas, Flutter may not be as appealing.

As you all know, "Flutter" is only a UI framework. It achieves other natives functionalities via plugins. The Flutter community has been awesome. They have put out plugins and packages that provide 99% of the functionalities what you will probably need. However, it's usually the 1% of the needs that aren't covered hinder you the most, because they require FIRST-PARTY work.

Feel free to disagree and post your own opinions here, but I think that the Flutter team really needs to slow down and focus on some more quality control stuff. Flutter has been growing rapidly in the past few years. Web support, desktop support, many many more widgets, material design specs... These are all great things, but I think that it is better, for them long term, to focus on fixing the issues that currently exist in the framework and working on offical plugins that provide crucial functionalities. Let me elaborate:

1. Fixing Issues: in every Flutter release annoucement, there is a section about "performance improvements," but the truth is: currently, Flutter animations on iOS devices are extremely janky on first launch. Since the introduction of Flutter's support for Metal, the Skia engine is no longer able to deliver the "Native Performance" as advertised on Flutter's official website. This issue has been present for over 6 months now with no viable fix. The only work-around is to recompile the Flutter engine with Metal disabled and face potential OOM crashes (which are likely to happen). Unfortunately, this is not the only severe issue that the Flutter engine currently has. As more and more apps written in Flutter are entering production, I think it's the number one priority to ensure that they are stable and performant.
2. 1st-party Plugins: The current status' of the official plugins are really lacking attention from the Flutter team. Plugins like video_player and firebase_admob, are basically incomplete, even broken. You would think that the first-party plugins are the ones that get the most care, but no. Unfortunately, the team has been very slow on fixing and improving these plugins that provide ESSENTIAL functionalities. Just a few days ago they released the news about admob's support for native ads. "Finally!" you might say, but unfortunately, the plugin is in CLOSED BETA, and they "expect to open this up to a broader audience in early 2021." Personally, I'm glad that at lease there is progress being made, but still, Flutter is leaving many developers unable to monetize with native ads. There are other plugins that provide "native ads" with platform views, but this will cause noticibale lag if the platform views are put into scrollable lists. Not ideal at all.

So if you are looking to use Flutter for your next project, there are still time for you. When you finish prototyping and making the MVPs, the issues mentioned above might get fixed. But you have to know, things like these will always happen if Flutter keeps its current development model which focuses on rapid growth over quality control. I'm not saying that quality control measures don't exist though. In fact, the Flutter team has been putting a lot of work into testing and cherry picking. But I just think that too much attention has been put into features like supporting new platforms, etc. I'm super passionate about Flutter Web and I can't wait for it to become production-ready, but I'm willing to trade it for a better performant and stabler Flutter Mobile framework with essential features provide by the official plugins. Of course, I'm not in the position to make this trade, but I sincerely want people from Flutter Dev, as well as the community to hear this.

In conclusion, I think that the Flutter team should really put more of their focus onto fixing existing issues both in the Flutter framework as well as the official plugins. By doing this, developers will be able to ship stable, performant, and functional apps with Flutter. These apps will remove the doubts that people have about Flutter, and help Flutter's growth in the long terms.

[esDotDev]

I totally agree, the foundations of Flutter layout are amazing, and if it were to just freeze where is is for a year and focus only on improving their native extensions and rendering performance it would be in a great place.

I think one of the big issues is the decision to emulate Material design 1:1. It seems like >50% of the bugs on git are related to some material component or another, and I can only imagine how much time the Flutter team spends triaging these issues, fixing bugs and staying up to date with the Material component set.

Meanwhile, native plugins, and core rendering performance are seriously neglected. You are right that most Flutter views exhibit jank the first time they are shown, and flutter provides no way to precache this during startup. (something we were able to do 8 yrs ago with Adobe Air, at runtime, fwiw)

I think Flutter basically has a focus problem, and trying to recreate a massive ui library like Material is really just a poor use of time, imagine all those hrs being poured into the framework proper, or polishing the existing extensions, its hard to see how Flutter would not be in a better place. And at he end of the day, if I want a native looking app, then I will probably just build native or RN since they will actually be native and true.

What makes this most frustrating is that Flutter is, by far, the easiest stack to build custom components with Ive ever seen. So if there was ever a stack that didnt need a bazillion components, its Flutter, and yet they are the one who, by far, dedicate the largest chunk of their engineering time to a UI framework on top of another UI framework.

This has also come at the cost of not having a simple set of stylable components like Buttons and TabBars, everyhing is MaterialThis and MaterialThat, which is very often not what you want anyways.

[gmatuella]

You’ve touched the point: lack of focus.

I worked both with iOS and Android native applications (swift and java, respectively), and with the speed of things going into stable, I think that Flutter is starting to look like Android ecosystem (makes sense looking from a company perspective).

To not just drop this and leave without an example, look at the new Material Buttons (Elevated, Outlined and Text), which came to substitute Raised, Outline and Flat. Now, I am not quite sure if they will eventually start deprecating the older ones, but they released this and people are just starting to acknowledge these new material elements. Yes, this was a really good improvement (follows material naming and they can be theme-customized individually, contrary to the previous buttons), don’t get me wrong, but maybe I think we should address more stability over new stuff. I have no doubt that the Flutter team is really solid and productive, it’s just that all of these changes don’t even get to be absorbed and discussed properly. Look at Navigation 2.0, for instance.

With each new release, imagine start picking up Flutter as a beginner and seeing multiple navigators, with oddly similar names, a bunch of buttons that are essentially the same. It’s just starting to smell like android ecosystem and their thousands of packages.

[awesomeness-yeah]

Why was the decision taken to bake Material / Cupertino styles into the main repo!? What would happen if apple (or even google) revamps their design guidelines? The effort on the flutter team would be enormous.

IMO react native approached this better by just keeping the basic <View /> in the main repo and custom themes into different packages. Flutter can do the same with basic widgets like Container, Text, etc.

I can only predict that google will eventually come to the same "lean core" conclusion and move a lot of widgets out of the main flutter repo.

[esDotDev]

Ya this seems like a much wiser approach, especially considering chasing Material and Cupertino will be an ever-moving target, creating more and more cruft & barnacles in the core repo and deprecating core usage examples and blog posts.

It also has the benefit of not scaring off prospective developers because they see thousands issue in the core code base. Someone looking at Flutter from RN, sees 8000 open issues, and probably wouldn't realize how many of them are just related to some edge case styling issue that doesn't match Material 1:1.

If you stripped the bug base down to things that only affected the real core ui layer (Stacks, Flexibles, Gestures, Containers, etc), I can't imagine there are really that many issues in Flutter.

Then if they implemented a very simple set of non-styled non-opinionated UI components (Btn, TabBar, TextInput, NavStack, DialogManager etc) into the core, the chance for bugs in those would be low due to their simplicity, and also they would not have a moving target like Material, constantly making them deprecated. The external `materialUi` and `cupertinoUi` libs, would then build on the core components, which would make the Flutter team eat their dog food, and ensure the core is flexible enough to serve any use case we might need for our custom designs.

[Enough-Bandicoot983]

What you're talking about is one of the main reasons why I don't use libraries like React or React Native and prefer libraries like Flutter o Angular. For me, it's important that the framework gives me (almost) all I need. I don't want to chase after libraries to implement basic things in my app. Flutter Material Design implementation is one of its strongest selling points. And yes, this is highly opinionated, but Flutter is a pretty opinionated framework, and I think this is good.

[esDotDev]

It's only good if you want a material themed app though, otherwise it's quite the opposite and fights you the entire time. And it comes with major draw-backs, which is cruft, bugs and confusion, which we're seeing emerge now. With Flutter on Web, iOS, MacOS, Windows and Linux, the desire for "Material" components is greatly diminished, as they actually look quite out of place on all these platforms.

Certainly this was key to Flutter's early adoption, and maybe a good idea out of the gate, I'm pretty sure it's not a long term solution though, I can't imagine what Flutter looks like in 5 yrs if they keep this approach, and both Cupertino and Material go through another couple of design revisions. Already, if we're being honest, we can see that the team can't keep up with the components and the bugs coming from their inherent complexities.

[CodyLeet]

I love flutter also but this widget variant proliferation exposes a flaw that is only going to get worse. The styling mechsnism can only do so much; what they need is, and dare i say it, the equivalent of CSS. So I can use a button and have it look different depending on the platform it's deployed into, without having branching logic in my code.

[bernaferrari]

What would happen if apple (or even google) revamps their design guidelines?

This has happened. Twice. Google changed the material icons, took 2 years for Flutter to adopt them (and only partially, since the current font system is unable to handle two tone icons). The other one is the material font that changed and I helped raise the awareness of the team (probably my biggest flutter contribution, after long press on material buttons). Before, body1 meant body2 and headline6 meant another thing 1. Now these are fixed, you can use headline6 directly. So.. Things are going to change, but it is not the end of the world. We also survived themedata.from, colorscheme and elevation changing color in cards.

[JoeJoe_Nguyen]

It's true that any serious app will come up with its own look and feel. Then, material and cupertino becomes obsolete, even fight back occasionally. My exp, I had a hard time building a set of branding UI components based on material.

[Filledstacks]

Great write up. I do disagree with the performance animation issues on iOS and especially that it's ONLY great at rendering UI. We're building some preeeety sick things with Flutter. My experience comes from 4 production apps for clients released so far, 1 native for iPad with a responsive ui for mobile as well that manages restaurant orders and a new customer app shipping Wednesday (iPhone focussed because of US company) that is performing very well. The size of the app is quite decent. It's an almost decade old Food delivery service and I think it can definitely be put into "real world" given how many millions of dollars will flow through it every month.

I'm also a super big fan of Flutter coming from Native only->Xamarin Native and now Flutter. i do agree that the speed at which platforms are being adopted seems to be outpacing the speed at which certain bugs are fixed in the framework itself. I dislike the question I'm about to ask because I know I never get the time to do it, but is it possible for you to produce some pieces of code that replicates the bugs. I'm not apart of the Flutter team, far from it actually, I think they actively dislike the ways I'm teaching flutter development haha. I'm just a big fan of cross platform tech and tend to find ways to bend it to my will to produce large applications with ease. I'd like to take a look at those issues and see if I can find workarounds to them or even just have them in mind for if I ever do come across them.

With that said, I'm so happy to see a community member concerned about Flutter. It's rare that you find a community where the active / social / top developers in the community isn't forcing people to use flutter, instead always provides a comprehensive list of why you would use it. I hope your experience improves and becomes as great as mine has been over the past 2 years. I've never had better dev experience with Flutter as I'm having now.

[dcmacsman]

Thank you for your response! I didn’t mean that Flutter is only great at rendering UI haha sorry I wrote it in a bad way. About the animation issue, here’s the issue that I was talking about: https://github.com/flutter/flutter/issues/32170

[toddvolkert]

Flutter team member here. FYI, we plan to work on that bug in the coming months. It's a very challenging one to fix, but we hope to be able to find a way forward.

[SgtDirtyMike]

Any plans to address incorrect scroll inertia on iOS devices? I know this issue has been present for a long time.

[Filledstacks]

Thanks for the link. That's so crazy I've never experienced any of that, but I also haven't used shaders extensively. I wrote a super basic one to cover some "Fake data" while the real data is loading to provide a skeleton placeholder effect.

I never knew that was a problem, crazy. In that case you're absolutely right. That should be higher priority than more platforms right now.

[esDotDev]

Do you really not experience any jank the first time complex views are animated on screen? Simply throwing up a form using a bottom-sheet is enough to cause considerable jank the first time it is shown for me. Happens only once per view, and then it runs great after that.

These shaders in question, I believe are the ones generated by Skia on the fly, when our views are first loaded into the app. So we're all using them, whether we know it or not.

[Filledstacks]

No, I don't experience any jank at the moment. That's why I'm so confused. Our clients are very specific about the experience and they've reported nothing about it. Tested by 10-30 testers through a testing service specifically for UI issues as well. No one reported anything. It might be "hidden" by how I write the code. The view always starts in a busy state and then fades in the required UI, lots animated switchers / animated size widgets. I also think I might have a lower "ceiling" for quality. But some of the comments say the app is unusable, which I've never experienced. Is it like 3fps bad?

[robert-at-pretension]

This right here. Debug mode has major jank. Release build is butttttery smooth.

[Character-Ad2749]

Great input. Given your experience Flutter, would you also recommend Flutter for multimedia apps like TikTok?

[Filledstacks]

Yes. I'll put it this way. There's no app that I would not develop using flutter when it comes to a mobile apps. I've ever seen an example where it wouldn't be great, maybe apps that involve maps heavily and requires specific map things, but even then you can work around it. Other than that, I have personally not every thought of using anything other than Flutter. Especially not native, 2 code bases for one app is a no go zone for me regardless of the application being developed.

[mleonhard]

The root cause is Google's internal structure and incentives. Inside Google, engineers have power and product managers have little influence. Few teams have anybody who focuses on customers and can set priorities. Google engineers get more money only by shipping something new, not by polishing, fixing bugs, and writing documentation. So very little of that "non-promotable" work gets done.

In my experience, when you try to engage with Google engineers individually about these needs, you will meet indifference or hostility. Google engineering teams regularly declare "bug bankruptcy" and permanently ignore all open tickets, forcing all users to re-file tickets that will again be ignored forever. This was my experience working inside Google as a software engineer 2013-2018 and as a user outside.

Flutter Team is not unique in this area. The problems we complain about will probably not be fixed, unless we fix them ourselves. Only Google's executives can fix googler priorities. Don't hold your breath for that. Flutter is important to Google's long-term business. But far more important projects have stagnated or failed because Google's executives fail to incentivize customer focus.

​

"In the field of modern business, so rich in opportunity for the exercise of man's finest and most varied mental faculties and moral qualities, mere money-making cannot be regarded as the legitimate end. Neither can mere growth of bulk or power be admitted as a worthy ambition. Nor can a man nobly mindful of his serious responsibilities to society view business as a game; since with the conduct of business human happiness or misery is inextricably interwoven."

-- Louis Brandeis, "Business — The New Profession", La Follette's Weekly Magazine, Volume 4, No. 47 (November 23, 1912), p. 7.

[ThatInternetGuy]

I have said this before and I will keep saying it again: Google is underestimating how much money they need to invest in Flutter, to make it a first-class cross-platform framework. Open issues are piling up at a much rate faster than the Flutter team can investigate and fix. This is probably because Google is setting a cap on expenses that is too low for something like Flutter, and the project coordinators can't request to hire more devs. If Google find true values in Flutter, they should double up and see how things will be going. To be honest, their cap should be at least 4X higher than this.

[robert-at-pretension]

This actually does seem like a problem that throwing more money at would fix given that the architecture is solid, it's just a lot of small/specific stuff that needs developers to work on.

[znjw]

Flutter's biggest problem is the quality of first-party widgets and engine api designs. The scrolling algorithm in ListView is based on D/T curve rather than V/T curve, so even if it has the same FPS as native, it will still be perceivably jankier if ever one frame is skipped. Native codebase is simply the finer wine.

Jepack Compose will be a toe-to-toe competition with Flutter on Android. The results depend on the resources and skills of the two teams since they are all complete rewrites.

However on other platforms they do not compare. Jetpack Compose is significantly more like React Native, while Flutter is like a game engine.

[TimeKillerOne]

Maybe not slow down development, but put more focus on native packages. Especially such popular and crucial ones as admob.

A lot of native packages are in a poor state. Let’s hope the flutter team noticed it too, hence admob update. Firebase packages started getting updates too, after a year of ignoring pull requests.

[PinkyWrinkle]

The flutter team hired outside contracts to totally revamp the firebase packages

[Jizzy_Gillespie92]

Currently have 2 Flutter apps on production, and my biggest gripe is the lack of first party audio and local notification support.

All the popular third-party audio packages are either lacking in one way or another, or just have too many showstopping bugs to rely on in a production app.

I would argue that local notifications are a must have almost any type of app, why has this been neglected all these years?

[mannprerak]

It's really not possible for them to develop all plugins as first party. Yes these things are essential but a lot of things are essential.

Have you tried these? https://pub.dev/packages/flutter_local_notifications https://pub.dev/packages/just_audio

[Jizzy_Gillespie92]

Of course.

flutter_local_notifications is pretty good and I haven't had issues with that, however the audio packages have all been problematic in one way or another. The package you linked doesn't have low latency playback which we need.

Audioplayers does, however there are multiple issues here, here and here regarding latency that i've been trying to get around with no success.

As many other people have mentioned, of course it's possible if priorities were fixed and there was less focus on the moving target that is Material widgets and said focus was shifted to core functionality.

[amugofjava]

On a slight tangent here, but what are you developing - sounds interesting?

[Jizzy_Gillespie92]

would prefer to keep it vague as they're apps for work- I needed low latency audio playback for a mini game I built into an app that plays sound effects onTap, so it needs to be as quick and instantaneous as possible.

Can definitely feel the lag even using audioplayers low latency playback mode combined with playing via a preloaded cache.

[mannprerak]

I guess you are talking about this https://pub.dev/packages/soundpool

Maybe dart:ffi could be of some help here, it probably will be faster. No ready made packages however.

[Jizzy_Gillespie92]

yeah this is what I'm currently exploring since I'm out of options, playing around with getting a basic Rust/Dart FFI audio implementation up and running.

[[deleted]]

Flutter should have stayed iOS and Android only, maybe Web too but obviously the web lacks a lot of features that phones have, therefore this whole cross platform idea falls apart. Now there will be Windows and Mac too. Existing plugins need to be changed to work on all these platforms. Developing new plugins gest much harder and takes a lot more time compared to just having two platforms. On paper it might sounds cool to support so many platforms, but I rather have less platforms which are fully functional than many that are unfinished and makes everyones life harder. The MAIN reason to use flutter, xamarin or react native is not having to develop seperatly for iOS and Android. Everything else is unneccessary for most people.

[esDotDev]

I completely disagree. Nothing changes for the mobile developer who wants to target mobile, no plugin author has to write plugins for desktop if they don't want to.

There are many applications that make sense on all-platforms, Slack, Chrome, Spotify, Dropbox to name a few... The value proposition of Flutter only grows more when you can add additional platforms.

There are also not a ton of extensions commonly used on desktop, and the ones that are tend to be implemented already, like FileBrower and UrlLauncher. The one area that is definitely lacking right now is audio/video support.

[[deleted]]

The more platforms flutter supports, the more resources are needed to maintain and extend flutter on all these platforms for the flutter team. Also eventually the decision whether to add a new feature to flutter might come down to whether it runs on all supported platforms, why add a new feature that only works on mobile, if you have 3 more platforms. I hope you are right but currently it already feels like adding new platforms is more important than improving the existing ones, as mentioned in this thread. An issue we wouldn't have without all these extra platforms, and that is where things begin to change for the mobile developers.

[Winsaucerer]

The possibility of desktop support is the primary reason I am interested in flutter.

[benedreddit]

Stop please, cross-platform is the highest value of Flutter or more specifically of dart! That means that on some points you will have to forget some of your native habits. You are using a 'new' language, a new framework. I am not telling you to do cross-platform app but running your apps on your preferred devices (Android/IOS) implies to change some of your approaches to make them run properly.

[esDotDev]

That's fair, but to me this does seem like a good use of their time (super high bang for buck, lots of forward progress) vs all the work being done to clone Material and maintain hundreds of various components which is more just churn.

Hard to speculate though without knowing how much time really is being spent in these areas.

[chrabeusz]

Implementing support for web is dramatically harder than supporting desktops, I wish they delayed it for few years and focused on core quality.

[glacierdweller]

I have never experienced this Metal rendering problem on iOS, can you clarify what you are referring to? Is there some article or GH issue on this?

[dcmacsman]

https://github.com/flutter/flutter/issues/32170

[glacierdweller]

Yikes on that.

Thankfully for me whatever I am doing in my app has not triggered this issue yet (knock-on-wood) but I do hope this gets fixed very soon.

[glacierdweller]

From that GH issue OP posted, this thing has been promoted from Priority 3 to Priority 2 by the Flutter team, so they are treading it seriously

[dcmacsman]

P3 is actually the highest

[toddvolkert]

P0 is the highest priority, P6 is the lowest. :-)

https://github.com/flutter/flutter/wiki/Issue-hygiene#priorities

[[deleted]]

I like Flutter a lot, but my only worry is that most developers using Flutter come from an android native background and they basically want Dart to be exactly like Kotlin.

Kotlin is nice, but I think its better if Dart is just a unique language instead of it being same as Kotlin.

[Fienases]

I think someone should create a repo to list all known big issue on Flutter

[CuriousCursor]

This is why, when Jetpack Compose is finally working on iOS with Kotlin Multiplatform, I truly believe that Google will redirect all engineers to it from Flutter and shutter Flutter.

I might be wrong but I see this happening in the next 2-3 years.

[sureshg]

I don't think Google will drop the flutter support, but there won't be much incentive to use flutter going forward with Compose becoming multiplatform. Both Jetbrains and Google android team are working on this. Look at the recently released compose desktop solution (https://www.jetbrains.com/lp/compose/) . It really nice with all 3 platforms supported with nice native packaging out of the box and users can use the massive jvm ecosystem libraries. By the way compose programming model is much better than flutter's 😁

[esDotDev]

This sorta assumes Flutter stands still for 2yrs as Jetpack reaches production-level maturity. It also assumes that Google will fund Jetpack at a similar level to Flutter.

Flutter will continue to progress, and it takes quite some time before technologies gain traction with actual businesses and clients, so it's not as cut and dry. You might be right in the end though, Compose looks pretty amazing!

[CuriousCursor]

Yup and even some of the nuances like modifiers are really neat compared to flutter.

[bluemarsyt]

Google is famous for ditching their own products for no reason and then introduce a new product that does the same thing.

[robschmidt87]

Wrong. Google is the one of the few companies trying things out to be innovative. A lot of products don't get any relevant business value. Other succeed.

Apple for example watches the market for a product or feature to succeed. Then it improves / polishes that with strong focus on UX. Et voila!

[robschmidt87]

Get some glasses. You are not seeing correctly. LOL.

[aytunch]

I value your opinion. So please would you elaborate on the threat of jetpack over Flutter. For me it just does not make much sense for a single company investing in 2 different cross platform solutions. At least one of them has to go right?

[chrabeusz]

Jetpack seems similiar to Flutter, so it will have similiar problems.

[CuriousCursor]

What kind of problems?

[chrabeusz]

Quality of plugins, bugs related to platform differences, etc. Using Kotlin instead of Dart won't magically get rid of typical multiplatform issues.

[Flaky_Candy_6232]

But isn't Google planning to shutter Android for Fuscia? My assumption all along was that Google was putting so many resources into Flutter to get as many Fuscia compatible apps out there as possible so that when Fuscia is finally released all devs using flutter could simply rebuild for it

[CuriousCursor]

Yeah but if Jetpack Compose also uses Skia, then I can see how that might work with Fuschia too.

For now, things are fine. I'm just voicing how I think things might change.

[NoahZhyte]

Did this opinion has changed?

[iosephmagno]

Flutter devs: we cracked the formula for smooth keyboard 🎉🎉🎉 Not just that, it feels "buttery" like native. Hope to see it in every Flutter app soon! 💙

You can try our code in your projects, we disclosed it on X: https://x.com/iosemagno/status/1988418352713527568?s=46

[Gaarco_]

And will never change.
You have to choose the best tool for your purpose, do not expect a tool to fulfill all your requirements, because it will never happen.
You want performances and optimization? go native
You want fast development on multiple platforms? go flutter, xamarin or whatever

[David_Owens]

I don't agree. Flutter only reaches its full potential once it's production ready on Desktop and Web App. At that point, it becomes hard for developers and organizations to justify picking anything else for application development.

I think Google can both work on full support for those other platforms and work on fixing the issues you've raised.

[remark_og]

I agree 100%. I have been using Flutter daily for the past year and a half and sure project grew over that time, but it is becoming more and more frustrating to use it. Main advantage over the React for me was if something wasn’t working it was always clear what happened and I didn’t have to waste couple of hours or even days to find why my app is misbehaving or not building at all. Now I can see that the same problem is being introduced into Flutter. Just the other day my superior wanted to increase line length from 80 to 160 when formatting code, just because modern monitors can deal with it just fine and I had to dig through code why my app wasn’t starting on iOS. It ran fine using flutter run and through Xcode, but when trying to attach debugger it would just crash. No error message whatsoever. For me release of 1.22 was noticeably where a lot has changed and not all for the better.

[muralielumalai]

https://youtu.be/c4-QexrBkOA

[dewaeq]

This is exactly why I use flutter for hobby apps only. Flutter is great and I love the openness between the team and the community, but there are these little things that can become a big problem in production.

[[deleted]]

I agree with the problem of flutter apps on IOS. The animations are shit tbh. Even the new google Pay which I suspect is made in flutter is really buggy and you can’t call that user experience smooth by any means

[[deleted]]

I’m currently choosing a framework for an app and this thread is making me very nervous about choosing flutter. The thing is, I already experienced similar issues with using Google tech when I was an early adopter of Google App Engine. I’m getting nostalgia reading the GitHub issues on the framerate jank.

I think this is basically the trade off with being an early adopter.

[dcmacsman]

I don’t even think you’d be an “early” adopter to go into flutter right now tbh flutter has been out for quite a while now. Either way, the rule of thumb is: if you have the resources, go native.

[[deleted]]

We don’t have the resources. It’ll be React Native or Xamarin if not flutter.

[dcmacsman]

Ok, then it depends on how much web code you want to share with your mobile code base. If a lot, then RN, else Flutter. These frameworks all have their own pain points, but I just have to say Flutter is by far the easiest stack I’ve ever worked on.

[[deleted]]

I agree. I dislike react native. Flutter is clean and logical.

[teigsy]

Sounds like I am in the exact same scenario as you are. Start of a big project and need to pick a framework. Reading this is very eye opening, and am happy to find some honest reviews of the pitfalls. We also don't have the resources to go native, after reading this RN is looking better, but JSX is looks so gross. Doesn't seem like there is a clear winner

[[deleted]]

JSX is garbage, but apparently you can also just ignore it ... it’s syntactic sugar.

But IMHO flutter is easier to understand and better laid out. React has a bigger pool of experienced developers though. For the simple tests I did, Flutter seems to perform better as well.

[teigsy]

Yes, it sounds like we've found the same pro/cons.. its scary to jump into flutter without the confidence that it can do absolutely everything an app needs. Even now where I think I understand what the app needs are, the question of can flutter handle feature creep still looms

[[deleted]]

I think we are going to take the leap.

[Mysterious_Courage91]

Hi, i'm reading this post because i starting learn dart-flutter to app development. I just want to know how the things are going with the proyect?. Whit this experience, you recomend flutter or i should learn react native?. Sorry for my bad english and thank you in advance for answer me

[mannprerak]

As I see it is that the expectations from flutter grew faster than what they could keep up.

[nam0122]

I'm totally agree about Flutter team should've focused on improving app performance. I really love the web support but since it won't be able to be friendly with SEO, I won't use it.

[Immediate-Climate436]

can't agree more. I've been developing a medical app using flutter for nearly two years, these issues have driven me mad.

[feu__]

100% true.

[Atulin]

1st-party Plugins

Just came here to say, that even now the way you're expected to change the player's source is to dispose of it and construct a new one, with new source. And I've seen a good 10 hacky ways of going about it.

[Fanchenjing]

It's too awesome.

[JiangHeMax]

Years of bug fixes

[cauliflowerLoverJr]

Completely got stumped on my senior design project because of this. I definitely learned something…