[garrtt]

> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality. By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.

from pay.google.com

> Starting April 5, you won't be able to use pay.google.com to send and receive money from other people. To send and receive money, use the new Google Pay app.

[shepherdjerred]

The easiest way to get rid of 500,000 lines of code is to delete your website

[rp1229]

The new Google Pay app on iOS is incredibly sluggish -- animations stutter, switching pages has hesitations. I'm not sure what they mean by "quality" in this case.

[eseidelGoogle]

[Flutter Eng. Dir here]

We were also not satisfied with the performance of the initial GPay release. We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app. Hopefully the next release of GPay will be out soon and others will be able to see the progress we're continuing to make with the team.

[ROARosen]

> We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app

So seriously, how can you reassure any indie dev not getting VIP support to optimize their app for laggyness, that they can easily produce a decently performant app?

[Hixie]

Many of the lessons we learn with GPay directly fed into improvements in the framework, improvements in our tooling to make this kind of debugging much easier, and better documentation to try to scale the knowledge to the whole community. Some of these have already shipped (see e.g. new features in our DevTools) and much more will continue to deploy over the coming months.

[ignoramous]

Thanks.

Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress.

And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply no alternate universe where a third-party team gets the level of access the way you described the Google Pay team did.

Of course, it helps that the stakeholders are in the same company, but my point is, shouldn't there be a Flutter Foundation where every developer can feel at home on equal footing with other Googlers? Flutter is so promising, and yet, at the same time, I don't want to end up being slave to its complexities with no way out as a third-party small development shop.

Despite that, I'm 99% porting my cross-platform app to Flutter after strong reviews from other developers I know.

[Hixie]

