Keynote - Flutter Is Everywhere - Craig Labenz & Loïc Sharma | flutterCon USA 2026

[00:00:00]All right. So, welcome everyone to Fluttercon USA 2026. Good morning. I'm so glad you're all here. I'm so glad to see you. My name [applause] So, as some of you may know, my name is Craig and I work on the Flutter developer relations team and I'm joined today on this stage by Loick. He's one of the rockstar engineers that keeps the Flutter project moving. Loic has worked up and down the Flutter stack and is truly one of the most knowledgeable people on the whole team. So you're all very lucky to be able to hear from him.

[00:00:38]Now today Loick and I want to zoom out and look at where Flutter has been, what got us to where we are today, where we are at this exact millisecond and where we want to see Flutter go and critically how Flutter is going to get there. So ultimately LOIC is going to share three initiatives that the Dart and Flutter teams are embarking upon now and we hope that these three initiatives will rise to at least two needs that we have. One, we think they're going to help address the question that has kind of hovered over Flutter's head for years and years and years. We don't even need to say what it is at this point. And the other thing is we want it to meet the moment where we find ourselves right now in 2026.

[00:01:27]So we've used these words before Flutter is everywhere. But making that happen is more than just simply declaring that Flutter is everywhere and hoping that that kind of solves the problem. So running everywhere involves running on a lot of devices on a lot of architectures. It involves uh running in scenarios that were not originally imagined. It involves negotiating and coordinating with a lot of people, teams, and technologies.

[00:01:57]So, [clears throat] this moment where we find ourselves in 2026 is not primarily about AI, though we'll see later that is one of the catalysts that is driving this. But first, before we get uh before we talk about where we want to go, we've got to remind ourselves how we got where we are. And because I have the stage, I'm going to tell that story through the lens of myself.

[00:02:20]So, before I was a Flutter developer, I was primarily a web developer. And my favorite tool of choice was Django, the web framework written in Python. And though I never submitted a PR to core Django, which thinking back on is kind of crazy that that was true, I did have a handful of my own Django packages available on pip. That's Python's version of pub.dev. And some of them were pretty cool. I also read a ton of Django source code and understood how that framework worked quite intimately.

[00:02:52]Once at an engineering retreat for uh it was Zapier my company at the time I gave a talk called how the Django OM works to a room full of full-time Django developers and it was I think largely all novel information for them.

[00:03:08]I also at one point got a license plate that said Django, which in 2012 was easily mistakable for a certain Quinton Tarantino movie.

[00:03:21]And one summer on a hot day in Detroit, Michigan, I was sitting at a red light.

[00:03:27]There we go. Got some Detroit love with my windows down and a police officer rolled up next to me. uh he's rumbling there on his motorcycle and leans down and just is cheesing ear to ear as he looks through the window and says, "I love the license play."

[00:03:43]Now, I kept it to myself that this was [snorts] technically about a Python web framework as I merely said, "Thanks back to him."

[00:03:54]So, I'm not new to open source software, nor am I new to being a little obsessed with my favorite framework. But as I was migrating my favorite tool from Django to Flutter, I couldn't help but notice something interesting. Because Django runs almost entirely on the power and goodwill of volunteers. And yet, nobody was concerned about whether or not Django was one day going to cease to exist. Like, will the next Django release happen more or less on time?

[00:04:23]Well, of course it will, was the opinion of the community. And Flutter has obviously never shared, never enjoyed this level of confidence.

[00:04:35]It's no secret that Google is a bottom-up company willing to start experiments and also a company willing to end experiments. So given Flutter's complexity and scope, people have wondered for years, wait a minute, what are we going to do if Google kills Flutter?

[00:04:56]So I think it's ironic that by having such a rich benefactor, Flutter has actually lost confidence in the court of public opinion uh despite the fact that that financial backing has just led to stable and consistent releases for 10 straight years. And this is not going to be a hot take. But I think the reason for that, of course, is that Google represents a single point of failure for Flutter. And no point of failure, no matter how stable at any one point in time, is comfortable if it is singularly loadbearing.

