Google's Flutter: 2 Million Developers, Uptick In Enterprise Use, New Release Model Revealed

Liam Tung writing via ZDNet: Google says two million developers have used its Flutter user-interface (UI) framework for building apps targeting mobile, desktop, and the web since declaring it production ready at Google I/O 2018. Flutter is on the rise, according to Google's Tim Sneath, who said Flutter use grew 10% in March compared with February -- despite COVID-19 coronavirus pandemic impediments. He added that the UI framework now has "nearly half a million" developers who use it on a monthly basis. Most of them are also building on Windows, with 60% of Flutter users developing on Windows 10 PCs, 27% on macOS, and 13% on Linux. Google says over a third of Flutter users work at a startup, while 26% are developers working in the enterprise, 19% are self-employed, and 7% work for design agencies. There are also now 50,000 Flutter-built Android apps on the Google Play Store, and 10,000 of those were uploaded in the past month, according to Sneath.

Google is also updating the release process for Flutter to improve the stability and predictability of its releases. Google found that Flutter contributors and developers didn't understand when a release would be built and what code it would contain. Another issue is a lack of testing for branches, which means sporadic hotfix releases to address regressions or bugs, which also run the risk of introducing new bugs. Google is now moving to a branching model for Flutter, which commences with the April release and includes a "stabilization period" for the beta and stable releases to address key bugs that have been selected by reviewers. Google will also align the Flutter and Dart release processes and channels. This means Dart now has a beta channel, and it will be aligned with the Flutter beta channel.

2,000,000 mugs who don't know their history

[poptopdrop]

Google will get bored and drop this in a couple years, and move onto their next big - but short-lived - thing. Don't waste your braincells.

Re: 2,000,000 mugs who don't know their history

[BAReFO0t]

This wound suggest that there is not much to waste in the first place. ;)

You can lead a donkey to water, but it has to learn to drink by itself.
And if it fails ... well, natural selection is a good thing.

Re:

[thegarbz]

Google will get bored and drop this in a couple years, and move onto their next big - but short-lived - thing.
Don't waste your braincells.

But that's the point of UI frameworks. You can either stay current, relevant with a fresh looking app, or be one of those non-conforming people creating something that looks dated from the get-go because you didn't conform to the status quo.

If your app is to survive your UI will need to be short-lived one way or the other.

Re:2,000,000 mugs who don't know their history

[lessSockMorePuppet]

Wish we could have that short-lived UI, but the trend for our product, because the PHB says so, is to push as much logic as possible into the client-side frontend.

So, our backend is actually pretty simple and stupid. Our frontend is heinously complex spaghetti code where it does intricate ballets with finely timed race conditions.

We could replace the backend. We're always struggling to stay on top of the churn that results from frontend framework updates combined with untested (and very broken) code introduced by said PHB. We're making negative progress most of the time.

I agree with you, but it looks like a utopian fantasy from here, while shackled to this desk.

Re:

[Anachronous Coward]

At least they named it honestly -- it will soon flutter its wings and fly away.

Say no to frameworks.

[BAReFO0t]

The difference between a library an a framework, is that a framework expects you to integrate into IT. And it does not allow any other gods beside it. You can't put it into your existing workflow. You can't just use a part. You can't just stick it in your program.
It's the software equivalent of monopolistic lock-in. The opposite of modularity and gluing together small tools that do one job and do it right.

It limits you.

So I hereby declare frameworks a software design anti-pattern.
Like GOTO (most of the time). Like an inner platform (which is the mother of all frameworks).

Re:

[lessSockMorePuppet]

Small tools require you to know why you'd want a tool. A framework is like Mad-Libs; just in the blanks.

At least, that's how your boss sees it. The way we see it as programmers is, "oh fuck, the boss says I absolutely must use their piece of shit framework that doesn't provide for his use case, but he's convinced it should be done this way anyway or I'm getting fired."

So then you need to find a solution, but it can't be anything you code yourself, because that's not from StackOverflow, probably beyond his

