4 ms·

> I mean, I hate to be flippant about it, but honestly the biggest factors in Google's funding of Flutter in the last 5 years have been COVID-19 and Russia atta

> I mean, I hate to be flippant about it, but honestly the biggest factors in Google's funding of Flutter in the last 5 years have been COVID-19 and Russia attacking Ukraine, along with the subsequent market instability and inflation. Very fair > Well that's fine but I can't afford to have someone comb through 600,000 apps and make a call for each one on whether it's a hobby or not. :-) > We don't know how people wrote their apps. Also, someone can do a single Udemy course and then develop a killer app that makes millions of dollars. Is that a hobby? > I assure you plenty of commercial projects fail in exactly this way. ~90% of startups fail. Here I what I was getting at was todo examples being submitted, or some single tutorial chat client, someone can come out and make flappy birds of course, I taught kids in the past and some went on to publish their apps as encouragement from their parent. Nothing wrong with it, just don't see it paying the bills was my point. That was the totality of my point I think.... > The value Google wants is ad dollars, Android users, and reduced internal development costs. I was trying to get at if a billion "hobby" devs don't drive any of this it's all a zero, thus my interest in that number. > My job is working on Flutter, and I am not concerned for my job. If that's not enough, there's not much more I can tell you. This is the best answer yet > But again, the people who would work on, say, HTTP2, and the people who would work on the Game Toolkit, are entirely different people and the skills aren't interchangeable. Engineers aren't commodities you can just move around at will. People specialize, have interests, commitments are made, etc. Totally agree, it seemed more to me people were hired for this vs expanding elsewhere. > The paltry funds we spent on the Game Toolkit work literally could not have been used for iOS work. That's just not how things work. Seems like it didn't matter though so fair enough > I would also say that "no matter what a survey says" is a very subjective way to run things. > The two are not mutually exclusive. The Google team working on Flutter is currently focusing on growing the user base _by_ improving the polish (specifically around developer experience). I could be 100% wrong but perception is real, after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished. I know in the yearly survey it asked about professional use, not sure if that gets more weight? > These numbers have been public for some time, for what it's worth. I tried googling this so many times, SEO of dev shops and blogs obscure whatever is out there on this subject. > The total Flutter developer base is much bigger than MAUs This is a deeper convo, if I have to update some wordpress php once every 6 months am I really part of the php/wordpress developer base? Idk, it's semantics I suppose, I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis. My point in being interested in this number related to "Google wants is ad dollars", and the assumption they connect. > I actually have no idea where Remy works, where is it? Remmy works for Invertase who make all the Firebase packages, he and they do a great job imho. The last pieces were on iOS, here is the issue that was filed: https://github.com/flutter/flutter/issues/110431 https://github.com/flutter/flutter/issues/110431 but honestly if you have full time iOS users ask them, they have to know, it's impossible to miss, this is not the only issue, but it requires more quantifying. To be totally frank as a dev with many iOS and Android test phones, Flutter scrolling feels like Android scrolling on an iPhone.