[00:05:29]So the Dart and Flutter teams have wondered for years how to [clears throat] address this problem. I can personally recall conversations that I had with various teammates on the Flutter team stretching back more than five years on how we're going to address this confidence gap. Everyone knew that something needed to change, but we were still looking for the right formula.

[00:05:50]But now in 2026, the urgency to act is undeniable. Flutter is the top multiplatform framework on GitHub. Every day, new contributors arrive at the repository, and with AI, they submit more pull requests than ever before.

[00:06:06]Zooming out, the amount of platforms that want to run our Flutter apps is constantly growing. I'm sure you've all heard how LG, who's here and has their own uh talk later, how LG is bringing web uh Flutter to webOS, how Toyota is putting it in their cars with automotive grade Linux, and even GE is using uh Flutter on toasters so we can see when our bagels are ready to eat. So if the Flutter and Dart teams don't adapt in this moment, then we'll cease to merely be the single point of failure that keeps you up at night and will instead also become the bottleneck through which Flutter stagnates and fails to live up to its potential. So we will be the reason that Flutter doesn't run everywhere. But I think it's also more complicated than merely like, "Oh no, AI is submitting more PRs than we can review." Even though that's true, Dart and Flutter have undergone tremendous growth in their last 10 years. And if you've ever been at a startup that gained traction, then you may have also seen what that can do to your internal structures.

[00:07:11]So, as I mentioned before I joined Google to start working on Flutter, I was employee number 19 at Zapier writing Django code. And four years later when I first saw stateful hot reload and thus obviously had to apply to Google to work on flutter uh zap year had grown to hundreds of employees [clears throat] and it had to reinvent itself uh countless times along the way.

[00:07:32]So by the time I left uh Zapier to join Google in 2019 the way we worked and the way we communicated with each other all the way back in 2015 was a distant memory.

[00:07:46]Now all of this orbits another quote that I think is relevant for us and that is that what got you here won't get you there. So to fully appreciate what got Flutter here, where we are now, where we want to go, and critically what it's going to take to get us there, I want to propose an evolutionary biology lens. A teammate of ours, Dako Harkus, dreamed up this analogy for a talk that he was giving earlier this year. And I think it's also fitting for our purposes.

[00:08:17][snorts] So go back in time with me if you will, billions of years to the dawn of life when Dart was born in 2011.

[00:08:29]Now, in its early DNA, Dart had some principles that have stood the test of time, like class-based inheritance and excellent developer tooling. It also had some principles that natural selection did not favor, like null ambiguity, or null danger, as I like to call it. But much like evolution pushes life into places where the sun's energy is going underutilized, I think human ingenuity pushes the frameworks and technologies that we use into places where developer friction still abounds. So what was this 2011 era friction that created the opportunity for Dart to arrive on the scene as a new species? Well, at that time, companies were struggling to deal with large single page web apps written in JavaScript. And it turns out that hundreds of thousands of lines of untyped code is a reliable source of developer friction. [snorts] So, multiple species evolved to address this opportunity. Within the JavaScript ecosystem alone, there was first coffees script, which didn't really last that long, and also, of course, TypeScript, which did. Outside of the JavaScript community, developers at uh Mozilla, Google, and Firefox started this other project called Wom to try to get entirely different languages to run on the browser. And of course, at Google, a team started a language called Dart.

[00:09:59]Now, evolutionarily speaking, at this point, Dart was just a single-sellled organism trying to remove developer friction and thus establish itself in an ecosystem of more mature species. So it was not everywhere yet, but it was willing to try. So you're saying there's a chance. One of my favorite movies. So how did this uh how did adoption go?