Re:

[Njovich]

Good luck writing a mobile app without a framework

Re:Say no to frameworks.

[thegarbz]

The difference between a library an a framework, is that a framework expects you to integrate into IT. And it does not allow any other gods beside it.

Given the clusterfuck of UI designs from every coder who thinks "better" than the next, this is not a bad thing. Frameworks exist for a reason. Frameworks are widely used for a reason.

Re:

[ILongForDarkness]

It's enforced consistency too sometimes. The framework has a standard pattern to how you nest controls into each other and what is injected vs properties on the controls and what not. If you piece things together from here and there you can easily end up with a very cluttered flow for any piece of code. Will this play nice with my DI tool, how do I reskin the control? Answer ends up becoming: it depends more than it needs to. Some design choices are just choices they aren't necessarily right or wrong. Picki

Re:

[Junta]

I shudder when something wants to use the word 'framework' because it suggests that they mess with things a bit more than necessary at the low level.

If something goes wrong while using most projects that use the word 'framework' to describe them, the stack trace in the browser is utterly indecipherable even for very easy flows. Flows for which utterly standard Javascript happens to cover in a way that is much better modeled in the browser debugger.

Additionally in my experience, most shy away from doing wha

Re:

[dfghjk]

Love to hear your take on IDEs then.

"So I hereby declare frameworks a software design anti-pattern."

Is a "one and only" pattern an anti-pattern? As much as I hate and refuse to use that term, you aren't using it correctly.
Problems should not be shoe-horned into solutions. That's what patterns are for and that's what you are complaining about regarding frameworks.

Re:

[angel'o'sphere]

What you describe is not a Framework.

Re: Say no to frameworks.

[ToasterMonkey]

In the context of desktop software, why would you not use a framework then?

Using one library for interactive UI elements, another for copy/pasting or drag & drop between applications, another for filesystem access, another for sound etc. we've been there done that and it's a complete train wreck. Nobody is pining for the 90's Linux desktop experience again... right?

for... masochist.

[DraconPern]

The ecosystem is terrible.  I just looked at the subred, and there are a lot of 'minor' issues.  It's a platform for people who enjoy death by a thousand cuts.

Re:

[lessSockMorePuppet]

PHBs who like to look stylish thrive on the new hotness, while the devs slave underneath them, cursing the latest round of broken and untested changes, which will be blamed on them anyway.

Re:

[molarmass192]

Flutter has existed for less than 3 years, why would Google create libraries for use cases they don’t have? Ecosystems grow over time. Google is target Flutter for Fushia, we’ll see if it sticks. This is likely their vector for getting rid of Java on the client and not relying on Kotlin to do it.

Shame about FlutterDriver not being taken forward

[PaulHammant]

That from a reddit comment from the dev team. In my own research (as a user of Flutter for 1.5 years now), most external to google dev teams using Flutter don't rely on FlutterDriver anyway - too hard to setup, too slow and too fiddly to do basic things. It reminds me of Selenium-RC from 15 years ago (which is my fault). Thank goodness WebDriver came along and did the reverse-takeover of the project.

What's old is new again

[kackle]

Didn't Fred MacMurray [imdb.com] invent this in the 1960s?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:I've used it for some prototypes

[lessSockMorePuppet]

That's not production ready if they're changing state management every 6 months.

That's an academic toy.

It's bad enough I have to use a "move fast, break all the things" framework at work, which already has us rewriting the frontend constantly just to keep up with their changes. This looks like it also hasn't settled down enough to be able to move from "constant maintenance"/"putting out fires" mode to "improving our product" mode.

Re:

[molarmass192]

I’ve played with Flutter, at a minimum I can say that it’s orders of magnitude nicer to read than React code. The Dart prefix types are a throw back that date it in a not so nice way though.

What?

[fubarrr]

How in the world do they see an uptick in use? I think it is on the way to becoming an abandonware with multiple API fragmentation events splitting the remaining user base