cc @floitschG

also see
https://groups.google.com/forum/#!msg/flutter-dev/YwzItp1pxJo/7bFGDLvxBAAJ
I would be extremely excited about this.

I would think this would be fairly important because this is might be one of the only truly distinctive features of react native, and unfortunately some companies might consider this a dealbreaker.

Use cases

• critical bugs, especially on iOS, especially for VIPs or urgent, time sensitive situations, business critical, and/or users that can't use the app at all for some reason.
• More dynamic testing of features than staged rollouts
• this would be a nice touch preparing for Fuschia, and/or Chromebooks. there could be scenarios where flutter is "competing" with web apps not just pwas/Kotlin/Swift/React/Xamarin/other-junkier-hybrid solutions

In the epic battle that is Flutter vs React Native, code push is one hell of a tool (:
As an RN dev I can't stress enough the importance of this feature. Many will pass Flutter just because the absence of hot pushes. Once you get accustomed to quickly fix bug and push new features you can't go back.

compiling to javascript path will diminish the dart advantages right?
i found some native app used to be able to have code reload using Rollout.io but it was blocked by Apple: https://news.ycombinator.com/item?id=13817557
looking at this pattern, seems like flutter will not have a seamless code push feature like what we see on react native.
would love to get more insight to this feature possibilities from core maintainers (:

compiling to javascript path will diminish the dart advantages right?

What advantages are you talking about?

Codepush is very much needed. Love to see the over-the-air upgrade release possibility on Flutter.

we just had a live use case with a production app where we were getting lots of bad reviews for a feature that appeared to be slightly edge case (related to denying location permission in a use case that not every test account had ) but really wasn't.

a codepush feature could push critical fixes for users immediately rather than waiting for them to upgrade; for some reason it seems users are slow to upgrade sometimes :(

No hot code push support is a NO GO :-(

Looks like JavascriptCore may no longer be required for interpreted code: https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/?page=2

If the IOS ecosystem is a hindrance, why not implement on Android only for now? Something better than nothing and its a starting point.

Much appreciated for team to implement this feature ASAP.

We've built some basic prototypes here, but don't have anything really to share at this time. To do this really well will require some work in Dart's compiler toolchain. I would expect it to be many months before we will have much to share here. The team is currently focused on stabilization for 1.0.

All that said, we hear you. :) This is clearly a feature many people value and we're interested in providing functionality like this eventually.

"Code Push" support for Flutter could be the final nail in the coffin regarding React Native.

With all my love for RN and the RN community, being the game changer it is, it is no match for Flutter.
Flutter just nails it in any aspect (tooling, performance, language...).

After 1.0 hits and the community grows a little bit more + Code Push support = Can't see any reason to start a new mobile project with anything other the Flutter.

any progress on "Code Push" ??

How feasible would be to have a full .so replaced dynamically? The whole compiler toolchain, code shake etc shouldn't be steered to an arguably edge case that people may or may not benefit, given there will always be tickets at the top of the priority list.

I think there should be room for "sideloading" the full .so file, so the build from dart to machine code can still be exactly the same. A small but completely independent component could be assigned the following "minimum viable features": download .so and replace the originally shipped one with it, and restart app with the main launch intent.

Extra responsibilities: download assets, verify signatures and what not. Update flutter/dart/skia engines and what not.

It sounds to me like it violates iOS guidelines, but I'm really not a fan of anything interpreted anyway, or iOS in general. And I'd rather have it in Android than not having it at all, just because it's cool.

At least the download part seems doable now that we have some isolate work being allowed in the background, but it would be interesting to see how to swap the original .so with the downloaded one. Maybe an extra .so or java code could do that part, but it's going to be sitting at the code folder, not sure the app itself can modify it so probably it would need some tweaks so the flutter engine loads all app's .so from internal data?

Starting to revamp my companies app using flutter. However our key demand to have a hot update feature since we are still in beta and keep testing out new UIs and features rapidly. Would live to have this feature.

Any updates?
(I'll bet the feature is already done and will come as a suprise when 1.0 hits)
😁

up vote

There is only one reason to prevent us from using Flutter: Code push

If you guys can not support Code Push, is there a way to make a Parser to generate from some dictionaries (like json, xml...) to Flutter Widget? Is this impossible or a good idea?

I think at least the UI/View written in Dart can be downloaded via the network from the server.
For inspiration see how Qt Quick framework is doing it.

QtDD12 - Serving QML applications over the network - Jeremy Laine:

• Video
• Slides

expect it can be included in the coming 1.0 release!

Many of our customers will be using our Flutter app on a kiosk device behind strict firewalls that would prevent Google Store's app-update mechanisms. These customers will not whitelist the Play Store. We will ultimately have 100's of hardware devices with the Flutter app, and having a way to push updates to app while adhering to customer firewall restrictions would be amazing!

This is one of the most critical factors that I consider turning to RN halfway. I can't believe that this issue has passed four years by a team that claims it pursues user experience.

This is one of the most critical factors that I consider turning to RN halfway. I can't believe that this issue has passed four years by a team that claims it pursues user experience.

Have you checked out shorebird.dev ?

It's led by @eseidelGoogle himself and it seems to be ready for production on Android and iOS. I believe they already have existing customers who've published apps with the code-push support.

Could be worth looking into.

i need it

@rutvik110 Have you used this? If yes, how's the experience so far?

CodePush is the more important factor than others When Company chooses development framework. In China development efficiency is the first question

I'm no longer at Google (hence using @eseidel rather than my @eseidelGoogle account), but have built a solution for this issue in my new company: https://shorebird.dev.

Shorebird's "code push" allows developers to deploy fixes to Dart code directly to Flutter apps on end users’ devices. It takes < 5 minutes to integrate, requires no code changes to your app, and supports updating any Dart code in your app. We designed Shorebird specifically to comply with Apple and Google store policies without sacrificing performance (even after patching). It does not use Hot Reload (or Dart's JIT compiler), rather we had to build a special interpreter for Dart since store agreements require use of an interpreter for updates (https://docs.shorebird.dev/faq discusses more details).

I'm happy to answer any questions via our Github (almost all Shorebird source code is open and MIT + Apache 2 licensed): https://github.com/shorebirdtech/shorebird, or via our public Discord: https://discord.gg/shorebird, but out of respect for the wider Flutter project (and people's inboxes) I do not plan to reply to questions about Shorebird on this issue.

The current Google Flutter team should decide if they wish to keep this issue open. Thank you!

The essential reason why we choose open source project is that they are free. For nowadays, Code Push is almost essential feature to a production application. But shorebird is charged, which means flutter is not free to a current production application. It can hardly be believed that Goolge will allow its own product flutter to bypass its own Play Store, which means this issue can hardly be resolved. From a benefit perspective, unless flutter be stripped from Google or shorebird's developer find a new reliable way to makey money, flutter will never support Code Push and will never be a modern production-level and really open-source project.

unless flutter be stripped from Google or shorebird's developer find a new reliable way to makey money, flutter will never support Code Push and will never be a modern production-level and really open-source project.

That's a pretty narrow view. Flutter is already free and open-source, and there are over 1m apps built with Flutter. Isn't that production-ready enough for you? It’s not like they included code push as a feature and then hid it behind a paywall.

If you think it's essential and should be free and built-in, why not clone Flutter, build your own solution, and share it with us? Then we can self-host and push live code ourselves. Sounds easy enough, right?

The discussion here should be:

• Is it possible to push Dart code over the wire?
• What are the Flutter team's viewpoints on code push? If there were a proposed solution, would they recommend it or warn against it due to potential breaking changes and future compatibility risks?
• What are the security and stability implications of pushing code updates dynamically in Flutter with the current solutions?

I'd like to add that the people at Shorebird aren't the only ones working on a solution for Code Push / Over-the-air (OTA) updates. flutter_eval is another solution that takes a different approach. It also seems promising.

flutter will never support Code Push and will never be a modern production-level and really open-source project.

Open source doesn't mean "it has the features I want". It means the source code is available for you to view and modify. We have to remember that even though React Native is well known for OTA updates, it was not the react native team that added support for that feature. It was implemented and popularized by third parties (i.e. Expo and Microsoft Code Push). Flutter already seems to be going down a similar road with projects such as Shorebird and flutter_eval.

I think as long as the flutter team is willing to collaborate with people working on code push solutions, flutter has the potential to have just as good a solution if not better.

The essential reason why we choose open source project is that they are free. For nowadays, Code Push is almost essential feature to a production application. But shorebird is charged, which means flutter is not free to a current production application. It can hardly be believed that Goolge will allow its own product flutter to bypass its own Play Store, which means this issue can hardly be resolved. From a benefit perspective, unless flutter be stripped from Google or shorebird's developer find a new reliable way to makey money, flutter will never support Code Push and will never be a modern production-level and really open-source project.

This cannot be the reason the Flutter dev team won't do Code Push as of today. Because there are already plenty of alternative options to the play store.
Flutter apps can be compiled to APK files, and those files can be uploaded and shared in any way you want. You can:

1. Host the APK files on your own website and add a download button
2. Use an alternative platform such as F-Droid that already contains a bunch of flutter apps.
3. Host your files using something like mega.io or google drive, and then share a link to that as the download.
4. Host your releases right here on GitHub.
5. You can even make your app download its own updates and then install them when given the right permissions. A simple search results in loads of libraries that easily allow this https://pub.dev/packages?q=apk+installer.

The essential reason why we choose open source project is that they are free. For nowadays, Code Push is almost essential feature to a production application. But shorebird is charged, which means flutter is not free to a current production application. It can hardly be believed that Goolge will allow its own product flutter to bypass its own Play Store, which means this issue can hardly be resolved. From a benefit perspective, unless flutter be stripped from Google or shorebird's developer find a new reliable way to makey money, flutter will never support Code Push and will never be a modern production-level and really open-source project.

It appears that Shorebird can be self hosted, see #485 at the https://github.com/shorebirdtech/shorebird repository.

The Shorebird pricing is quite reasonable for the features and the community support it provides.

While I haven’t explored this specific feature request, there are many alternatives and solutions:

• dart_eval and flutter_eval.
• Conveyor which is designed for desktop applications (Can work outside of Flutter), it's an application packaging solution, that can package the application for all three platforms on any platform with different formats and the signing process is easier and usually will less expensive, support for different use cases, it requires payment for non-open source products, with fair pricing.
• flutter_code_push: seems to be no longer maintained or supported though it's still can be helpful.
• You could also develop a custom solution, it doesn't have to be complex, you can upload the Apk and instead of redownloading it from scratch every time you push an update, you could support delta updates. and then request from the user to install it, this suggestion works for Android.

The (Code Push / Hot Update) is not a standard feature in native Android iOS, or Desktop apps.

Similar issues are either non-existent or have not been pursued on the native platforms (e.g., Android, iOS, JVM) issue tracker.

For most use cases, the update feature in the app store (e.g., Google Play or Apple store) is enough, if you require updating the app very often it's usually a sign the app is still in an early state and not production-ready yet.

This is one of the most critical factors that I consider turning to RN halfway. I can't believe that this issue has passed four years by a team that claims it pursues user experience.

Both frameworks are quite different. For example, Skip and Compose Multiplatform offer different approaches to cross-platform development. Kotlin Multiplatform provides platform-specific access and code sharing, though it functions differently from Flutter. I briefly explored the Flutter source code and understood some of the decisions made by the Flutter Team.

For example, dynamic class loading and reflection are limited in Flutter due to complexities in the obfuscation and shrinking process, While GuardSquare has done great work for maintaining and developing ProGuard for 22 years, these features are easier to implement when the language itself supports them like in Dart, it's just as easy as passing --obfuscate argument.

Kotlin Multiplatform does not offer features like Hot Reload or Hot Restart, as KMP depends on native targets (e.g., Android, JVM, Apple, Wasm) and usually the native platforms do not have it for compatibility reasons, Compose Multiplatform support previews in Fleet which is available to download without license or payment during the public preview, and it's still not quite like Jetpack Compose or Swift UI.

The Other alternatives like the ones in JS (e.g., Electron) are different too, I tried some of them like
Tauri, it seems they depend on the System-embedded web view,
which makes it easier to implement the Auto-update feature. In general JavaScript modules are usually dynamically typed.

As so many people require this code-push feature and Google will definitely not permit this feature for the sake of business benefit, and also Shorebird has refused self-hosting code-push solution ( #485 ) as expected, how about we do a crowdfunding to hire some professional programmers to implement this feature in a separate repo. If one give 100 dollars, only 10 thousands persons can crowdfund 1 million dollars, and I suppose it can be implemented in several months. Corporations can give more money, you can apply for money from your corporation and it will generally approve this. If you guys agree with this plan, we can start to do it. Flutter is not a vendor-neutral software, it is backed by android Google that will never allow Flutter bypass its Google Play. So only we ourselves can help ourselves.

We can talk about this plan at 1

2024 but issue can't be close

2024 but issue can't be close

i agree with flutter team ,code-push should be outside the flutter/core

infact flutter is too bloated ,with material-design components ,which takes 300K LOC while rest whole flutter is 500K ,hence a huge bloat

Any update??

2025 Q1 is almost over. How is the hot update of Flutter now? Does anyone still care about this topic?
In 2024, React Native is surging after Hermes & Fabric system went public. The performance of Flutter will not be an irreplaceable feature today. Flutter has to integrate this feature to defend its ecosystem. But apparently, Google is tired of copying with AGI competing and can't give enough attention to Flutter.

Although commercial, I think the best way forward is just to use shorebird, it's definitely production ready, and we use it to deliver thousands of patches every week.