[00:10:21]Well, in the early days in the context of those single page web apps, Dart was fairly successful. So this vertical adoption scale is logarithmic. So this is a pretty good start. However, when Dart tried to venture out of its primordial soup, which is a lovely phrase, it quickly discovered that the rest of the world was not very friendly.

[00:10:42]So, for many years, Dart adoption stagnated and the rest of the world went with Typescript to solve the problems that Dart was positioned to address. And in 2015, Chrome closed the door on a possible future by announcing that they would not ultimately ship the Dart VM in their executable. And thus, Dart code would have to be compiled to JavaScript just like TypeScript was compiled to JavaScript. And with the dream of 10x startups and much faster runtime execution gone, Dart's optional type system was just kind of not quite enough of a lure to convince millions of JavaScript developers to rewrite billions of lines of JavaScript code.

[00:11:25]So in evolutionary terms, Dart at this point is stuck in a refugeium, which is a refuge environment outside of which the organism typically struggles to respond or struggles to survive. Also known as the opposite of being everywhere. And I think that this was the first existential moment for Dart that created an inflection point in what Google needed to do to uh see to the languages success. And if Google and the Dart team had not responded correctly at this time, I think it could have been the end of everything all the way back in 2015.

[00:12:01]Thankfully, Google had already committed to investment and evolving Dart's DNA.

[00:12:08]So, back in 2012, the team had added method cascades. In 2015, Dart added enums and async await. And then a year later in 2016, Dart added a strong mode which would later lead to a strict type system.

[00:12:22]However, in 2017, everything was about to change. So, in the natural world, one of the most consequential processes that can ever happen is when one cell engulfs another cell without metabolizing it. And that is called endo symbiosis. Both cells live on neither as parasite or host, but as symbiotic teammates. And if you've forgotten your high school biology, the most relevant instance of that for our purposes would be the mitochondria in our cells. They're kind of the power generators, the power factories. Uh they are how we have the energy to get up, walk around and and be human beings. So in Dart's case, that symbiotic teammate was of course Flutter. And in this analogy, Dart plays the role of the mitochondria. It is in the cell providing the power for everything to work. And that power is the VM and isolates that make 120 FPS rendering possible. And also as of this time, Dart had a new developer productivity trick up its sleeves. stateful hot reload. You some of you might have heard of that one. So, Flutter is the host cell. It knows how to interface with the hostile outside world. It knows how to handle packaging and bundling concerns on Android and iOS. It knows how to process user inputs and render pixels. It is uh the the kind of safe shell in which Dart can live. Of course, Dart can also live outside of Flutter. But this arrangement was very successful and adoption skyrocketed. So within a year, Dart usage had grown by almost an order of magnitude. Now, invigorated by this momentum, the Dart team kept going. In 2018, that strong mode was in fact upgraded to a fully sound type system.

[00:14:00]So I think you can think of this post 2017 era as another inflection point.

[00:14:06]Flutter has chosen Dart and now Google is not merely nurturing Dart to viability but instead supporting an ecosystem and you can tell that this is becoming an ecosystem because a high percentage of the innovation is coming from outside of Google. So year-over-year the ecosystem grows and this continues to shift Google's responsibility and I think this manifests in new behaviors like when Philip Praek surveyed all of the early days state management libraries and recommended provider which also ended up being a library that was used internally at Google extensively or when Brian Egan gave his famous keep it simple state talk at Dart 2018. And as an aside, there's something else really crazy about this screenshot other than the fact that I took it. There's 188,000 views on an unlisted video.

[00:15:01]Ryan, teach me your secrets, please.

[00:15:04]What is going on with this?

[00:15:07]But of course, Google did not pause on feature work for Dart and Flutter. over the next few years added multiple quality of life improvements to Dart and radically expanded the ways and places that you could run your Flutter apps.

[00:15:20]But there's something kind of interesting about some of those things I said radically expanded the ways and places you could run your Flutter apps.

