Has there been any consideration of possibly spinning the Flutter project out of Google and into a non-profit foundation?

I think right now the biggest thing holding Flutter back isn’t technological, but rather the stigma that is attached to Google’s history of abandoning products. I understand that it is in widespread use in important products from Google and other major companies, but nearly every time Flutter comes up both here and on Reddit a significant number of comments are concerns about Google’s long-term commitment.

I agree that this is a common concern with Google products, but I can't help but wonder if spinning Flutter out of Google would just end up being a vindication of those concerns rather than mitigation. If tomorrow Google came out and said that Flutter was being moved from Google ownership into a non-profit, I'm struggling to imagine that the community response would be "oh good, this shows that Google has a long-term commitment to Flutter" rather than people more cynically viewing it as yet another instance of Google shutting down a product, just with an attempt to avoid the PR repercussions. If Google really does care about it in the long term, I'm not really sure there's any way to win the debate about their stewardship, so they might as well just keep their heads down and focus on continuing work on it, and maybe someday if they do that long enough they might be able to win some trust back.

it's a hard problem, because when Google cares it might not be good for users of the various projects/tools/languages. these projects has specific goals (that serve Google's high-level goals in various ways) and circumstances (which many times lead to significantly different engineering trade-offs).

Google starts projects with a lot of initial investment (new language/compiler/toolset/SDK/std-lib/frontend-component-library), but then their boldness almost disappears, and it takes a lot of time for them to finally catch-up, and on top of that they usually take a long time to "care" about things important for users (non-google developers).

for their care/support/long-term-commitment to matter, first they (would) need to position themselves as downstream users of Flutter, and for that they first need to transform leadership into a community-driven something.

My understanding is there has been a lot of discussion about this. It's not something I'm actively pushing for.

One of the things I'm excited for with Shorebird is creating an economic entity whose purpose is moving Flutter forward. We're pretty early in our journey, but I would love to see us grow to be "the flutter company" over time.

I think it's still a little early to try and spin Flutter out as a non-profit, but I suspect as more companies contribute to Flutter something like that will happen.

I think your Flutter knowledge is really very out of date. They rewrote a rendering engine from the ground up and released it about a year ago and a lot of the problems you describe are no longer the case.

Any iPhone App that I can try to see how the performance is these days? I remember Google Wallet app was horrible performance wise about two years ago

Wonderous is an app we've pointed people to in the past. I believe the current iOS release on the App Store uses the newer Impeller rendering engine instead of Skia, but I could be wrong.

App Store: https://apps.apple.com/us/app/wonderous/id1612491897

Code: https://github.com/gskinnerTeam/flutter-wonderous-app

(Disclaimer: I work on Flutter)

This indeed runs much smoother than most Flutter apps I've used in the past!

If it was indeed all just due to the slow rendering engine, hopefully this will sift down to other apps.

In the end I really don't care what framework a mobile app is developed with, as long as apps don't feel janky and/or out of place as far as platform UI conventions are concerned. In that sense, me not noticing that an app is using Flutter, React Native, maybe even webviews etc. is probably the ideal :)

But my experience as a user of apps leveraging technologies like this has often shown that reinventing so many layers of the UI rendering stack inevitably leads to some form of "weirdness". Sometimes that's ok; sometimes the alternative would be even weirder, badly developed and maintained native apps. But I can't say I've ever loved using such an app for, and not despite, not being a native app. The React Native approach just seems like a better level to try platform abstraction at.

On the web, I still can't help but find "rendering text and UI elements to a canvas" incredibly weird. I could see that approach working for games, but for things that might as well be regular old web applications, there are just so many things that can go wrong... (Reader mode and password autofill come to mind, for example.)

I think that ultimately (and despite what they might claim) Flutter just isn't a web technology (it's not suitable for rendering to web). But that shouldn't necessarily take away from it as a technology for native app development. React Native is a little better at this (and actively on rendering better to the DOM), but it isn't great either.

I think that might have been true when the DOM was the only game in town. With the introduction of WebGPU support coming to the platform a lot of those arguments begin to fall apart pretty quickly.

> On the web, I still can't help but find "rendering text and UI elements to a canvas" incredibly weird.

Flutter's docs explicitly say [0] that it is not a tool for building websites, it's for web apps. If all you want is to render some text onto a canvas, look elsewhere.

[0]: https://docs.flutter.dev/platform-integration/web/faq#what-s...

