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.
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.
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.
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.
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.
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.
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).
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?
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
FWIW, I was also using Rive animations in my 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?
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.
> 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.
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.
> Flutter 2 supports web now!
> We've re-written GPay in Flutter 2!
> We're dropping support for using GPay on the web...
"Didn't you simply delete the website?"
"Yeah, what of it?"
After April 5, I will have to use the app so that I can get back functionality that I once had on the web.