[00:15:28]And that it was about to turn out was going to be an infinite task outside the scope of what even Google could deliver.

[00:15:36]Thankfully, the community, that's you all, were willing to take up the torch because you had enough fight in you. You wanted to see new ways and places to run your Flutter apps. So, Shorebird, who's also here, launched code push that delivered OTAA updates for us, allowed us to get updates and, you know, feature fixes or features and bug fixes [clears throat] into the hands of our developers much more quickly. Server Pod also here made backend development with Dart much easier. Removing the need to use another language. Uh and I I said what I said, removing the need. We should all be using full stack Dart. It's a lovely way to live.

[00:16:13]In 2022, Killian Schulta launched Jasper, a web framework designed to have a similar programming style to Flutter, but ultimately produce HTML. In time, Jasper would go on, in the Flutter team's opinion, to become the best answer to static site and SEO questions for Dart and Flutter developers. Now, those few things are adaptations and kind of supporting tools. But through this same window, Canonicle, the creators of Yubuntu, the Linux distribution, also started contributing to Flutter Desktop, eventually growing to become its steward and lead maintainer in 2026.

[00:16:48]Obviously also have mentioned LG, Toyota, uh GE, Samsung, others. There's companies out there in the world desperate to bring Flutter to their platforms. So these projects again I think represent yet another inflection point because if you thought that a lot of the innovation was coming from outside of Google before merely because most of the best packages come from the community wait till you factor in these projects.

[00:17:20]So at this point Dart and Flutter are not a mere ecosystem anymore. The intelligence and the innovation is just too distributed. And in the infallible opinion of Daco Hares, again the genius who came up with this analogy, Dart and Flutter are now a super organism like the super colony of Argentine ants that spreads uh covers most of California. I don't know if any of you have heard of this. If not, you've got to look it up.

[00:17:44]Did you know that the estimate is that for every person on the planet there is a million ants?

[00:17:51]I don't know what to do with that thought. And now neither do any of you.

[00:17:57]It's crazy.

[00:17:59]Anyway, the organizational needs of superorganisms are dramatically greater than the organ than the organizational needs of anything that came before them.

[00:18:09]I already mentioned how I watched Zapier grow from 19 employees to several hundred, constantly being forced to reinvent itself internally along the way. Well, Dart and Flutter have grown to thousands of direct contributors around the world, tens of thousands of package authors, and as of our last measure, 2 million monthly active application developers. So, that places a tremendous amount of strain on our internal communication structures.

[00:18:39]Now, Conway's law, or more colloquially, the phrase you ship your org chart states that the software you ship necessarily reflects your company's internal structures. And in hindsight, this is somewhat obviously true because it's also a very funny comic. In hindsight, this is somewhat obviously true because if two teams don't talk to each other, then their products probably won't work well together. And if their products don't work well together, then customers using them will feel that and they'll feel the shadow of the meetings that didn't take place between those original teams. Now, most people think of Conway's law as an inevitably bad thing, like, "Oh man, I don't want to my org chart because my org chart's a mess." But you can actually flip this relationship on its head, pull an inverse Conway maneuver, which is just so delicious. What a well-n named thing.

[00:19:29]By merely examining the kind of software that you want to deliver and deciding to structure yourself internally in a way that reflects that.

[00:19:40]Doing this is called sociote techchnical congruence and is when, wait for it, your companies or your organization's internal structure matches your external specifications. So this is where I think we find ourselves in 2026 as Dart, Flutter, Google, and the whole community trying to scale ourselves to superorganism levels while maintaining symmetry between our operations and our outcomes. Now, folks across the team have been brainstorming how this is going to go for many years. But today, we are excited to share three new initiatives that we think will help Dart and Flutter scale to infinity and beyond. They are one a formalized contributor ladder, two a governance policy for organizations to attain ownership and autonomy over parts of the project and three a pluggable platform system that should reduce the friction required to bring flutter to a new platform. Now to tell you all about these mechanisms, I'm excited to finally be quiet and pass the stage to Loic.

