Code Push / Hot Update / out of band updates

This is currently not on Flutter's roadmap, for reasons discussed in these comments: https://github.com/flutter/flutter/issues/14330#issuecomment-1279484739, https://github.com/flutter/flutter/issues/14330#issuecomment-485565194
This comment also gives a brief overview of the various kinds of "hot update" features that you might be thinking about, and gives terminology for referring to them, which can help if you wish to communicate unambiguously about this topic: https://github.com/flutter/flutter/issues/14330#issuecomment-442274897

Often people ask if Flutter supports "code push" or "hot update" or other similar names for pushing out-of-store updates to apps.
Currently we do not offer such a solution out of the box, but the primary blockers are not technological.  Flutter supports just in time (JIT) or interpreter based execution on both Android and iOS devices.  Currently we remove these libraries during --release builds, however we could easily include them.
The primary blockers to this feature resolve around current quirks of the iOS ecosystem which may require apps to use JavaScript for this kind of over-the-air-updates functionality.  Thankfully Dart supports compiling to JavaScript and so one could imagine several ways in which one compile parts of ones application to JavaScript instead of Dart and thus allows replacement of or augmentation with those parts in deployed binaries.
This bug tracks adding some supported solution like this.  I'll dupe all the other reports here.

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 the only truly standout feature of react native as far as I can see, 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 will 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 = No 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 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.

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?

This sounds a bit promising. Firebase remote config to widget if needed.
Although getting companies to have an idea what they want also helps :)
On Fri, Oct 12, 2018, 3:45 AM Hưng Lương Đỗ Minh<EMAIL_ADDRESS>wrote:

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?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

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!

Progress continues.  No updates to share at this time.

We came up with three clear terms for what people have been lumping into this bug earlier today:

"Dynamic patching": the ability to update the Dart code of an app in the field by downloading a patch (of sorts) and providing it to the Dart VM. This would require a reload of the app to take effect.
"Dynamic extension loading": the ability to download some Dart code that wasn't written when the app was first published, which adds a new feature to the app. This could be done on the fly. It may require the core app to be larger since we can't know ahead of time what is needed by each future extension.
"Modular application delivery": the ability to package a single app into multiple separate archives when compiling it, and download them independently as needed.

We should probably split this issue into three bugs that we can track separately.

Is this really feasible? Apart from the possibility of Apple banning this just like they did with rollout.io, the javascript would have to run without any kind of JIT (no writing to executable pages on iOS).

What Apple does/does not allow currently (or in the future) is wholly separate from the technical implementations.  Flutter runs in a lot of places other than iOS.  Obviously we would like to always design technologies which can work on iOS (as I believe many possible "code push" solutions could), but iOS is not the only consideration.  Hope that helps?

Really sad not to see Code Push released in 1.0. Like others this is the main reason I can't use it on projects that require the ability to patch without waiting for the app stores.
I appreciate that it's a heavy lift to get there, best of luck.

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

Would like to leave my feedback just to show my interest on this topic.
My company develops an android-only multi-customer app to manage maintenance teams. In 2018 we released approx 100 updates, none of which has requested a new version through Google Play since most of them are little tweaks and customizations that each customer requires, that are unpredictable beforehand.
Rewriting this app in Flutter would be a dream, but aside the rewriting costs, wasting money to wait for a fix or customizations to be published through GPlay would be a nightmare.

Hope to achieve as soon as possible

Another point: If the Flutter team provides the hot-fix solution officially, I think the Apple may reject all Apps built by Flutter, because hot-fix breaks the AppStore Review Guideline definitely, the developers can bypass AppStore review and modify their app, it is unsafe to users.
Currently Apple reject all apps with JsPatch, which was the most popular hot-fix solution in China. JsPatch is built on top of JsCore and OC runtime.

@MaxZeng Nice to know about JsPatch. But for now, it seems like hot patching is allowed. There are many React Native apps in Apple's store and they all use hot patching via CodePush.

If only iOS/android support such as
**MyFlutterApplication** asks permission/wants to update your app

**Allow** | Don't allow

after reviewing the guidelines for both parties.

@MaxZeng Nice to know about JsPatch. But for now, it seems like hot patching is allowed. There are many React Native apps in Apple's store and they all use hot patching via CodePush.

Yes, ReactNative is an exception of code push for now, but it does't not means Apple support it officially. Our company's App is rejected by AppStore for 3 times recently due to RN liked framework, and we have to rewrite these function back to OC or H5, it is nightmare for developers .
React Native is still a SAFE framework to Apple, because it is rendered on top of UIKit finally, but Flutter is a different, for example:
1、It breaks the Apple's developer ecosystems, It bypasses the UIKit, and it's out of Apple's control, for example there will be more and more MD Apps in AppStore, and it against the Apple's Human Interface Guideline.
2、If hot-reload is supported by Flutter officially, Apple may use this reason to reject Flutter Apps.
quoted from AppStore's Resolution Center:
"Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with App Store Review Guideline 2.5.2 and section 3.3.2 of the Apple Developer Program License Agreement.
This code, combined with a remote resource, can facilitate significant changes to your app’s behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes. This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior and/or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.
The next submission of this app may require a longer review time, and this app will not be eligible for an expedited review until this issue is resolved."

@MaxZeng Nice to know about JsPatch. But for now, it seems like hot patching is allowed. There are many React Native apps in Apple's store and they all use hot patching via CodePush.

Yes, ReactNative is an exception of code push for now, but it does't not means Apple support it officially. Our company's App is rejected by AppStore more than 3 times recently due to RN like framework, and we have to re-write these functions by OC or H5, it is nightmare for developers .
React Native is still a SAFE framework to Apple, because it is rendered on top of UIKit finally, but Flutter is completely different:
1、It breaks the Apple's developer ecosystems, It bypasses the UIKit framework, and it's out of Apple's control, for example there will be more and more MD style Apps in AppStore, and this may against the Apple's Human Interface Guideline. Apple is a famous company because of its great design.
2、If hot-reload is supported by Flutter officially, Apple may use this reason to reject Flutter Apps directly.
From my perspective, Flutter should follow the AppStore Review Guideline instead of breaking it, this is important for a cross-platform mobile framework, you should not break the ecosystem of Apple because we can do it. If Apple rejects Flutter, the key advantage of Flutter will be gone.
The CodePush is not a hard or mysterious technique, Apple can implement it easily, the only reason that Apples disallow it is that it is unsafe to end users, and this damages the AppStore/Google Play completely. It is a disaster if many apps can change their functionality anytime and anywhere, and it is hard to trace and limit these harmful actions after the App is allowed to publish.
CodePush is not just a technique, it is an important part of the mobile ecosystems. I think Flutter team should not provide such technique officially, although it may implemented by some developers privately, this is OK because it won't be used wildly.

@MaxZeng Nice to know about JsPatch. But for now, it seems like hot patching is allowed. There are many React Native apps in Apple's store and they all use hot patching via CodePush.

Yes, ReactNative is an exception of code push for now, but it does't not means that Apple supports it officially. Our company's App is rejected by AppStore more than 3 times recently due to RN like framework, and we have to re-write these functions by OC/H5, it is nightmare for developers .
React Native is still a SAFE framework to Apple, because it is rendered on top of UIKit finally, but Flutter is completely different:
1、Firstly, It breaks the Apple's developer ecosystems, It bypasses the UIKit framework, and it's OUT of Apple's control, for example there will be more and more MD style Apps in AppStore, and this may against the Apple's Human Interface Guideline. Apple is a famous company because of its great design.
2、Secondly, if hot-reload is supported by Flutter officially, Apple may use this reason to reject Flutter Apps directly.
From my perspective, Flutter should follow the AppStore Review Guideline instead of breaking it, this is important for a cross-platform mobile framework, you should not break the ecosystem of Apple because we can do it. If Apple rejects Flutter, the key advantage of Flutter will be gone.
The CodePush is not a hard or mysterious technique, Apple can implement it easily (especially based on OC), the only reason that Apples disallow it is that it is unsafe to end users, and this damages the AppStore/Google Play completely. It is a disaster if many apps can change their functionality anytime and anywhere, and it is hard to trace and limit these harmful actions after the App is allowed to publish.
CodePush is not just a technique, it is an important part of the mobile ecosystems. I think Flutter team should not provide such technique officially, although it may implemented by some developers privately, this is OK because it won't be used wildly.

Very interesting point and sounds reasonable in some ways, but also have some mistakes.

Flutter also support Apple's Cupertino, MD is not the only chosen.
You may know the Unity in the Gaming area, Flutter's render system works similarly in some ways.
In fact and for now, using the web(JS) can implement the CodePush and bypass AppStore's review to modify their app. So why reject Flutter(dart) and let off JS.

So why reject Flutter(dart) and let off JS.

JS runs in a sandbox and is therefore secure. (like every loaded web page in Safari)
Dart compiles to binary code and is not constrained by such a sandbox.