Hixie 4y ago
> todo examples being submitted [...] Oh I'm sure plenty of that happens, but that's true of all SDKs. Plenty of people do that with Android Views, plenty of people do that with Swift UI, etc. I have no reason to believe that Flutter is particularly different from the others in terms of the proportion of apps of this kind. > Totally agree, it seemed more to me people were hired for this vs expanding elsewhere. Ah, no. We've hired more engineers for iOS work in the past few months, but the games toolkit was mostly devrel and a contractor, if I recall correctly. Similarly for things like the pinball demo or the Wonderous app, those are primarily done by contracting an agency rather than people on the Flutter team, with the agency's feedback directly feeding into the engineering team's priorities. So for example, Wonderous was great because during its development it helped us find a whole bunch of issues we needed to fix. > after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished Again, the various areas aren't comparable or exchangeable. For example, Canonical is contributing to the Linux port, but it's not like Canonical would ever contribute to the iOS port, after all, their interest is in using Flutter on Ubuntu. Similarly, people Google hires to work on the iOS port are typically not the kind of people who want to work on Android or Windows, and so on. There's lots of areas of specialization, and if you task people to work on areas they're not experts on and not interested in, you're just going to burn them out and get low-quality work. Even if people were commodities and interchangeable, though, I don't think it makes sense to focus on one area at the exclusion of another. There is more value in Flutter being able to target seven platforms (Android, iOS, Windows, macOS, Linux, web, and Fuchsia) well, than there would be in targeting just one platform completely perfectly. Especially because the effort to get from zero to excellent is much less than the effort required to get from excellent to perfect. Flutter is not unique in this. Kotlin isn't perfect on Android, but that doesn't mean JetBrains should avoid working on web support. C++ isn't perfect on AT&T Unix, but that doesn't mean people shouldn't implement it on other platforms. HTML isn't perfect for documents, but that doesn't mean we should not have extended it to applications. My house's kitchen isn't perfect, but I still want a bedroom. > I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis By that definition, I am not a programmer, because there's literally no language that I use every week. Indeed, there are entire weeks where I don't write any code at all! > https://github.com/flutter/flutter/issues/110431 https://github.com/flutter/flutter/issues/110431 Looks like Chris is working on that one. (By the way, that issue was filed by a Flutter team member, so presumably that answers your question about whether the Flutter team notices iOS issues.) (Also, that issue is a good example of the tools that we use to test this stuff.)

Hixie 4y ago

> todo examples being submitted [...] Oh I'm sure plenty of that happens, but that's true of all SDKs. Plenty of people do that with Android Views, plenty of people do that with Swift UI, etc. I have no reason to believe that Flutter is particularly different from the others in terms of the proportion of apps of this kind. > Totally agree, it seemed more to me people were hired for this vs expanding elsewhere. Ah, no. We've hired more engineers for iOS work in the past few months, but the games toolkit was mostly devrel and a contractor, if I recall correctly. Similarly for things like the pinball demo or the Wonderous app, those are primarily done by contracting an agency rather than people on the Flutter team, with the agency's feedback directly feeding into the engineering team's priorities. So for example, Wonderous was great because during its development it helped us find a whole bunch of issues we needed to fix. > after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished Again, the various areas aren't comparable or exchangeable. For example, Canonical is contributing to the Linux port, but it's not like Canonical would ever contribute to the iOS port, after all, their interest is in using Flutter on Ubuntu. Similarly, people Google hires to work on the iOS port are typically not the kind of people who want to work on Android or Windows, and so on. There's lots of areas of specialization, and if you task people to work on areas they're not experts on and not interested in, you're just going to burn them out and get low-quality work. Even if people were commodities and interchangeable, though, I don't think it makes sense to focus on one area at the exclusion of another. There is more value in Flutter being able to target seven platforms (Android, iOS, Windows, macOS, Linux, web, and Fuchsia) well, than there would be in targeting just one platform completely perfectly. Especially because the effort to get from zero to excellent is much less than the effort required to get from excellent to perfect. Flutter is not unique in this. Kotlin isn't perfect on Android, but that doesn't mean JetBrains should avoid working on web support. C++ isn't perfect on AT&T Unix, but that doesn't mean people shouldn't implement it on other platforms. HTML isn't perfect for documents, but that doesn't mean we should not have extended it to applications. My house's kitchen isn't perfect, but I still want a bedroom. > I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis By that definition, I am not a programmer, because there's literally no language that I use every week. Indeed, there are entire weeks where I don't write any code at all! > https://github.com/flutter/flutter/issues/110431 https://github.com/flutter/flutter/issues/110431 Looks like Chris is working on that one. (By the way, that issue was filed by a Flutter team member, so presumably that answers your question about whether the Flutter team notices iOS issues.) (Also, that issue is a good example of the tools that we use to test this stuff.)