[00:20:47][applause] Hello everybody.

[00:20:57]Uh, thanks Craig. So the first mechanism is called the Flutter contributor ladder. And though I'm going to tell you all about it, you can also read the details yourself at flutter.dev/go/contributor ladder. It is an excellent document written by Kate Loveit, who some of you may know as Pinks on GitHub.

[00:21:14]For years, the Flutter team has extended membership to individual contributors through a group called Flutter hackers.

[00:21:21]And while this granted right permissions, the system had drawbacks.

[00:21:25]There was no automation. Admission criteria was somewhat subjective and in the uh focus was almost exclusively on code contributions. Other valuable contributions like issue triage, issue reproduction, and writing documentation had no path to viable acknowledgement or appropriate acknowledgement. There are also problems just within code contributions. Specifically, the old system conflated reviewing code with landing code. And because the bar because the stakes are so high for landing code, uh the bar for entry for both kinds of contributions was also extraordinarily high.

[00:22:00]And the issue with limiting code contributions uh and and the issue with limiting code uh the issue with limiting contributions in the form of code review is that the Dart and Flutter teams for all of Google's investments are still finite. This hard cap on weekly hours from core team members meant that mentorship often went to the back of the line. Contributors thus had to arrive fully formed and extremely knowledgeable or somehow had to bootstrap themselves into deep expertise which is very difficult to do. Over several years this resulted in a sort of midlatter gap in Flutter's pool of contributors because the cliff between a beginner and a contributor was so steep and because our physical ability to offer the support that new contributors deserved was simply missing.

[00:22:48]These overlapping and self-reinforcing issues, the undervaluing of node of non-code contributions as well as the insufficient mentorship for new contributors have created a scenario where Google is quite clearly the bottleneck for landing community contributions. And if you've reviewed significant poll requests before from your co-workers, you know how timeconuming and draining that work can be.

[00:23:12]We'll get into the details shortly, but conceptually, the only real way out of this limitation is by having more people contribute meaningfully to the project.

[00:23:21]But since bugs in Flutter always result in a bad experience for your users and because those bugs also affect Google's own apps like Google Earth and Google Classroom, that is a scary proposition.

[00:23:32]But as you'll see, we're going to try to thread that needle.

[00:23:36]To address this, we're increasing the number of steps on the contributor's ladder. Before, the ladder looked like this with Flutter hackers being the only real step and everybody else below that.

[00:23:47]It wasn't really a ladder. It was more of a stepping stool. Moving forward, Flutter will recognize four distinct tiers of contributors.

[00:23:56]The first tier is contributor, which just like the name suggests is anybody that contributes to the project. There is no GitHub role associated with this tier. So you are genuinely a Flutter contributor if you file high-quality issues, help us triage or reproduce issues, write documentation, or certainly land code. If you do any of those things, I invite you to refer to yourself as a Flutter contributor.

[00:24:20]The second tier is reviewer, which comes with the GitHub role of triage that lets you close issues and reopen them, apply labels, and of course, review pore requests. Now, technically, anybody can review a pore request, of course.

[00:24:34]However, uh an approval from a reviewer counts as a necessary vote towards landing said porequ quest. And though reviewers can help approve pore request, they cannot actually merge them without approval was without approval from someone else higher up on the contributor's ladder.

[00:24:52]There's more interesting parts to reviewing code as well since right now there are more incoming pull requests than there are uh contributors uh that can review them in a timely manner.

[00:25:02]First, to echo what I said earlier, um reviewing a pore request is an incredible donation of your time and energy and makes you a valued uh contributor to Flutter. Second, if you want to level up your own knowledge in Flutter, a great way to do this is to serve as a firstline reviewer and then to wait until after subsequent reviews from more experienced engineers to see what discussions you may have missed.