I am an android developer for many years.  I  think Code push is not so important.
If without Code Push, you can't develop?  If so, that's too foolish.
Flutter is a framework for mobile, so first at all you must learn more mobile develop knowlewdge.
Without Code push,you can use Full-update.
As the ad says: cross the bridge when one comes to it.
As an developer, i think it's more important to use different ways to solve the same problem.

@MaxZeng Perhaps flutter can enable hot update exclusively for Android.

Without hot update like RN, we won't be moving to Flutter! Frameworks should make a developer life easier!!

The flowers I waited for are all gone.

@MaxZeng Perhaps flutter can enable hot update exclusively for Android.

1、Actually it will damage the ecosystems of Google Play Store too, it will make Android team hard to control the App behaviors.
2、CodePush is not necessary for most Apps，this technology will be maliciously used by some developers.
3、It could cause large “Man In The Middle Attack” if developers do not encrypt patches correctly，malignant hackers may modify pushed-code to hijack Flutter Apps.

https://github.com/flutter/flutter/wiki/Roadmap

It seems that there is no plan to support CODE PUSH on IOS.

https://github.com/flutter/flutter/wiki/Roadmap

"The list here shouldn't be viewed either as exhaustive, nor a promise that we will complete all this work." :)
The code-push work is still in relatively early days of testing.  What platforms we will/will-not deploy that work to in 2019 is not yet determined.  It's only February after all.  10 months is a long time!
Currently engineers are focused on building out the core technology to support the 3 use-cases @Hixie outlined in: https://github.com/flutter/flutter/issues/14330#issuecomment-442274897
I expect we'll start doing some limited testing of at least one of those use cases in the coming months.

Because our flutter development technology is not very mature, the APP is frequently updated, and many are urgent updates. And our app doesn't plan to upload an app store. So this feature is very important. This can improve the iteration speed of the APP. Otherwise, the fragmentation of APP causes our api to be delayed.

As I think we can all agree, the driver of this issue is that delivering any mobile app to end-users via the walled-gardens managed by both Google and Apple (the stores), is a major inconvenience for app developers (not to mention poor service to end-users of good/innovative apps), Apple being the most inconvenient (days for Apple as opposed to hours for Google).
As a side-point, a possible solution could be if the stores provided a path for instant updates for 'trusted' developers (like a fast-track service). Google and Apple could then do a realtime audit (automated,... like with AI??... with auto-rollback post-facto as necessary) of the app. But this seems unlikely for a bunch of technical and other reasons. Both stores do of course have a fast-track to beta testers.
So... while waiting for the features in this issue, one way to alleviate the inconvenience involved in delivering any mobile app to end-users is to automate the steps.
For an example of a tool that does this kind of automation for Flutter see:
https://github.com/mmcc007/fledge
For the record, it includes documentation for many of the one-time setup-steps involved that cannot easily be automated:
https://mmcc007.github.io/fledge/
@charliezzo Using this tool, or tools like it, a Flutter app (and updates, etc..) can be delivered to android and ios beta testers within minutes.
It also has a workflow to automate delivery to end-users via stores (hours+ for Google, days+ for Apple 😂👍).

@mmcc007
oh,thank you. but i say i dont't want to push my app to google play and app store.
i need to sale my app in other way.
and i dont need google play and app store to update my app.
i only want to update my app by itself when users installed it and start it.
and ,flutter is a 60FPS or higher framework, it can make online game , we dont want to have a little patch by google play and app store.
you know every patch in a little time by google play and app store are slow and hard.
in fact you know we cant use google play in china . and app store is very slowly.

Code Push should be a primary feature in Flutter. Put it on top.

We can make it by replacing all the files in the app_flutters on Android

hi can you give me your email for further discussion，our team also found this solution， but it can work only when the application must  be killed and restart app。tks

hi can you give me your email for further discussion，our team also found this solution， but it can work only when the application must be killed and restart app。tks @LNeway

我也是跑了个demo验证可行性. 哈哈哈~

Please share with brief snippet or blog post or comment here or cc<EMAIL_ADDRESS>in the email...

@LNeway @KinsomyJS  Can either of you give further details please?
Thanks

@taibaiyinxing Flutter can not provide features that are disallowed by Apples App-store though.

@zoechi  Are you saying you and/or Flutter team has an analysis that concludes that a codepush technique feasible by Flutter is fundamentally different than one by React-native and is prohibited - and therefore, due to Apple, may never come to iPhone?

If this feature is added, will it be supporting beta 1.0.0?

@dahabdev