But it still runs a loop like a game engine - 60 FPS? So when compared to native UI, it's like immediate vs retained mode, right?

Native iOS also has a loop, it’s literally called the run loop.

My music app is written in Flutter and I think the performance is pretty good. In fact I did some prototyping in SwiftUI before settling on Flutter and was having a hard time getting the same scroll performance on image grids in SwiftUI that I got in Flutter without even trying:

https://apps.apple.com/us/app/minimoon-music/id6478451132

Just tried Google Classroom on my iPhone Pro and animations are indeed choppy and scrolling feels weird

Without knowing what Flutter version Classroom was using before impeller was released and how active development is on Classroom at google its hard to say if they could easily upgrade to the latest version. Flutter has had a lot of breaking changes leading up to the impeller release so it's hard to say if they actually upgraded to the newest version although yeah it is bad that they haven't done it by now if they didn't and if they did upgrade to impeller and it's still slow that's also bad.

Here’s some apps I’ve written in flutter. I’ve been very happy with flutters jank-free-ness. Big props to flutter team.

https://apps.apple.com/us/app/heythere-local-group-chats/id1...

https://apps.apple.com/us/app/treehouse-capture-moments/id64...

https://apps.apple.com/us/app/bops-music-with-friends/id6467...

https://apps.apple.com/us/app/palace-workspace-for-creators/...

It still was when I last tried it a couple of weeks ago. Not sure if it was ever updated to the new rendering engine.

Why, because I can make an app that works on all platforms, seamlessly, and the apps on each platform do in fact have accessibility support. As the other commenter said, they have improved performance to a considerable degree. It's an alternative to React Native, not necessarily native development, and it's a great platform for such use cases.

This is amazing. Thank you very much for all you've done and are still doing. Flutter changed my life as a developer. I learned so much thanks to its culture of openess & embracing community contributions. I feel like it's something unseen in most other open-source projects of this scale - I'm speaking this as a person that contributes regularly & has been invited to #flutter-hackers a few months ago:)

I was at Fluttercon Berlin last year and I remember your talk where you said we need to build for the next 10 million developers who will use Flutter. Many tools that should exist for Flutter still don't exist. The fact that you did code push on Android & iOS is a great achievement (code push on desktop should be much easier to implement than iOS and it's only a matter of time for you) - but what's the next big thing you plan to accomplish at Shorebird?

Desktop is one of our most requested features: https://github.com/shorebirdtech/shorebird/issues/397

I suspect we still have many months of work to do for iOS and Android code push. Mostly a lot of features to build for larger customers.

After that, I'm not sure. We have a long list of ideas. Do you have particular needs around Flutter you'd like us to address?

I feel like the build system situation in Flutter is really unfortunate. For Android there's Gradle, for iOS/macOS there's Xcode (xcodebuild), CMake for Linux, some Visual Studio-something for Windows and so on. This causes problems at scale – reliable, incremental, cross-platform builds are very hard/impossible. Same goes for splitting the build work across multiple workers (aka remote build execution). I did some research on this and looks like Bazel is the tool designed to solve this kind of problems. Of course the cost of Bazel adoption is huge but at a certain scale it makes a lot of sense. As the number of huge Flutter codebases grows I think this problem will become more pervasive.

I read on flutter/flutter repo that Google has Bazel rules for Flutter, but they're internal and they're not interested in open-sourcing them.

I agree 100%. Flutter needs a real build system. Bazel could be that? Feels better than inventing a new one.

Google has Flutter and Dart rules, yes, but they were started so long ago (for Google AdWords, which uses Dart on the Web), and historically were very tied to internal Google oddities. If we went with Bazel, we'd just write new ones publicly.

Yes, IMHO the world doesn't need another build system. Bazel sounds great, and the mobile development community seems to be converging arond it as the go-to tool for huge apps, e.g. see rules_xcodeproj [0].

It'd be a lot of work, because no good Bazel rules for Dart exist (there is [0] which is old and unmaintained, although it was recently forked [2] by a Google engineer working on Flutter), and of course, no rules for Flutter exist as well. Another problem here is that a lot of flutter_tools [3] code assumes that Android project uses Gradle, and iOS project uses Xcode.

After some investigation, it looks that to change this situation one could either:

(1) reimplement flutter_tools in Bazel, or

(2a) contribute to flutter_tools to work with Bazel, or

(2b) fork flutter_tools to work with Bazel (like you forked the engine)