[00:25:26]To reach the reviewer tier, a contributor will need a healthy track record in the last 12 months. Types of contributions that count include, but are not limited to, filing high-quality issues or reproducing a problem to help triage an issue or reviewing pull request or certainly having your own poll requests merged. And these c contributions should be of substantive complexity, which means that typoixes and variable renames won't count towards that tally.

[00:25:54]But of course, typo fixes are still important, so please keep on filing those poor requests.

[00:26:00]The third tier is committer, which comes with write permissions to the Flutter organization on GitHub. To achieve the status, a reviewer must complete the same actions, but at a much higher rate.

[00:26:11]The exact numbers here are still in flux as our goal is to incentivize deep expertise and not to burn tokens turnurning out poor requests. Committers can somewhat obviously commit code The fourth and final tier is maintainer which is reserved for members with responsibility on the project or deep domain expertise or full-time contributors or partners. The path from committer to maintainer is left intentionally ambiguous and up to the discretion of existing maintainers. But I expect that this will be a you know it when you see it kind of situation.

[00:26:46]We believe that this four-tiered system will help Flutter grow its leadership pool and help the project better incorporate the be the vast fill brilliance of its many contributors by creating a network of distributed trust.

[00:26:58]We hope to emerge more pull requests that a qualified engineer agrees not only works but does so without introducing bug or introducing technical debt.

[00:27:08]If all of this is making your eyes light up, then uh go search GitHub for issues that interest you and leave a comment stating your interest. The last thing you want to do after pouring your Saturday on a fix is to find out on Monday that someone else was just slightly ahead of you and landed a pore request before you did.

[00:27:27]Flutter used to use specific GitHub labels to indicate that an issue was beginner friendly. But in recent months, we found that those labels were catnip for AI bots. So unfortunately, we had to remove them. Some of the last issues that we applied those labels to received five AI contributions with just a few hours, far too many for us to be able to review.

[00:27:50]So instead, we recommend working on issues that affect your day-to-day experience when building Flutter applications.

[00:27:57]And so on this note, as you consider contributing, know that your human brain is responsible for understanding and signing off on every single line of your contribution. Flutter only merges in code that a human engineer has verified, and the first person in that chain is you, the author.

[00:28:15]You can certainly have AI agents help you write a pull request, of course, but ultimately it is your responsibility to read that code and understand exactly why it is the correct implementation.

[00:28:27]For more information on Flutter's AI contribution guidelines, please read the section on get the GitHub wiki on tree hygiene. And Kate Love's document includes much more detail about the contributor ladder, including rubric criteria for poll request. But I'll leave that riveting content as an exercise for the listener.

[00:28:46]So that's the contributor's ladder. But zooming out, Flutter is not only adding a system for individuals, but also whole organizations. If individuals can grow to take ownership of Flutter on a poll request by pull request basis, then we're exploring mechanisms by which organizations can do so on a feature by feature or even platform byplatform basis. Obviously, all contributors, be they individuals or organizations, need to verify alignment before diving into code. And that challenge is hard enough when you want to add a new widget to the framework. But imagine if you want to add something like multi-wind for desktop or even an entirely new platform to Flutter.

[00:29:26]But that is exactly what Canonicle is doing today. And their stewardship of Flutter Desktop means that the Flutter or now transcends Google. In some senses, it always did thanks to the thousands of contributors around the globe.

[00:29:39]However, Canonicle with full-time employees working on Flutter represents another hub of intelligence in the super organism. This raises interesting questions about how to avoid all the problems from Conway's law that Craig was talking about earlier. First, how do we set up Canonicle for success and give them uh access to information and design documents? Should Canonical send delegates to Google meetings or should Google send delegates to theirs? Should someone hold office hours? Second, who has final say on design decisions? Or put differently, can Googlers veto a canonical pore request or canonicle veto one of ours? Third, who's on the hook for fixes and what sort of SLAs's might we agree to?