For what it's worth, from my experience with Ionic, I believe "code push" is overrated, and I hope the Flutter team doesn't spend too much time working on it while there are still so many other, basic, essential features missing.
Back when I developed UAVForecast, I used Ionic, attracted by the "ionic deploy" feature which offered to update the entire contents of the app remotely. Back then (this was 2014), Apple's App Store review times were on the order of 2 weeks. I wanted to iterate quickly, move fast, and break things, as they say.
At first "ionic deploy" was great, but soon, I noticed some major problems. It caused confusion for my users ("the app says it has updated itself, so why is there another update pending in the Play Store / App Store?"); it broke the app sometimes, e.g. when app metadata (e.g. permissions) were silently changed by a Cordova plugin but didn't get updated by a hot code push; tracking version numbers was tricky and they would get out of sync with what I'd pushed to the stores; it made me lazy about testing, since I could always "ionic deploy" myself out of bugs; and sometimes I ended up pushing worse bugs, ones that might have been caught by the app review teams had I given them a chance to look.
About a year after I released the first version, App Store review times had improved significantly. Today, it's down to just a few days, and of course on Google's Play Store it can be as little as a few hours. Given all the problems I'd had, I decided to remove "ionic deploy" functionality from my app, and with several million downloads now behind me, I haven't looked back.
While I like Ionic and really appreciate everything its developer, Drifty, has done (thank you!), I'd argue Drifty made the mistake of investing too much time into glossy features like code push which attract users, and not enough into getting the nuts and bolts of the framework right to avoid issues which end up driving them away. Now in its fourth version, Ionic has been rewritten so many times in backwards incompatible ways that I have stopped trying to keep up - the latest version still has several serious issues outstanding which prevent me upgrading, and I'm now rewriting my entire app in Flutter.
The experience so far has been excellent, and I'm having a lot of fun, but there are still some major gaps and omissions in Flutter, especially in the plugins. For example: there's no text field integration with password autofill, the Google Maps plugin is barebones (and there are related framework rendering bugs), the native WebView doesn't support file:// URLs for loading assets, the tab bar doesn't support transparency or gradient backgrounds, table cells don't support colspan, ThemeData is not extensible with app-specific colors to use with animation, the only fully timezone-aware DateTime library is lacking many important features of moment and moment-timezone, there are so many approaches to state management it is confusing for newcomers, you have to "flutter clean" frequently to avoid weird exceptions, hot-swap often doesn't work as it should, and I could go on...
I would rank all of these as more important than "code push", especially if it risks Apple rejecting Flutter apps, if it requires major changes to the compiler framework that could eventually make optimizations that improve app performance more difficult (I'd take a 5% performance improvement over "code push" any day), or takes time away from getting the framework feature complete.
On the other hand, I can see that some developers might genuinely need it in some situations, especially if they are operating outside of the stores, so I can understand the enthusiasm here.

@matthewlloyd lots of great points!

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?

--Does anyone have an opinion about this one?
https://pub.dartlang.org/packages/dynamic_widget
it appears promising, although it doesn't address the 'critical bug' fear.
That's the crazy part is that code push is the elephant in the room, that is deeply a business/process issue and a technical one, and one side tends to ignore the other...

there's no text field integration with password autofill, the Google Maps plugin is barebones (and there are related framework rendering bugs), the native WebView doesn't support file:// URLs for loading assets, the tab bar doesn't support transparency or gradient backgrounds, table cells don't support colspan, ThemeData is not extensible with app-specific colors to use with animation, the only fully timezone-aware DateTime library is lacking many important features of moment and moment-timezone, there are so many approaches to state management it is confusing for newcomers, you have to "flutter clean" frequently to avoid weird exceptions, hot-swap often doesn't work as it should, and I could go on...

Hopefully all of these already have Github issue :D

This was previously on our roadmap for 2019. After investigating this in greater detail, we have decided not to proceed with this work for now.
There were several factors that led us to this decision:

To comply with our understanding of store policies on Android and iOS, any solution would be limited to JIT code on Android and interpreted code on iOS. We are not confident that the performance characteristics of such a solution on iOS would reach the quality that we demand of our product. (In other words, "it would be too slow".)

There are some serious security concerns. Since these patches would essentially allow arbitrary code execution, they would be extremely attractive malware vectors. We could mitigate this by requiring that patches be signed using the same key as the original package, but this is error prone and any mistake would have serious consequences. This is, fundamentally, the same problem that has plagued platforms that allow execution of code from third-party sources. This problem could be mitigated by integrating with a platform update mechanism, but this defeats the purpose of an out-of-band patching mechanism.

There is currently no out-of-the-box open source hosting solution for patching applications, so we would either have to rely on people configuring their Web servers accordingly, or we would have to create integrations for proprietary third-party services, or we would have to create our own bespoke solution. Hosting patches is a space we are not eager to enter. Having people configure their own server leaves them open to making mistakes with potentially serious implications as explained in the previous point about security. Depending on third-party services puts Flutter in an awkward position of having to pick winners and exposes us to the risk of those projects themselves making policy changes that would affect this feature.

We prefer to spend our engineering effort on other issues for now. We expect to keep experimenting in this space and will probably become serious about this again in the future (for example, we will probably need an update solution for desktop applications), but probably not this year.

While I understand the reason behind dropping this feature, it is still disappointing. The Play Store and App Store are important considerations but not every app is distributed this way. For our use case, we supply the customer with both the device and and the app preinstalled. Having a mechanism to dynamically push updates to the user is a very important feature as we don't want to go through the stores. This feature would've been invaluable. I do hope it is revisited in the future as you mentioned.
Thank you for transparently communicating the team's rational.

@eseidelGoogle Will the JavaScript code that compiled from dart be able to use Skia to render pages?

This is quite disappointing.
Regarding all the security and store compliance issues you mentioned, they might be valid and legitimate, but at the end of the day there is an example of "hot updated" technology that is already working: code push.
React Native + the code push service works and proven itself in the real world. It's battle tested. There seem to be no problem with the app stores regarding the indirect updates. It seems everyone is "ok" with it.
The code push client library even addressed the "rollbacks" issue by adding a "retry" parameter.
Regarding the performance issues, it might be a good idea to let the developer choose to work in "low performance" mode but enable live updates.

A good move! I rather the engineering effort be spent on optimizing Flutter than adding a code-push feature that can overcomplicate and hurt the ecosystem

I am currently having my first ever app, developed in Flutter, in the open beta testing and I've pushed around some 10 app bundles with fixes. But it should be mostly error free when I release it to the production.
So I don't know if I will ever need this feature, but I found this pub package OTA Update that seems to be doing good on the score of 89, which is only brought down by its popularity. Is that package secure? It seems to be downloading APK from a URL and unpacking it natively and triggering the APK installation intent on Android.
Those who absolutely need this feature can try out that package.
But I can see why Flutter team isn't too excited about this, because, let's take the above package in case. It seems to be downloading from an URL. And a website is always more hacker-friendly than native apps. There are too many security concerns as of now. It just makes a Flutter app as vulnerable as a website which is a strict no-no.
I had a 2 GB RAM machine when I started out, trying to develop an Android App as I always wanted but my machine wasn't up to the task. I tried PhoneGap, Cordova, some Intel framework, React-Native, and none of them even started to run. Flutter was the only one who I got actually started with and with it's beautiful UI and development tools, it is miles ahead of its contemporaries even without this feature.

Any update?

App release workflow is never going to be the same after the way react-native spoiled us Code Push. Real shame that Flutter won't support it. Flutter is shaping up nicely and it could have been a competitor to React Native if they chose to support this feature. Alas...

@Hixie OK, so a fundamental engineering/technical change has too many downsides for now - that makes sense to me.
However - how do you feel about helping flutter devs that business concern in the short and medium term with some alternate approaches that get some documentation/discussion - perhaps even videos, while perhaps not an 'endorsed' or official solution, but some attention.
e.g.

Firebase real-time config
Server baased json->widgets (e.g. https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md or simlar, i don't endorse the exact plugin yet but the idea)
or perhaps something else, perhaps cloud functions for advanced users...
obviously I'm not suggesting you take a bunch of engineering effort for a 'big' use case, but sort of a hello-world-code-push-alternative that addresses most of the need without a 'let's fix/change every single thing' type architecture.

my  premise is that "we" can meet 70-90% of the concern for codepush without a fundamental architecture change for flutter; what does anyone think of this?
Flutter's code-as-ui approach might even make this easier than it would for android devs....
I've seen personally at least two companies that chose  the other guys over flutter just for this reason, and many others have spoken out similarly.
Maybe the conversation could go
"User: Are you skipping codepush support"
"Flutter team: Yes-for now, for these reasons, (as you did) but additionally, you could try A or B for some use cases"
Sorry for long comment

@neiljaywarner Perhaps LUA is worth a look for you - I did a proof of concept last year whereby LUA scripts could be used for creating/adjusting the functionality of a Flutter app.

@neiljaywarner I'm all in favour of that kind of approach, but that's an orthogonal concern than what this bug is covering.

虽然我理解放弃此功能背后的原因，但仍然令人失望。Play商店和App Store是重要的考虑因素，但不是每个应用都以这种方式分发。对于我们的用例，我们为客户提供预装的设备和应用程序。有一个动态推送更新给用户的机制是一个非常重要的功能，因为我们不想通过商店。这个功能非常宝贵。我希望将来如你所提到的那样重新审视。
感谢您透明地传达团队的理性。

我同意

code-push functionality means more apps, more clients, more developers, more tests, more bug fix, less issues

For a startup's MVP or growing applications, the updates or bugs fix is crucial, while performance are less concern most of the time. This will cause pros and cons to Flutter ecosystem. The decline of adoption, startups and personal developer are important for early stage community growth. The advantages might be the quality apps and teams that would switch to Flutter which aim for higher performance?

@maplerichie, Agree, the reason why I love flutter is the Developer Experience, performance, and cross-platform for all devices. I don't mind if code-push will not be implemented(maybe), It's for the sake of the reputation and popularity of the ecosystem.  Now I know why code-push seems too slow when using windows apps.(slow startup, delay of input and laggy animation) here

we are very need this function
很需要热更啊

As others before mentioned, big companies and large dev teams might not need hot updates. But think of a small startup, a couple of devs working on a mobile app, delivering features to production with quick release cycles. There no time for robust testing and QA cycles. Create a new feature, see if it works and users like it, replace or fix it. We could not get to where we are without hot updates. It's a game a real game changer for mobile development.

@yaronlevi I am a "small startup", even less than a couple of devs working on a mobile app, it's just me, and I deliver to production with quick release cycles. With the Google Play Store offering updates that take just a few hours, and Apple App Store reviewing updates almost always less than 24 hours in my experience these days, I for one definitely do not need code push. If Flutter had code push, I would actively take steps to make sure it was disabled in my app.

I am currently the sole developer of a mobile app (and the matching back-end) for a small company. I really love Flutter, but I have to constantly explain to a client who doesn't understand the need for unit tests or automation testing why it takes so long to implement functionalities that can be describe in 10 words. I am a little worried to have to release something half baked and not be able to push critical bug fixes quickly. I will do without for now, but code push would definitively be nice to have. However, I understand the technical challenges and security concerns and in the end I support a precautious approach.

well, thanks anyway.
I guess we need to figure it out by ourselves.

really disappointing :)

@matthewlloyd hi man it's necessary to support hot update, the point is not for the time to reviewing. User must be link to the AppStore and download the app again.

I don't really see much of an urgent problem with not having code push. Almost all users have auto update on on their app store. Providing an alternative solution for distributing updates without an App Store would be nice though.

Maybe help，MXFlutter uses JavaScript to implement Flutter's rendering capabilities, perfectly supporting the Flutter syntax, and perfectly supports code push and hot update.
https://github.com/TGIF-iMatrix/MXFlutter

@TGIF-iMatrix do you know whether this solution complies with Store's distribution policy?

@truongsinh
It's safe as it's a js distribution->native parser->compose widgets approach.

we'll consider use flutter if it supports code push

@TGIF-iMatrix It's highly likely that this would not be approved by Apple, as the exemption for Javascript Core updates has been axed from the App Store Agreements, and many CodePush users have been warned/denied because of that feature.

Maybe we should rephrase the question, "sever-dictated-rendering" vs "code push". "sever-dictated-rendering" is only about different UI/layout/theme, while code-push also implies change in logic, permission, plugins, etc.

Maybe, however at that point you can just use a plug-in to do that,so this kinda defeats the purpose of this issue.

Did anybody tried tinker-lib with flutter which is from tencent github repo and any success with that if anybody interested i can collaborate with you i tried it able to push update but small modifations are needed to load new code which should be done in flutter.jar artifact file

Hope to have a solution as soon as possible

Regarding the performance implications of implementing code push, would compiling Dart code to WebAssembly be of any help? This may allow implementing JIT compilation in iOS inside the JavaScript sandbox.

we need rapid iteration and agile development.
if no hot update ,flutter is always be a younger brother for react native.

Hot update is very important for us,if flutter support hot update,we will use flutter to subsitute for react native.

I had planned a best possible way for code push but due to time constraints i can only start this project from november last week or from december, i dont modify any engine code or framework code or any java code like tinker lib does so it doesnot violate any store terms, output app is also aot so no performance regression, i try to make it as easy implementation so that any one can plugin to their app, based on my research on code base flutter team is intentionally made impossible to make code push i tried all the possiblities with current implementation and concluded that only possible ways either you have to make engine modifications or prepare a solution without modifing engine, i go for 2nd option and planned all necessary requirements for the project. I hope project will suceed. In the mean time if flutter team will reasses the issue we all are happy with inbuilt implementation.

Hot Update will always be needed！

this is a must-have, a crucial functionality

I had planned a best possible way for code push but due to time constraints i can only start this project from november last week or from december, i dont modify any engine code or framework code or any java code like tinker lib does so it doesnot violate any store terms, output app is also aot so no performance regression, i try to make it as easy implementation so that any one can plugin to their app, based on my research on code base flutter team is intentionally made impossible to make code push i tried all the possiblities with current implementation and concluded that only possible ways either you have to make engine modifications or prepare a solution without modifing engine, i go for 2nd option and planned all necessary requirements for the project. I hope project will suceed. In the mean time if flutter team will reasses the issue we all are happy with inbuilt implementation.

I had planned a best possible way for code push but due to time constraints i can only start this project from november last week or from december, i dont modify any engine code or framework code or any java code like tinker lib does so it doesnot violate any store terms, output app is also aot so no performance regression, i try to make it as easy implementation so that any one can plugin to their app, based on my research on code base flutter team is intentionally made impossible to make code push i tried all the possiblities with current implementation and concluded that only possible ways either you have to make engine modifications or prepare a solution without modifing engine, i go for 2nd option and planned all necessary requirements for the project. I hope project will suceed. In the mean time if flutter team will reasses the issue we all are happy with inbuilt implementation.

Hi @canewsin
I also tried doing the same by not modifying the flutter engine. I found out that in the AOT mode, the engine looks for the .so files in the native library path of Android, modifying/adding a file in there after compilation of application is restricted by JVM. Hence loading .so files downloaded over the air couldn't be added to the native lib path.
Waiting for more insights from you. 😀

I think no need to update both dart code and native code.
Only dart code is fine!

Hey, I am in need for this now. Goodle has stricted their review policy. Our app takes 2 weeks to update now...
@NEELANSHSETHI can you post the plan here? We can start implementing it

@almeynman Please keep us up-to-date about your progress :)