Each of these is quite a lot of work. I'm curious to hear what you think about this.

[0]: https://github.com/MobileNativeFoundation/rules_xcodeproj

[1]: https://github.com/cbracken/rules_dart

[2]: https://github.com/matanlurey/rules_dart

[3]: https://github.com/flutter/flutter/tree/master/packages/flut...

I'd probably start simpler. I'd just start with either cbracken or matan's rules and see if I could get some basic Flutter projects building nicely with Bazel. Then I'd look to see how it would make sense to integrate with Flutter tools.

I think there are still open questions as to what kinds of projects would want to use bazel. And if they do use bazel, what do they do for all the other services flutter_tools currently provides (like running on a device)? Inside Google they have different (bazel-specific) implementations for "run this app on an android device" so they don't use the `flutter` tool internally I don't think. I do think some of the internal bazel rules might call into `flutter` though? I'm not sure. Those are all question's I'd explore after having some working examples that I could stare at and decide if I liked the DX of them before proceeding further.

Fuchsia also has rules for flutter, though in GN - but it's closer to bazel than the rest. Also I think their "sdk" (for consuming) is using bazel.

Could write them for Buck2 and avoid the old bazelisms. But already need a jvm I guess so bazel is no harm.

What do you mean by bazelisms? Is it akin to bashisms? :-)

Just curious if you thought of other build systems outside of Bazel and if so which ones & why?

We have a pretty large (surface area) Flutter app. One of our concerns with Shorebird in evaluating it early on was lack of JIT for iOS. As you mentioned, your custom interpreter solves this problem. But I guess my question is, how well?

Do you have performance data for comparison between the interpreted runtime and the official runtime?

Edit: found this thread + comment which answered most of my questions. https://github.com/shorebirdtech/shorebird/issues/1871#issue...

How are these "code pushing" technologies holding up when it comes to security?

Apps loading and executing additional code at runtime (as opposed to e.g. gating behavior using feature flags fetched from the backend) just doesn't sound like a great idea, even if it might technically pass the various app stores' review guidelines.

YouTube, TikTok, FaceBook (and any large game) have code push. And of course every app that uses a WebView or any other OTA service.

I do think code push is hard to get right. I think that's one of the values hopefully Shorebird can provide, by offering an easy-to-use and easy-to-get-right solution that's accessible to teams who use Flutter, but don't have an extra 10 engineers to write their own code push solution.

I feel very aligned with the stores in that what I want are great apps for users. Having users stuck on buggy/broken apps is a pain not just for companies but also for the platforms and most importantly the users (including from a security perspective).

I do agree with a lot of these points!

But should we then maybe just stop the pretense of "app stores control every executable byte of code in the apps they distribute" in favor of "app stores do content moderation at the business level; what apps technically do is up to their developers"?

Maybe we could even have both models (immutable, signed bundles vs. very dynamic entry points ad-hoc fetching parts of their logic), with app stores indicating which one an app purports to follow.

We should.

TIL that self-updating mobile apps are a thing. It is quite surprising to me that the app store gatekeepers don't force all app changes through their vetting process! Has this always been the case, or is this a new development?

Every time you launch YouTube, or TikTok or Facebook, or any large game, (or any App with a WebView), yeah. https://docs.shorebird.dev/faq#does-shorebird-comply-with-pl... https://docs.shorebird.dev/faq#does-shorebird-comply-with-ap...

There are also various other commercial services offering code push. Even Microsoft has one: https://learn.microsoft.com/en-us/appcenter/distribution/ina...

The stores obviously can punish apps who break their terms (not just around updates), but code push is ubiquitous because so many apps need the ability to fix bugs w/o waiting for every single user to click "update" in a store.

I am very curious about this too. Wouldn't this allow you to remotely inject malware into an app? For my own, non-malicious, project, I'd love for this to work, but I don't want the app store gods to wreak vengeance on me.

UPDATE: I found this.

Examples of SDK-caused violations

Your app includes an SDK that downloads executable code, such as dex files or native code, from a source other than Google Play.

There are some limitations on what code push is allowed to do. Shorebird's docs[0] go over some of the details for the Play and App stores.

[0] https://docs.shorebird.dev/faq#does-shorebird-comply-with-pl...

Thanks! It doesn't seem like they address the specific policy I referenced. Hopefully, they if add it soon.

> It is quite surprising to me that the app store gatekeepers don't force all app changes through their vetting process!