[00:30:23]Fourth, what about tests and infrastructure? Google maintains a massive device lab to run Flutter's integration test. But what happens if Canonicle wants to double the number of desktop devices? Should those new devices live in Google's device lab? Or if they live in Canonicle's device lab, um how do we integrate everyone's testing infrastructures together?

[00:30:43]Fifth, how does the next Canonicle follow in the footsteps and foster a similar relationship with a Flutter project? So the arrangement may evolve over time, but here's where Canonicle and Google have settled so far. First, Justin McCandless, who some of you may know as the Flutter framework tech lead, and I meet bi-weekly with Canonicle to discuss design decisions, blockers, and overall progress. This allows both teams to stay in sync without putting too much burden on anyone's calendars.

[00:31:14]Second, no, Googlers cannot veto Canonicle's decisions on the Linux implementation. And for the inverse canonical inversing uh influencing uh Google Canonical is invited to present at flutters weekly-forum where design documents are shared and discussed.

[00:31:30]This forum is open to everyone at the reviewer tier and above on the contributors ladder. So if you reach that tier, you can personally join the dash forum for any topics that interest you and contribute to the direction of Flutter. If you're curious about this, you can learn more about the dash forum at this URL.

[00:31:48]Third, Canonical and Google are held to the same SLA. Priority zero issues uh should be fixed within weeks with status updates posted once a week and priority one issues should be addressed within a few months with status updates posted at least once a month. Fourth, for now, Google continues to own all of the testing infrastructure, but believe it or not, Canonicle also has robust infrastructure for Linux. We intend to add a bring your own infrastructure model to Flutter which will allow partners to test Flutter in a way that simply wasn't possible before.

[00:32:21]And fifth, future Canonicles would rise to the same level of partnership the same way that Canonicle did by demonstrating investment through steady contributions. The contributors ladder is helpful for this as an organization with multiple committers on staff is likely a good candidate for increased ownership on the areas that they work on. Now those five questions presented unique challenges unique challenges but obviously they all had answers. However, there's another question that's a bit trickier and whose answer is much bigger in scope.

[00:32:52]In some senses, Canonical has taken over the simplest platforms that anyone outside of Google could take over. Not that the work on multi-wind is simple by any means, but rather that the footprints of the desktop platforms were already stamped throughout the Flutter codebase. This may suggest a hard question. How would someone bring Flutter to a new platform that's not already in the codebase?

[00:33:14]Consider this code that we've all seen at one point or another. If this code stings your nostrils a little bit, that might be a good thing. So, what's so bad about this? Well, what if LG wants to add a new target platform WeBoss Valley to this enum? And what if Toyota wants to add a new target platform automotive Linux? And what if Samsung wants to add a new target platform Tyson? Obviously, we don't want to keep extending this enum forever. So, something else has to give. And you might think, well, maybe I can use something like extension methods. Well, that doesn't work either.

[00:33:47]If Dart allowed consumers of an enome to staple on more variants, that would break anyone trying to exhaustively match on this enome like this unfortunate function.

[00:33:57]So, that's no help for new platforms either. For this reason, we're working hard on pluggable platforms, which moves all of this to an interface-based system. In the future, if you want to expand Flutter to your platform, you won't need to worry about landing changes to the core Flutter framework itself. Instead, you'll implement special classes which define the behaviors for your platform. When Flutter apps are compiled for your platform, they will automatically use your behavior implementations.

[00:34:25]Consider scrolling physics. The Flutter framework currently maintains several scrolling physics implementations like one for iOS and one for Android. Instead of a future platform needing to settle for one of these existing implementations or needing to contribute its own implementation directly to the core Flutter repository, instead it'll write a class which registered its desired behavior and the framework will be refactored to always use whatever is the registered implementation anytime scrolling is necessary.