@HerrNiklasRaab I have not started with this yet, as I don't have a clear picture on how to implement it. If anyone have any ideas, please share your thoughts

That's the main reason we haven't migrate from react-native to flutter. :(

😔

ReactNative is way ahead of Flutter because of this feature and I've had plenty of projects where the choice of environment (RN or Flutter) was decoded compared to the push code feature ! Waiting for a news :/

Hi all its November already as I said i started my work it's going well. It is gona be a private project, so i will charge a license key to use it. So it's not gona be free, since i don't have any source of income i have to do this way, if you are interested i will create a follow up repository about work, follow that for updates. Once i created the timeline repo i will inform you guys.

@eseidelGoogle
Business case:
We have a bus tracking app on tablets but customer update 1 time in the month because the tablet using internet data not wifi
With Code Push, we will be able to update without consuming the customer data too much

We had cordova app with code push support. When it came to modernize the app mistakenly we thought flutter would add code push support "anyways" so have developed our app using flutter. But life without code push has been totally terrible for the past year for us. So we're finally (and happily) in the process of (re) re-writing the app in react-native to have our code push support back.

Code Push, that's why I'm learning React-Native now.

If you are interested in my implementation
follow progress report here
https://github.com/canewsin/flutter-code-push-timeline
please read all my comments above before proceeding.

Code Push, that's why I still stay with React-Native.

Please don't post non-constructive posts, +1, "We need this", "We're using X instead", etc, as it isn't constructive and doesn't contribute to the discussion.
You will have a much better impact by clicking the Thumbs Up ( 👍 ) button on the first post, without everyone that has ever posted to this discussion will be notified about it (As far as I know, some members of the flutter team will mute large threads, so posting here has less effect than a thumbs up).
I also want to remind everyone subscribed here that github has an unsubscribe button on the top right of the thread.

Also, the Flutter team prioritizes issues based on number of thumbs ups, so getting that counter high can make a big deal. That and just clicking "subscribe" is enough.

Code push project i took up is going well but i want some examples of requirements of code push, so if code push is completed how do you use it post your unique requirement as a new issue in this repo https://github.com/canewsin/flutter-code-push-timeline so that development is on right track.
limitations i found so far are :
we cannot able to access native platform but this can be done via ffi functionality.
codepush code runs in a sandbox for some security concerns, so no harm can done to device.

Hi all its November already as I said i started my work it's going well. It is gona be a private project, so i will charge a license key to use it. So it's not gona be free, since i don't have any source of income i have to do this way, if you are interested i will create a follow up repository about work, follow that for updates. Once i created the timeline repo i will inform you guys.

Very interesting!
Hi, do you have any examples yet? And how you handle the iOS section? since Apple very strict in this area. Thanks

Hi all its November already as I said i started my work it's going well. It is gona be a private project, so i will charge a license key to use it. So it's not gona be free, since i don't have any source of income i have to do this way, if you are interested i will create a follow up repository about work, follow that for updates. Once i created the timeline repo i will inform you guys.

Very interesting!
Hi, do you have any examples yet? And how you handle the iOS section? since Apple very strict in this area. Thanks

currently working with android side, even though ios side is dumb one, similar to sandboxed version of reactnative js apps, code will run in sandbox without accessing platform apis so it may not be the problem when it will be ready for ios side.

Hi @eseidelGoogle
Any updates? Timeline?

Hi @eseidelGoogle
Any Updates? It's December is a feature that will be released in 2019?

I asked an AMA topic about this issue. May have helpful information.
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w?utm_source=share&utm_medium=web2x

@Hixie I read your article on Reddit [https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w/?utm_source=share&utm_medium=web2x](Reddit Post)
I wonder is Flutter app updates will be small size if I published it as abb "Android App Bundle" in Google Play or it is for native code only?

This is an important feature for Enterprise builds (apps that are distributed outside stores, for example through web portals)

It is very much required feature. Why can we not have it officially ? Whats preventing it from giving this feature ?

is this in 2020 roadmap?

No

2020 and still waiting

Please read this before posting below.
Here is a short recap if you don't want to scroll up in order to understand:
As was pointed out in this comment, the three big challenges are:

What is pushed
Is it safe for users
From where it is pushed

The first one, what is pushed, is where the biggest issue lies. Apple's review guidelines disallows any kind of code push whatsoever. Yes, the terminology used also includes javascript code push. Apple seemingly hasn't taken action against it, and there might be many reasons for that, but any reasons posted here would be pure speculation.
Google's own play store guidelines also forbid compiled code download, although it says that you cannot download executable code, it explicitly says "dex files or native code", so javascript might be safe, and pure dart source too.
Flutter, at least in release mode, is compiled, and even if it was not, is not javascript, therefore, it cannot be interpreted on iOS without breaking the "no JIT" requirement, or being very slow.
The second one, is it safe for users, is pretty much the entire rationale behind the stores' logic for disallowing dynamic, unchecked code download. Allowing anyone to download anything from anywhere and just running it puts users at risk. Even within a sandbox, where JavascriptCore's special privileges around code push are highlighted, it still isn't safe.
Code push allows you to bypass the verification process of the stores, which means unchecked code h runs on users' devices, which means that it is possible to either misrepresent the original app, or even to add harmful features such as data siphoning or exploits that the verification process would have caught.
You can have the best intentions in the world, there will always be someone to backstab you with them.
For now, on Android, if you're not using the play store to distribute, you can just build in a downloader that will fetch an apk and prompt the user to install it. On iOS, well, you effectively can't sideload without a ton of pain, and JB'd devices don't care about the app store's restrictions.
Now, is it possible to implement it for other platforms than iOS or Android? Sure! But Desktop is not in Beta yet (besides, you can also make your own autoupdater on desktop yourself), and, Web, well, just refresh the page.
Now, if you want the team to take a look, go to the first post and add a 👍.
If your comment falls into the list below, please reconsider posting it.

Asking when/if it is in the roadmap
"It's not there" (and variations, such as the previous comment to this one)
"We're using framework X because no code push"
"Framework X is better because code push"
"We need code push"
"Updates?"
Arguments for code push that are

Enterprise/Sideloaded apps
Emergency patching

Arguments against code push that are

The play/app store review durations are shorter now
The play/app store forbirds it
You don't need it

This issue is already charged with enough comments as is, so please do not add comments that add nothing to the conversation. If the team has something to say, they will post it here, as this post  has almost 100 participants right now, and over 500 thumbs, it's not possible to ignore it.

To be honest I don't think this should be your concern. A developer will use the feature at his/her own risk. If Apple suddenly decides to ban all the apps using code push, then your app will have to use a different approach. But this is not happening for JavaScript. It didn't happen for years, why should it happen for Flutter? They can't even check it. People are asking for this feature because it's useful. You can write small modules and update them dynamically. It's a game changer. You can fix a bug in a module on the fly. In addition, Apple can't really check what an app is doing, it doesn't have the resources. It would be impossible, I hope you realise it. Plus, what is the point? I can write obscure code and insert a backdoor in an application, triggered when I provide a specific JSON as result of a REST call. How Apple will be able to verify it? It can't. There is nothing Apple or Android can do to stop that. People need this feature, and you should implement it. What we do with it, it's our business, not yours. You said yourself, this feature has over 500 thumbs up and over 100 participants. Maybe it's time you implement it as per community request.

@dedalozzo Great fresh arguments!
I'm not part of the flutter team, so please don't target me in order to request implementations.
Still, it is true that Apple and Google might not have the resources to detect that (the play protect team is active all the time, they can detect dangerous behavior automatically), but implementing it "behind their backs" now gives Apple an actual reason to apply a blanket ban on Flutter, as it basically comes with tools that explicitly go against their policies.
You could also frame it as part of an ethical question (Should you implement something that adds additional risks to an app, and goes against store policies, in the name of progress?) or as a scheduling question (Should you work on something that has a massive "If you use this, it is likely you could get banned from the app/play store" clause, that users will probably want to avoid, and deviate resources away from other tasks with a safe, and guaranteed, impact?).
Not only that, but accidentally breaching play store policy/being related to someone who breaches play store policy basically means getting your account banned, so it would be playing with fire, making users even less likely to use the feature.
Plus, as stated above, distribution outside of the play store lets you push updated APKs.

I'm sorry, I thought you were one of the Flutter team.
What you say in your last comment is true. As a matter of fact, code push seems to be tolerated by Apple and Google, even it's borderline and against the rules.
But as long your application doesn't do any harm I don't think they will even bother to check if you are actually pushing code. They might, if someone reports a strange behaviour. But at that point they will take action against that app's developer, not the entire apps using push code.

Very much a work in progress, but enables code push https://github.com/chgibb/hydro-sdk

@chgibb Hold on... that enables code push but also changes the entire thing from Dart to Typescript?
Is there a way to separate those to things? To get codepush while writing Dart as usual?

@SpajicM that only works because it's not using Dart, instead, it uses a JS engine, such as JavascriptCore, which is owned by Apple, and they seem to look the other way when it is used with code push.

@miyoyo why is that specifically against store policy?

It is forbidden by store policy to push any kind of compiled code, of which .hc files seem to be, as they are compiled lua bytecode (maybe with extensions, haven't checked).
The specific use case of pushing compiled code to apps is explicitly against play store **policy**, and the "no source code provided" element that you could pass javascript as, in CodePush, would not apply, breaching Apple's guidelines.
I'm not saying the concept is bad, in fact, that's great work! It's just that downloading bytecode over the internet is explicitly against store policy in both cases.

How do all these mobile games with their in game updates work? Do they only push/download assets?

@miyoyo from Google Play's ploicy; https://play.google.com/about/privacy-security-deception/malicious-behavior/
...This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs...
Hydro-SDK's .hc files are pure Lua 5.2 bytecode with no extensions or special features. They are run in an interpreter with no functionality for self-mutation or code generation. Nothing from dart:io is exposed to them. Though, there is nothing stopping an embedder from exposing dart:io's File class, or exposing PlatformChannels for instance.
Apples section 2.5.2 is a little bit more ambiguous with respect to the meaning of the word "execute", as well as in changing features or functionality.
https://developer.apple.com/app-store/review/guidelines/#2.5.2
...
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,
...

@chgibb Okay, I'd say that might pass on Android, though I'd still expect a rejection on the App Store. (Not to say the reduction in peak performance, but that's probably a detail on high end phones)
@kuhnroyal Mobile game updates use either Dynamic Asset Delivery for non executable things, these are usually fast tracked because they require less verification, APK Expansion Files which lets you do partial upgrades, but are still subject to regular store update cycles, and regular APK updates.

Spoke with customer: headline that this is no longer a priority for them.

You can use Localizely for over-the-air updates of texts/translations: https://localizely.com/flutter-over-the-air

For flutter sake build this feature or guide us on how to build it. thank you .

For flutter sake build this feature or guide us on how to build it. thank you .

I'll literally second that point of @oussaki
It's a very important feature and needs to be prioritized if we want flutter apps on production and published on PlayStore and App Store.

Folks please, it's the third time this is posted, but Do not send comments unless you actually have something to add.
Consult this post for more details and to put a thumbs up on the first post.
Messages have no more impact, as I'm pretty sure most of the team here have disabled notifications for this post, let's keep the noise down unless you have something to add.

in the meanwhile any alternative for code push ?

in the meanwhile any alternative for code push ?

based on my experince, there is no alternative

in the meanwhile any alternative for code push ?

did you do any research before that ?
flutter is trying to improve performance of the application and adding code push to that will make it lose alot of performance
https://www.reddit.com/r/FlutterDev/comments/ccb30u/mxflutter_is_a_highperformance_flutter_dynamic/

in the meanwhile any alternative for code push ?

https://www.reddit.com/r/FlutterDev/comments/ccb30u/mxflutter_is_a_highperformance_flutter_dynamic/

@samerdernaika @mfenej please do some research before answering to a question or asking

o some research before answering to a question or askin

who are you?

@samerdernaika @mfenej while not quite production ready, this project was started with code push as an explicit goal https://github.com/chgibb/hydro-sdk

The first one, what is pushed, is where the biggest issue lies. Apple's review guidelines disallows any kind of code push whatsoever. Yes, the terminology used _also includes javascript code push. Apple seemingly hasn't taken action against it, and there might be many reasons for that, but any reasons posted here would be pure speculation.

That isn't true. Please double check and don't spread misinformation!
Section 3.3.2 of the Apple developer license agreement states:

3.3.2Except as set forth in the next paragraph, an Application may not download or install executable code.  Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS.

They very specifically permit interpreted code such as JS to be downloaded as long as you don't change the primary purpose of the application. It's been this way for over 5 years now IIRC and I've never heard of anybody getting yanked for using codepush in a normal and responsible manner.
Have a look at AppCenter's section about codepush and store guideline compliance. AppCenter codepush (backed by Microsoft) is used by loads of apps with no store compliance problems. https://github.com/microsoft/react-native-code-push#store-guideline-compliance
The big blocker to codepush that I see is that it may not be worth the performance tradeoff of being forced into using compile-to-js or interpreted Dart on iOS instead of precompiled. Since Flutter is targeting the browser however I suspect compile-to-js perf would be good enough, but maybe still not an acceptable performance tradeoff to the Flutter team.
Perhaps a third party solution (like AppCenter for React Native) will come along and fill this gap. CodePush is super useful!

Hmm, a quick Google search reveals many examples of Apple rejecting apps that include code push capability, see e.g.
https://github.com/microsoft/react-native-code-push/issues/1297
Given that App Store review times are now almost always measured in hours and not days, I don’t understand why anyone would take the risk.

@matthewlloyd you're absolutely right that review times have come down. I myself submitted a (proprietary) app to the App Store this morning and had it approved by the end of the day today! But that's recently. We, as publishers of mobile applications are still beholden to the whims/capacity of the review teams to review our submissions.
An update getting into your user's hands does not travel at the speed of app review. The time between "Developer Release", "App Store Processing", propagation to servers in your users market, etc can take quite some time as well. I've seen these later stages take more than 24 hours in extreme cases.
Speaking personally, my passion for code push is about taking ownership over the update delivery supply chain as it where. Not to mention the rather large hurdles involved in attempting to automate the current process into a coherent CD setup given the sorry state of xcode CLI tooling.

Less than 24 hours in the vast majority of cases is sufficient for almost everyone, I think. If you need to get an update through Apple's review process more quickly than that, e.g. for an urgent bug fix, you can request an expedited review. I have done that on one occasion, and the app review was complete literally 10 minutes after I made the request.
Taking ownership of the delivery supply chain is something one does at one's own peril...
Apple's App Store guidelines, section 2.5.2 (https://developer.apple.com/app-store/review/guidelines/#software-requirements):
"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 Application completely viewable and editable by the user."
Apple's developer program requirements, section 3.3.2:
3.3.2 Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

@AndrewMorsillo No matter what are in each guideline and no matter how much information is put forward, the best we can get upon is "It's maybe allowed we're not sure it's not a bannable offense actually it may be we're not sure".
Whatever the case may be, Flutter runs no interpreted dart on iOS right now, adding it would be a performance drag, and as you yourself have brought up, in addition to my previous posts and @matthewlloyd s post, it's at the very best barely allowed in some cases, in general it's a very very gray area, and at worst it's just banned.
As far as I can tell, trading all of that off for bypassing a 24 hour review cycle and writing tests is not worth it. (I could understand when it was a week, and that's usually only on iOS' side, which is effectively the biggest point of contention here)

It's not even just about the review process, it's also about users who get stuck on old versions of the app because they might have turned off the auto update.
Sure, you can implement the minimum version check yourself but then they again gotta go through Play Store and people are unfortunately, lazy. With code push, it could just quickly update the app on every run (I hope) and let user in more seamlessly.
@miyoyo I don't know why you're feeling the need of responding to every comment or idea that gets presented here. People want this. You guys told people to upvote the issue, and we upvoted it all the way to the top. This will never be solved unless someone actively thinks about it and pushes it.

There;s another way to solve this. I had seen lot of apps do so. App if out
of date, pop up a message, either you close it or update the app. that all.
On Fri, 7 Aug 2020 at 07:38, SpajicM<EMAIL_ADDRESS>wrote:

It's not even just about the review process, it's also about users who get
stuck on old versions of the app because they might have turned off the
auto update.
Sure, you can implement the minimum version check yourself but then they
again gotta go through Play Store and people are unfortunately, lazy. With
code push, it could just quickly update the app on every run (I hope) and
let user in more seamlessly.
@miyoyo https://github.com/miyoyo I don't know why you're feeling the
need of responding to every comment or idea that gets presented here.
People want this. You guys told people to upvote the issue, and we upvoted
it all the way to the top. This will never be solved unless someone
actively thinks about it and pushes it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

There;s another way to solve this. I had seen lot of apps do so. App if out of date, pop up a message, either you close it or update the app. that all.
…
On Fri, 7 Aug 2020 at 07:38, SpajicM @.***> wrote: It's not even just about the review process, it's also about users who get stuck on old versions of the app because they might have turned off the auto update. Sure, you can implement the minimum version check yourself but then they again gotta go through Play Store and people are unfortunately, lazy. With code push, it could just quickly update the app on every run (I hope) and let user in more seamlessly. @miyoyo https://github.com/miyoyo I don't know why you're feeling the need of responding to every comment or idea that gets presented here. People want this. You guys told people to upvote the issue, and we upvoted it all the way to the top. This will never be solved unless someone actively thinks about it and pushes it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14330 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

Probably the worst UX way... :/

@SpajicM

It's not even just about the review process, it's also about users who get stuck on old versions of the app because they might have turned off the auto update.

Sure, you can implement the minimum version check yourself but then they again gotta go through Play Store and people are unfortunately, lazy. With code push, it could just quickly update the app on every run (I hope) and let user in more seamlessly.

UX-wise, isn't this a bad way to handle updates? If someone manually disables auto-updates, why should Flutter override that? It's debatable if any app should even have that power, but certainly not the entire framework.
I think centralizing the update process through the app stores is better for UX since they can manage all updates through the store. UX at the expense of developer time is kinda the gist of app development. And if you need an immediate fix (eg, for a vulnerability), you can get an expedited update, or refuse to let the user use the app until it's updated. Of course the latter isn't a great option, and the former is annoying, but that's because Apple and Google are putting the users first, and has little to do with Flutter itself.
@chgibb

Speaking personally, my passion for code push is about taking ownership over the update delivery supply chain as it where.

This is kind of the problem with this thread -- trying to do what Apple and Google are strongly warning against isn't a good idea if you're going to be using their app stores. As @miyoyo said, it's a grey area at best, which isn't exactly fit for a framework used by Google and other companies/individuals.

Finally 🎉🎉 https://github.com/microsoft/react-native-code-push

Finally  https://github.com/flutter/code-push

It is acturally https://github.com/microsoft/react-native-code-push

Well Flutter still can't hot update your code, but actually that link talked about images and it reminded me that Firebase Remote Config is a thing. Downside is that you need to preempt which bits of code might need changing and expect those changes in your app, but once that's done it should be pretty quick to roll out new changes without the app store (similar to what React Native Code Push does with its images)

There;s another way to solve that
without use flutter web

There;s another way to solve this. I had seen lot of apps do so. App if out of date, pop up a message, either you close it or update the app. that all.
…
On Fri, 7 Aug 2020 at 07:38, SpajicM @.***> wrote: It's not even just about the review process, it's also about users who get stuck on old versions of the app because they might have turned off the auto update. Sure, you can implement the minimum version check yourself but then they again gotta go through Play Store and people are unfortunately, lazy. With code push, it could just quickly update the app on every run (I hope) and let user in more seamlessly. @miyoyo https://github.com/miyoyo I don't know why you're feeling the need of responding to every comment or idea that gets presented here. People want this. You guys told people to upvote the issue, and we upvoted it all the way to the top. This will never be solved unless someone actively thinks about it and pushes it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14330 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

That sounds great... if you're building banking apps.

Here is a sample Flutter app with Over-the-air translation updates: https://github.com/localizely/flutter-ota-sample-app

It seems apple's guidelines are different than they used to be?
This is still 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 Application completely viewable and editable by the user.

However, I can't find any other references to interpreted or executable code.
Is it possible the details about the apple ecosystem from original post are no longer true given that they no longer seem to say anything specifically about interpreted or compiled languages?

Many apps, including most games do this. In order to keep their app size lower than the minimum size allowed for download without wifi, many apps will download content dynamically and push updates without the need to push a new version to the AppStore.
Please bump this up!

You can keep assets in the cloud and download those no problem, this issue is about downloading code. I don't think games are downloading code when you launch them for the first time

What about using Firebase Remote Config?

Problem with remote config is that it's essentially a JSON of key-value pairs. Which means your code needs to expect any changes you might make and handle them nicely. This works great for when you just want to change some text or flip a boolean to change the UI, but this issue is about actually modifying the source code.
That being said, I'm still not convinced modifying source code should ever be done without using the app stores. My 2 main reasons are to 1) use a familiar system -- you should never surprise the user, no matter how convenient it is, and 2) consolidate moderation to the app stores, so that they have a way to protect users.

How about storing Javascript in remote config? And using something like this: https://pub.dev/packages/flutter_js, to run it? 🤷

That being said, I'm still not convinced modifying source code should ever be done without using the app stores. My 2 main reasons are to 1) use a familiar system -- you should never surprise the user, no matter how convenient it is, and 2) consolidate moderation to the app stores, so that they have a way to protect users.

I think the point still stands, which is that you're doing something that the user won't expect, and the OS has every right to think it's suspicious. You shouldn't have to act like malware if you're not. Users download, install, and update apps using the app store, so use that, and focus your attention on getting Google and Apple to have shorter review times. Phones don't like it when apps come from somewhere else, and will almost always warn the user of a possible virus.

@Levi-Lesches You are thinking from B2C perspective, but if we take from B2B perspective that becomes so much different. Imagine us, the company who provide cloud cash register to our clients using both Android and iOS devices. Our application is business-critical and for us, it's crucial to have an opportunity to instantly revert the version our clients are using or release a hotfix. With app store and google play reviews that can take hours, even days, while our clients are frustrated and unhappy with bugs we accidentally introduced in the latest version.
Imagine it from a modern web-app perspective. You release a new version, you have a semver enabled. You see there is a blocker in it. All you do is go to your server, revert one simple number, and now all the clients just need to hit refresh to get the free-bug version. Now, this is not going to happen if you use the app store or google play. While I understand concerns regarding Apple devices,  I believe support for Android devices should be quite simple here. You already can install any APK you want, so why we won't let it out of the box?

I'm already convinced that the feature would definitely be nice to have (I didn't consider B2B though, good point). I'm worried about the implementation. So far, the only way to do this on Android would be to download a new APK and install it. Even this warns the user a couple of times, but like you said, it's already possible. I believe this issue is about downloading new source code and running it as part of the existing app, which is not supported by either platform.
Again, I agree with your motivation, but if you find yourself essentially making malware (in the sense that it avoids the OS security measures), you have to question if there's a better way to go about it. Personally, I think the only reason for having this feature is that the app stores take too long to review -- fixing that would help a lot of people.

@SanjiKir would your company be interested in helping to build a solution to this problem? My approach to solving this is based on my experiences building B2B Flutter apps for enterprise health and safety.
https://github.com/hydro-sdk/

I don't have any company behind me, I'm just a 4y student who made a custom app and wants to share every update with a person.
Is there any workaround for this ? I read something about Firebase Remote Config but it doesn't seem to work really well.
Will this feature really be implemented (new labels added on Oct 1st) ? At least on Android ?

Downloading and running code is banned on both the Android and iOS app stores.
Apple's App Store Guidelines:

2.5 Software Requirements
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.

Google's Play Store Guidelines:

Device and Network Abuse
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play.

This issue is turning into a philosophical debate on whether we should prioritize the user experience, the developer experience, or the policies of Big Tech™. The bottom line doesn't change: if you choose to use the Apple App Store or the Google Play Store, you are bound to its terms. Until those terms change, no workaround should be created/endorsed.

@Levi-Lesches We already know about this case but there are other channels for example:
1-Business distribution for non-play store supported devices like a bus supervisor who uses a Chinese device to track school bus trip.
2-Other stores.
More on everyone will have different cases it doesn't have to be limited to my distribution channel.
Schools, Factories, etc

@Levi-Lesches Yes I could show a popup to inform the user about a new update but what about force update I would need to use MDM which cost $$$$dollars per each device.

@amorenew What do you mean by "non-play store supported devices"? An Android that doesn't use the play store? In any case, if you're not dealing with an app store, the best (easiest, fastest, cheapest) solution might just be to reinstall the app every time you have an update. I know some apps that are off the app store, and their way of "updating" is to just download a new APK. It's actually pretty convenient, and that way you don't jump through hoops. If you have a different use case, you might have to describe what devices you're using, how you're getting the app onto it, etc. for me to help. My post was directed to everyone using the app stores.

@Levi-Lesches dealing with users using non-GMS (Google Mobile Services) devices likely means that asking them to manually uninstall and reinstall your app is a non-starter.

I know some apps that are off the app store, and their way of "updating" is to just download a new APK.

What's wrong with this? Have a button in the app that downloads the latest APK from your servers and "execute" it (ie, getting Android to open and install it). I get that the device isn't "normal" Android, but you got the app on there somehow. Again, there is probably an official way to update/install apps and you should prefer to use that if you can.

Downloading and running code is banned on both the Android and iOS app stores.
Apple's App Store Guidelines:

2.5 Software Requirements
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.

Google's Play Store Guidelines:

Device and Network Abuse
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play.

This issue is turning into a philosophical debate on whether we should prioritize the user experience, the developer experience, or the policies of Big Tech™. The bottom line doesn't change: if you choose to use the Apple App Store or the Google Play Store, you are bound to its terms. Until those terms change, no workaround should be created/endorsed.

@Levi-Lesches I actually don't want my app to be on any store, as it's a custom "couple app".

iOS or Android? For Android, you have the simple solution of downloading the updated APK. For iOS... well, how are you even getting the app installed without using the App Store? I'm trying to figure out the same thing for my app.

Android only, and I'm trying to figure out a free way to do that

Well the good news is the user doesn't have to see where the APK comes from -- it's just like any other file. For one of my prototypes, I even used a public Google Drive file! If you want a more "professional" solution, you can use Firebase Cloud Storage, which would be free if you just use it at this small level. Alternatively, now that Flutter Web is getting better, you can make a website and host it for free using Firebase Hosting, which is what I'm doing for an app I made for a friend.

I found one good example from youtube. it shows a full loop for how to do code-push on Flutter with IOS app
https://www.youtube.com/watch?v=X9m2I92hOn0

I made a custom parser for the ui so we cand make custom widgets over the air , but we need this as offcial flutter feature
so its more like update the dart code over the network and all the basic functionality of the app not the pubspec packages

@Levi-Lesches App Stores guidelines are not relevant for this discussion, CodePush is more common/important for enterprise apps, when your users/employees download the app from a Web portal instead of the stores and you want to avoid binary downloads to improve the user experience :)

@jdnichollsc, how are your iOS users installing apps outside the app store? I'm desparately trying to figure out how to distribute an app to iOS users outside the app store. Right now I have an enducation private distribution set up for App Store Connect, but I'm also looking for a better way since it doesn't allow for updates.

Check more details here https://stackoverflow.com/a/44166783/1532821

https://twitter.com/tuzi_moe/status/1361168896691036164?s=21
see this

@tuzimoe will you be sharing more info on how it works?

@tuzimoe will you be sharing more info on how it works?

Sure! If u don't mind please email<EMAIL_ADDRESS>with your info. We would like to see if we can offer you a SDK for free.

@tuzimoe will you be sharing more info on how it works?

We make it by rewrite some of the compile part with Dart and it work fine with most of the dart flutter feature support with the stable channel. And it can code push by host your own compiled outcome file.

Any progress on this issue? It's been a while.

...we have concerns about abuse of Code Push now that Flutter and Pub packages are fully supported.

I think this is essentially the same conclusion the app stores reached. And as Flutter wants to be on the app stores, it doesn't seem likely this will ever be an official Flutter feature. Otherwise, like someone mentioned above, Apple and Google might blanket-ban all Flutter apps.

Oh, I see.

We are happy to share the open source version with community check it out!
https://github.com/Waytoon/chimera_flutter_code_push

it is a really good stuff!

We are happy to share the open source version with community check it out!
https://github.com/Waytoon/chimera_flutter_code_push

So good! Thanks for sharing!

Any improvement?
I'd expect something like this with Flutter 2 ...

Chimera flutter code push got new updating with enhancing compiler performance. Please check the link above for further info…

...we have concerns about abuse of Code Push now that Flutter and Pub packages are fully supported.

I think this is essentially the same conclusion the app stores reached. And as Flutter wants to be on the app stores, it doesn't seem likely this will ever be an official Flutter feature. Otherwise, like someone mentioned above, Apple and Google might blanket-ban all Flutter apps.

This is not the case actually, React Native Expo apps are able to do this already and they are not blanket banned.

I recently talked to my company about the revolutionary Flutter 2. They loved everything, but no OTA code push updates like RN was a deal breaker for them. Really hope something is done in this space. RN apps are already benefitting from this feature and they exist on both stores.

Did anyone try out @tuzimoe solution? I see downvotes on his comment, why?

Did anyone try out @tuzimoe solution? I see downvotes on his comment, why?

Hi, feel free to go through the demo and see,if u met any issue u can also raise issue. the downvote seems were from another solutions team member 😂

Hi i have work around for this issue we can use flutter web app to solve this issue due to web app not need compile to read new files but if you change anything in yaml file or write native code you will need to submit the app

@SpajicM The solution offered by @tuzimoe works (And good job with that), but is exactly what is against the stores' policies, the download of opaque executable binaries that change the behaviour of the app.
This is perfectly valid in third party stores and enterprise contexts however, but then again, in those contexts you'll have much less friction to push a new APK/IPA, reducing the utility, so it solves the "code push" problem, but it does not solve the problem solved by code push: bypassing the app stores' review processes.

what do people think of this ?
https://github.com/hydro-sdk/hydro-sdk

Flutter's not being able to code push is why I can't choose, working at start-up.
Early development requires a lot of errors to be fixed and deployed, and it is not a good idea to encourage customers to update.
For non-serious errors, an environment that can be developed with Code Push is bound to be an option.
I hope Flutter will be able to do Code Push as soon as possible.

Early development requires a lot of errors to be fixed and deployed, and it is not a good idea to encourage customers to update.

I hear this sort of sentiment a lot -- out of curiousity, what does your beta, A/B, preview, etc. look like? I thought that these system are exactly the solution to this problem: Have a smaller group of users that are okay with getting error-prone code and updating more frequently, and in exchange they get features faster and you ship more stable features to your larger user-base.
Obviously it's not a replacement for Code Push -- still gotta get those updates out somehow -- but it reduces the problem of getting users to update more frequently.

sounds like your talking about feature flags

Um... @Levi-Lesches You're right, but what I'm saying is that there's already an option that doesn't require Flutter. RN or Ionic
Flutter couldn't be a better option than these.
I'm talking about one case, but even major applications that have passed some time, Hot Fixing with Code Push comes with a lot of difference.
Actually, I wanted to use Flutter for this project, but I developed it with Ionic.

Any news? In our home automation project we plan to use Android wall tablets without Play Store on board. We need some custom solution to deploy and update our Flutter application.

@baurzhan If the wall tablets have a browser, Flutter Web and "Add to Home Screen" is one option that just works everywhere. Also self updates are simple cause the gui relies on the web server to load from.
Not everyone cup of Tea of course but flutter web notifications work now and its coming along quite well.

@gedw99 for notifications we have to use FCM? We do not plan to use Firebase in our project.

I got notifications working with just a test flutter web gui to fire a native desktop notification. It worked on web and Mac and iOS .
So I never tested the notification coming from a server.
mod course the whole point of GCN and other server based push notifications is to make it occur at the OS level so that the user clicks it and then it opens your app to bring it to life . So the last half I validated and it worked using the navigator 2.0.
So in summary it seems to work independent of GCN and so you just need to give it a try with whatever server you plan to use.
applyboy is the golang one I have used in the past but I think apple boy I der the hood uses FCM or Microsoft .
if you make it open lt me know

What is are you running on your wall tablets ?

Codepush now has first class support in Hydro-SDK. I'd appreciate any and all feedback
https://hydro-sdk.io/blog/fluttering-over-the-air/

Just to be clear.
Apple and Google stores don't allow CodePush functionality in apps, right?
But for instance, YouTube has a code push functionality. They literally sometimes change some up or break it without an update. So my question is: is it allowed for the big apps and not allowed for small apps? Like do I have to reach a MAU number then use those features legally in the stores? Or is it something not possible?
@chgibb Also is hydro-sdk app stores compliant?

I can't speak for Youtube.
From my understanding of the policies of both Play Store and App Store, apps using Hydro-SDK and codepush are allowed.
That being said, Hydro-SDK and codepush enable you to do things that are against policy. For example, introducing a major new feature without App Store review or exposing Android SDK APIs to code delivered over codepush.
Hydro-SDK and codepush themselves aren't explicitly violations of either Store's policies.

Apple and Google stores don't allow CodePush functionality in apps, right?

yes they do, and have for years. React Native and Cordova apps have been doing it for years through https://microsoft.github.io/code-push/ and other solutions.
Apple cares about what kind of changes you make - limiting where you make your changes and how much functionality you change when you do it. Google doesn't seem to care.

Lack of live updating capabilities is a gaping hole for Flutter; would love to see this filled.

Think about it guys, how is it even possible to live update except to use something interpreted alongside the native code in Flutter. You're using an amazing UI framework that generates native code with a completely native UI and you want the ability to hack it up so you can update it over the air. The Google team said it early on in the conversation, doing so would mean a complete overhaul of the framework and, due to losing the compiled native aspect of the apps you build today, nobody will be happy with the results. React Native can do this because it has a JavaScript interpreted layer already today. The Hydro SDK mentioned above hacks a Lua and TypeScript layer on top of flutter but that's an awful lot of work to go through to get this feature.

I think the real issue is not technical. I don't think Flutter supports importing external compiled libraries (think DLLs in Windows or *.so files in Linux) which I think could be an option (assuming other issues like supporting different architectures don't make it a support nightmare). The real difficulty I fear is security. If something is pushed to devices, it better be come from a legit source (signed, etc.). There are so many hacking cases based on infecting the "suplly chain". Also, would this be allowed by Google or Apple since it means an app could virtually bypass any validation and change from a legit app to something way more nefarious?

