Code Push / Hot Update / out of band updates

eseidelGoogle commented 6 years ago

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.

aam commented 6 years ago

cc @floitschG

neiljaywarner commented 6 years ago

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

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

Use cases

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

yaronlevi commented 6 years ago

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.

badoet commented 6 years ago

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 (:

zoechi commented 6 years ago

compiling to javascript path will diminish the dart advantages right?

What advantages are you talking about?

ck-vimaljose commented 6 years ago

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

neiljaywarner commented 6 years ago

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 :(

rockneverdies55 commented 6 years ago

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

yisding commented 6 years ago

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

thefuzzyorange commented 5 years ago

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

ieatbyte commented 5 years ago

Much appreciated for team to implement this feature ASAP.

eseidelGoogle commented 5 years ago

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.

yaronlevi commented 5 years ago

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

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

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

shakil807g commented 5 years ago

any progress on "Code Push" ??

fmatosqg commented 5 years ago

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

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

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

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

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

vaibhavthapliyal commented 5 years ago

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.

yaronlevi commented 5 years ago

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

fisheye-123 commented 5 years ago

up vote

chufengma commented 5 years ago

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

minhhung2556 commented 5 years ago

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?

neiljaywarner commented 5 years ago

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 notifications@github.com 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 .

alibitek commented 5 years ago

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

genghf commented 5 years ago

expect it can be included in the coming 1.0 release!

JeffreyMcJeffFace commented 5 years ago

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

rockneverdies55 commented 5 years ago

@eseidelGoogle - it's been a while since you guys provided some updates in here.

Are you guys still working on this? How are the things going?

eseidelGoogle commented 5 years ago

Progress continues. No updates to share at this time.

Hixie commented 5 years ago

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.

knopp commented 5 years ago

Is this really feasible for iOS? 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). Also the different GC characteristics of Javascript core while Flutter creating tons of short lived object might not bode well.

eseidelGoogle commented 5 years ago

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?

iconico commented 5 years ago

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.

youmengna commented 5 years ago

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

mattiagalati commented 5 years ago

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.

koudle commented 5 years ago

Hope to achieve as soon as possible

flypigz commented 5 years ago

Another point: If the Flutter team provides the hot-fix solution officially, I think the Apple may reject all Apps built by Flutter at some time, 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 rejects all Apps with JsPatch, which was the most popular hot-fix solution in China. JsPatch is built on top of JsCore and OC runtime.

I would like to build Flutter Apps without hot-fix function, rather than Apps may rejected by Apple in the future.

yaronlevi commented 5 years ago

@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.

vinceramcesoliveros commented 5 years ago

If only iOS/android support such as this example: MyFlutterApplication asks permission/wants to update your app Changelogs: add kitties and dogs(v1.0) Allow | Don't allow

after reviewing the guidelines for both parties.

flypigz commented 5 years ago

@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.

excitedhaha commented 5 years ago

@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.

zoechi commented 5 years ago

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.

AweiLoveAndroid commented 5 years ago

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.

Flutter is not React Native,you can't use the experience for React Native(or other framework) to look at Flutter.They are different things.

potterdai commented 5 years ago

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

blessonabraham commented 5 years ago

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

zxm8241213zxm commented 5 years ago

The flowers I waited for are all gone.

flypigz commented 5 years ago

@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.

act64 commented 5 years ago

I just want to say ，hotfix is an import feature for most Chinese companies . more then 70% Chinese Android Devices don‘t support Google Play

zoechi commented 5 years ago

@act64 check https://github.com/flutter/flutter/wiki/Roadmap

taibaiyinxing commented 5 years ago

@act64 check https://github.com/flutter/flutter/wiki/Roadmap

The roadmap said hotfix on Android.Hope that the iOS will be supported soon.

zoechi commented 5 years ago

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

BANG88 commented 5 years ago

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

@zoechi We use enterprise app and we do not need upload to app-store.

yaronlevi commented 5 years ago

Dynamic patching on Android, allowing for code updates to deployed to Flutter applications running on Android directly from a servers. 🎉

flutter / flutter

Code Push / Hot Update / out of band updates #14330