[00:34:55]This is different from how video games support modding, for example. It will be limited to the touch points built into the framework, but additional systems can be made pluggable as needed. These interfaces will be covered by a strict breaking change policy so as to not break the platforms that build upon them. We'll take good care to design interfaces that will stand the test of time. Pluggable platforms will deliver major quality of life improvements for teams bringing Flutter to their platforms. First, they'll be able to develop everything in their own repositories instead of needing to land code in the Flutter repository itself.

[00:35:29]That also means that they get to own their own design decisions, their own test infrastructure, everything.

[00:35:36]Second, we hope to make the Flutter tool extensible. Today, if you play with LG's new Flutter SDK that they just released, you have to download a separate tool. In the future, the Flutter tool may be able to download the webOS bits for you directly. All of this should reduce or hopefully eliminate the need to maintain a fork of the Flutter repository, which is hard, thinkless work and makes it much more difficult to bring Flutter to new platforms.

[00:36:04]It's also worth contrasting pluggable platforms from governance. The reason that Google and Canonicle require such detailed arrangements is that Canonicle is working directly in the Flutter repository. So they require autonomy that no other organization other than Google has needed before.

[00:36:22]In the future, other teams may take ownership of certain features in the core Flutter framework as well and they will need to follow in Konicle's footsteps and need to work out a governance agreement. However, for teams following the pluggable platforms path, nothing like governance is required.

[00:36:37]It's your own repository. It's your own implementation. You can own everything and write whatever code you would like.

[00:36:44]Work on pluggable platforms is still in the early stages, but expect to hear more in 2027 and beyond. Now, back to Craig.

[00:36:52][applause] [applause] All right. Well said.

[00:37:03]So, once upon a time, Flutter Yeah, we're back. Get your science books open.

[00:37:11]Flutter was once upon a time just a pie in the sky experiment. Literally called Sky to see if the Oh, they just finished to see if the internet could be made smarter, faster, and more efficient. But before long, the folks working on Flutter accepted that to realize most of the gains and the performance improvements they were going for, they were going to have to accept a clean break from existing web technologies.

[00:37:37]Now, this opened the door for Flutter to choose Dart as its language and opened the door for a big flat canvas being the broad architectural decision. So essentially this is what unlocked Flutter's potential and the rest of the world has noticed that potential from the dozens of uh companies betting allin on Flutter to the increasing list of platforms the tens of thousands of package developers to the millions of application developers.

[00:38:07]So through all these eras that we talked about, I think that Flutter and Dart have genuinely benefited from the singular vision that Google provided.

[00:38:18]Just to take one example in Dart and Flutter packaging and distribution stories are much easier and more straightforward than they are in many other distributed technologies. Like getting your Dart code running on someone else's computer is way easier than in some other languages. But now that we're in our superorganism era, I think we've outgrown anything resembling a singular vision, not even something that Google could provide. In some senses, Flutter has always been open. At least we're committed to thinking it has because this is what we've been telling ourselves for a handful of years. It's one of the five pillars that we've been celebrating. But we hope with these three changes to deliver on that ideal in a new way. We want to bring in fresh minds, deeper expertise and broader opinions to make sure that Flutter benefits from everyone who wants to help the project. And we are already seeing some exciting success stories. Samsung has landed performance improvements for uh OpenGL Impeller and both LG and Comcast were interested in memory uh texture compression to have reduced memory usage and they submitted a design document that Brandon D. Roger, who's also here and has a talk later, is uh he's the mastermind behind the the 3D demos that we've all seen over the years. He was able to implement for them.

[00:39:38]So, in closing, Google's support for Flutter is not going anywhere, but we hope that in the future, Google support can be better complemented by the support of others. Now, we've [clears throat] said for years that our goal is to have Flutter run anywhere a device paints pixels. And with governance, pluggable platforms, and the Flutter contributor ladder, we're going to get there. Thanks so much, everybody, and enjoy the rest of Flutter Con.

[00:40:08]>> [applause]