https://github.com/flutter/packages/pull/452
Rather, RFW is best suited for interfaces made out of prebuilt
components. For example, a database front-end could use this to
describe bespoke UIs for editing different types of objects in the
database. Message-of-the-day announcements could be built using this
mechanism. Search interfaces could use this mechanism for rich result
cards.

As @Sunbreak mentions, I've been working on a package that might address some (certainly not all) of the use cases that you may be interested in as someone subscribed to or reading this issue. I call this package "Remote Flutter Widgets" (rfw).
The intent of this package is just to provide a way to describe Flutter user interfaces (widget trees) in binary files that you can ship to your application after the application itself has been published. In this regard it is vaguely similar to markdown, but rather than being for text, it is optimized for widgets.
There's no logic in RFW files, so it isn't code push. It could, however, be combined with a package like wasm to provide remote logic as well. There is an example that provides a proof-of-concept for this combination of packages: a Flutter desktop application that knows nothing about being a calculator downloads an interface description specifying all the buttons and their layout to show on the screen, and downloads a C program compiled to Wasm to perform the calculations. The Flutter program is merely a bridge between these two downloaded files.
Obviously all this is a far cry from just pushing Dart code to a published app so I will not pretend that this resolves this issue. I would be very interested in any feedback people may have about this package. Please post your comments on issue 90218 (not here). Thanks!