It's be because they can't anyways, what about web pages, feature flags & server side rendered views? The review process is mostly there to not circumvent their payment process.

How is this App Store compliant? I’ve heard of people having apps rejected for including Expo’s OTA update feature.

We've seen 1000s of releases in the last year, and not had a single complaint about rejections. In general, Shorebird provides the tech, intended to help you comply with your obligations to these stores. There can be good actors and bad actors with any tech, but we're here to help the good actors, and using Shorebird to violate app stores is explicitly against our TOS.

The stores both have explicit language about updates being generally prohibited unless they use an interpreter or a VM, so long as they don't "significantly change" the functionality of the app. e.g. Apple's agreement: https://developer.apple.com/support/terms/apple-developer-pr... or Google's guidelines: https://support.google.com/googleplay/android-developer/answ...

Which we reference from our FAQs: https://docs.shorebird.dev/faq#does-shorebird-comply-with-pl... https://docs.shorebird.dev/faq#does-shorebird-comply-with-ap...

Apps written with a WebView obviously can self-update. Others (as you mention) have offered updater-related products for many years, including Microsoft: https://learn.microsoft.com/en-us/appcenter/distribution/ina... Large games ship their lua scripts down when you log in, etc. YouTube, Facebook, TikTok are all known to self-update. Self-updating seems to be pretty well established practice.

I had to read the github ticket to find out what "code push" actually meant, as it is quite the generic term. Makes me think of git.

Turns out it means, "out-of-store updates," a description which I immediately understood. I'd lead with that.

Yeah, we picked "code push" to start with as that seemed to be the common term for similar: https://github.com/microsoft/react-native-code-push

It's possible we'll end up with a more Flutter-focused name like "hot patching" or something at some point.

Hmm, hot patching (and code push) sound local and not particularly noteworthy.

Hi Eric, congrats for the launch!

I'm curious, do you recommend any E2E test framework for Flutter? The idea behind hot pushing is releasing more often, for which you become more confident if you have some testing involved.

I'll make a shameless plug for my product (you don't get an opportunity to reach out to the Flutter founder every day!). I waited till the page was out of the front page to avoid looking like I was riding your show hn.

We claim we have the best support for writing and running end-to-end tests for mobile apps, and Waldo stands out in terms of compatibility with hybrid frameworks like RN or Flutter (where Appium support is poor). How can you tap on a button if your test framework doesn't "see" it?

We are releasing a new offer to run local test scripts on cloud devices, which has many benefits: https://dash.readme.com/project/usewaldo/v2.0/docs/getting-s... . By any chance, if you want to know more, I'd be glad to offer additional credits and even honored to do a personal demo (this holds for all HNers!)! My email is in my profile.

Not a question but a prop, this is truly a great product built by a great team!

One day I hope to be able to truly do CD on mobile to avoid the annoying gatekeeping of the app stores, for sure Shorebird is the way!

Looks cool. Was just about to start a new project with react native, but I might just have to check out flutter again to give this a shot.

Will this work with state management libraries like Bloc, and libraries that depend on code generation like MobX?

And how about adding new (Dart-only) libraries in pubspec?

EDIT: Also, flavors.

Yes. Works with any Dart code (no restrictions whatsoever), including code generation. Also works with flavors.

about how much size does shorebird add to the app bundle?

Does this still run AOT built code at fully optimised native performance? Your FAQ's mention that the App & Play stores allow interpretted code to be downloaded, but not native code. So this reads to me that this solution might be running things closer to JIT debug mode than AOT release mode. Help me understand this please.

On iOS, the code that you've modified runs in an interpreter but code you haven't changed runs the existing fully optimized AOT code that's already in your app.

So Code Push would be best suited for bug fixes that you need an immediate fix for, with the regular App/Play Store best for feature releases?

That’s the intent, yes.

This service is straight up lying when it says that Remote Code Push is implemented as per Apple's guidelines. Apple expressly prohibits Remote Code Push and if your app is found doing this, it can be banned by Apple.

Here is the guideline from Apple for the same:

2.5.2: Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

Ref: https://developer.apple.com/app-store/review/guidelines/

Here is their stance on that: https://docs.shorebird.dev/faq#does-shorebird-comply-with-ap...

I'm very interested in this tech but have never used it. From the FAQ it seems like that while they need to deliver a compliant system (e.g. interpreted code, I guess), the author is on the hook for following the spirit of the rule.