I founded Flutter and led the team for almost a decade. One of the constant questions we got was would we support code push like the web/react native: https://github.com/flutter/flutter/issues/14330 I left Google about a year ago and set out to build a company around Flutter and decided to start with code push.
It took us a year to build. We had to build a new toolchain for Dart and a custom interpreter (for store compliance). But it works! Our beta has already been used by thousands of apps. Most (eventually all) of the code is open source on GitHub.
I’ll be around all day to answer Flutter and Shorebird questions. We run our company in the public on Discord and are happy to take questions there too. Would love to hear your thoughts.
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.
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.
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.
No, as a user of some Flutter apps I also find them incredibly janky and wouldn't want to see the technology adopted (in this state!) even if it wasn't made by Google.
As nice as it might be to app developers, why should I pay for that with noticeable worse performance? How do you even make a brand new iPhone Pro drop frames when scrolling!?
Other than that, as far as I can tell it reimplements the entire UI rendering stack for web apps (there seems to be an optional HTML backend, but rendering to a canvas seems to be the default). As somebody never having used it... why? Doesn't this break all accessibility and native UI compatibility that browsers are providing out of the box?
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?
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 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.
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...
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.
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).
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.
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.
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.
[0] https://docs.shorebird.dev/faq#does-shorebird-comply-with-pl...
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.
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.
Turns out it means, "out-of-store updates," a description which I immediately understood. I'd lead with that.
It's possible we'll end up with a more Flutter-focused name like "hot patching" or something at some point.
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.