I have an idea to develop a scripting language virtual machine on Flutter. At present, I try to write LuaVM with Dart, but the next problem is that I need to wrap Flutter's Widget for Lua, which is very troublesome. You can check here if you are interested.

@eseidelGoogle Can we have some latest news?

@eseidelGoogle @Hixie Are there any timelines to this that we can know of, if possible, we had to push a hotfix to production but it can't go fast to the users because app/play store reviews take time, as a result, we are getting a lot of unnecessary hate on the stores.

I have benchmarked a lot of solution!
To me, Capacitorjs is still the best for hybrid apps, you can use any frontend framework you like, you have even component library ready to go with ionic.
And OTA update are allowed because of JS usage !
there different solution like https://capgo.app/ who allow it

Are there any solutions for dynamic feature?

Flutter as App Module could be loaded dynamically via https://developer.android.com/guide/playcore/feature-delivery
Check PR: https://github.com/flutter/flutter/issues/57617
But Dart logic could not deployed over the air. AOT could not be reflected

Its just not possible with the Flutter architecture.  This works in Apache Cordova and React Native due to its JavaScript runtime layer. Flutter apps are transpiled into native device runtime languages. Its just not possible to replace that over the air, especially without extreme security concerns. The alternatives other developers are creating are big hacks that add another language runtime (like Lua) to a Flutter to enable this. That likely works, but adds a layer of complexity (and size) to a mobile app that I just don't want.  App Store release timelines aren't that extreme anymore, approvals in a day or so for existing apps. We just have to live with this, there's no viable alternative.