I can't speak for Jetpack, but as far as Flutter goes: Flutter is open source, we do all our work in the open. File a bug; we look at all our incoming bugs and there are members of the Flutter team (volunteers as well as people from Nevercode and Google) who try to reproduce each issue. We don't always have the bandwidth to fix everything, but last year we fixed roughly as many bugs as were filed, so the odds are pretty good. (And of course you're welcome to try to fix the bug yourself, we accept PRs from anyone, not just Googlers. See our contributor guide on GitHub.)

We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.

[vendiddy]

We are using Flutter at our company and it's far from a black box if you get stuck.

For example, try going to a TextField widget and use go-to-definition view the source source code. You can go very far down the go-to-definition hole. Even to the point where you can see where the blinking cursor is being rendered.

For several "blockers" we did have, we were able to copy/paste the Flutter implementations, rename them, and modify them to fit our own needs.

[distances]

Android development is like that; you hit a framework bug, you'll expect it will never get fixed. Just find a workaround and accept it's what it is.

[dep_b]

At least with iOS you know it will take three years for something to come out of beta but then it's pretty solid. It's just Xcode that never gets fixed.

[dshpala]

Hmm, LiveData is pretty straightforward class, over the years I think I memorized its implementation. I'm curious what's the issue is?

[ignoramous]

The bug is, on ocassion, while executing a query, LiveData would hit EACCESS trying to open the table (?): https://issuetracker.google.com/issues/170228126

It had to do with their Invalidation tracker (a table, I believe, which is a living log of ordered updates that need to be delivered to observers).

[dmitriid]

The ad:

> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.

And then, the reality:

> We were also not satisfied with the performance of the initial GPay release.

Ah, the classic false advertisement.

Let me re-write the ad for you:

> Thanks to several-months-long involvement of Flutter's development we could finally fix some of the issues plaguing our app that we re-wrote in Flutter. We're still not close to the release, and we only hope it will be better.

[rubicon33]

Flutter used to be such a great experience, but something happened ~6 months ago that totally derailed it.

It brings my late 2016 MBP to a crawl if I am building on iOS simulator.

After reading online about it being related to Metal, and needing to switch flutter channels, trying that, and still seeing no success... I just gave up on Flutter (for now).

Maybe Flutter 2 has resolved this?

[eseidelGoogle]

[Flutter Eng. Dir here]

I would love to learn more about your experience. Would you be willing to file an issue and either post it here or CC me on it?

flutter.dev/support

[rubicon33]

This closed issue from 2018 appears to be the same issue I was experiencing in ~mid 2020.

FWIW, I was also using Rive animations in my app.

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

[bkm]

Relevant:

https://www.reddit.com/r/FlutterDev/comments/jwmepu/very_poo...

https://thomasmiddel.medium.com/flutter-its-poor-ios-perform...

[ywei3410]

Hi,

Could you elaborate on some types of applications which wouldn't or would be a good fit for Flutter at the moment?

There's a lot of comments and links to applications both working and non-working; but I don't really have a good gauge as to what works and doesn't.

[gaaclarke]

[flutter developer]

Hi, I audited the performance of the GPay app. Almost all of the performance issues in GPay are related to its use of vector graphics libraries which make Skia spawn many new shaders that have to get compiled. The suggestion was given to move to raster graphics but since GPay ships in many locations that are sensitive to app size, like India, they made the tradeoff to keep raster graphics.

That said there are some longer term initiatives to address this problem on Flutter's side and Skia's side since the problem can show up outside of vector graphics, it's just more unlikely.

[theanirudh]

It was buggy as well. I was locked out of receiving and sending payments for about a month. After some updates, had to relink my bank account and the app created a new UPI ID by appending a -1 ie. myname-1@okhdfc! It's like creating a new email ID to resolve the issue.

[sofixa]

On Android too. It literally takes 15-20s for it to charge enough for me to be able to select anything.

[aitchnyu]

I once noticed the green checkmark animation for a failed payment.

[adam12]

I have confused Google Pay with Google Play twice this week. I wonder how many other people get confused by this.

[alfalfasprout]

Google pay is utter trash. Crashes and super slow. What quality are they talking about??

[oh_sigh]

The website and the app are two different things.

[buzzy_hacker]

> the team removed feature disparity between platforms

[oh_sigh]

Platforms being ios and android, not mobile and web.

[ewindal]

Still doesn’t explain why you think removing LoC in a mobile application removes features from a web application.

[ComputerGuru]

The web application was deleted. That means there is no feature parity to factor into consideration.

[ewindal]

They are obviously talking about feature parity between the platforms android and iOS that their _mobile app_ targets. You cannot be this dense.

[jasonvorhe]

It's not clear what you're arguing for or against. Google Pay is a product with multiple features and one of them is being phased out. What's that to do with the benefits they're claiming from the rewrite of the mobile app?

[SamBam]

"I have a website and a mobile app. I unified my codebase with Tool X and saved a million lines of code!"

"Didn't you simply delete the website?"

"Yeah, what of it?"

[fastball]

Let me try:

> Flutter 2 supports web now!

> We've re-written GPay in Flutter 2!

> We're dropping support for using GPay on the web...

[dimator]

That doesn't follow. There's any number of reasons the web app would be shut down, usage statistics being the most likely.

[fastball]

Yes, exactly, it doesn't follow. You've just re-written your app using a framework that allows you to run one codebase in multiple places, including the web, and instead of doing that, you decide that you no longer want to support the web at all.

[oblio]

They claim a huge reduction in source code line count. After they've just decommissioned their web app...

[ehsankia]

The web version isn't shut down, but losing crucial functionality. If Flutter let's you run the same code across multiple platforms, then what reasoning is there for one platform getting less functionality after switching to a framework that, if anything, should increase cross platform feature match.

[The_rationalist]

Flutter web isn't production ready, it's false adversiting.

[AlphaSite]

I think it’s disingenuous to imply that the savings were purely from sharing a code base vs removing features.

[garrtt]

> removed feature disparity

After April 5, I will have to use the app so that I can get back functionality that I once had on the web.