Hydro SDK is your best bet at the moment. I recorded a podcast episode with @chgibb where we went over his Hydro SDK and it's REALLY impressive.

There are couple of options,

Remote flutter widgets - mechanism for rendering widgets based on declarative UI descriptions that can be obtained at runtime.
Deferred components - To build apps that can download additional Dart code and assets at runtime (only available on Android, taking advantage of Android and Google Play Stores’ dynamic feature modules to deliver the deferred components packaged as Android modules.)

+1 To support Hot Update

I think if Flutter does not support HotFix, it will seriously affect Flutter's development in the iot space. Hopefully the Flutter team will seriously consider adding HotFix features

@jjvu-xiao It doesn't matter whether it affects Flutter's development in different spaces, supporting OTA updates is simply not possible considering Flutter apps are compiled executables. OTA updates to native apps violates Apple App Store rules and nobody would be happy with the limitations and performance impact it would have on apps and devices running apps. The architecture simply doesn't support it.

@jjvu-xiao It doesn't matter whether it affects Flutter's development in different spaces, supporting OTA updates is simply not possible considering Flutter apps are compiled executables. OTA updates to native apps violates Apple App Store rules and nobody would be happy with the limitations and performance impact it would have on apps and devices running apps. The architecture simply doesn't support it.

OTA updates do not violate the AppStore guidelines. Apple allows javascript bundles and other bundles to be updated remotely, not native binaries. Flutter will not need to do that.

@SethuSenthil yes, OTA updates don't violate Apple's App Store guidelines but that only applies to things like HTML and JavaScript content. Flutter apps are compiled native binaries on Android and iOS devices, so the only way for Flutter to support OTA updates is if they hack in a JavaScript/TypeScript runtime engine and you'd have to segregate your replaceable app logic in a completely different language. Yes, it can be done, and several folks on this thread have hacked together solutions for this, but that's all they are, hacks.
React Native works for this because the underlying technology automatically lends itself to OTA updates. These apps are really inefficient because the OTA update is stored app storage and executed remotely, the original version of the code still compiled inside the app. Flutter doesn't do that and therefore can't support that.

Can't we just leav ios user to cry and make avalibale to android & windows .
They Just jerks and Evil People

Hello are there any updates

Hi everyone, I've just released flutter_eval which allows code push for Flutter apps! Please check it out and let me know what you think :)

Hello are there any updates

The latest status is described in the top comment (with links to more details). I assure you if anything changes we will not be secretive about it. :-)

@ethanblake4 thanks for sharing this information regarding flutter_eval, could you share with us the potential size increase for a typical flutter app that includes the interpreter and the various interop pieces.

@a-siva I have published measurements of the app size using flutter_eval here. It is between 0.4-1.4 MB, with a more complex app having a smaller size increase.

Cannot we have void main();, class FrontPage, and class ScreeningPage compiled as one-time aot, while everything else as fully-updatable JIT

Cannot we have void main, class FrontPage, and class ScreeningPage compiled as  AOT, while everything else as JIT(dynamically loadable, and upgradable)?,
And, regarding the security concern, we can take inspiration from android-app installation process, which checks the apk-to-install's signing keys with that of the already installed one, and only proceed with installation, if the keys match,
During app building process, we already have access to the signing keys, which can be saved somewhere in the compiled binary, and like ui.loadFontFromList function, we can have io.loadWidgetFromByteArray, which checks the signing keys, and sends it to dart-vm, which transfers the execution control of the isolate
Anyways, react-native already has code-push, they must have, also thought regarding security, thoroughly before implementing code-push,
as can be seen from this comment
But i must say, code-push is the only thing keeping flutter, from replacing react-native and mobile natives (kotlin/compose and swift/swift-ui),

@gintominto5329

But i must say, code-push is the only thing keeping flutter, from replacing react-native and mobile natives (kotlin/compose and swift/swift-ui),

Please be careful with the arguments you put forward, mobile native apps have the same level of code push as Flutter does, this is strictly a plus for RN, not native.
Nonetheless, if you read above, the issue is not loading or saving binary blobs (it isn't that hard to implement compared to shipping an entire interpreter, as you could rig up the hot reload mechanism to reload a new image), it's about store policies forbidding apps from arbitrarily downloading and executing binary blobs as updates.
RN gets around that, as it's technically shipping source code.

I have created a proposal about this, by utilizing https://github.com/fzyzcjy/flutter_smooth.
Link: https://github.com/flutter/flutter/issues/113281