Flutter: Code Push / Hot Update / out of band updates

cc @floitschG

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

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

Use cases

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

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

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

compiling to javascript path will diminish the dart advantages right?

What advantages are you talking about?

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

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

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

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

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

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

Much appreciated for team to implement this feature ASAP.

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

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

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

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

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

any progress on "Code Push" ??

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

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

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

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

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

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

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

up vote

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

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

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
.

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

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

• Video
• Slides

expect it can be included in the coming 1.0 release!

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

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

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

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

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

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

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

1. Flutter also support Apple's Cupertino, MD is not the only chosen.
2. You may know the Unity in the Gaming area, Flutter's render system works similarly in some ways.
3. 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.

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.

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

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

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

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

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

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

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

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

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

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

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.
there are a lot of app store like google play in china.we have no time to push update to every app store.

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

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
@KinsomyJS
我也是跑了个demo验证可行性. 哈哈哈~

Please share with brief snippet or blog post or comment here or cc [email protected] 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 time 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 updates" 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. So I think Flutter's solution could be allowed as well.

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 with 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 is no time for 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 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 :)

Flutter for web SDK is soon to be merged with mobile SDK. A workaround is to use a mobile WebView to load flutter code. 😁

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

Maybe help
https://github.com/dengyin2000/dynamic_widget
https://github.com/neohelden/Flutter-AdaptiveCards

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.

MXFlutter uses JavaScript to implement Flutter's rendering capabilities, supports Flutter syntax, and 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... Our lean methodology goes to shit with this.

@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 will 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=web2

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
  
  
  • Adding features
  
  
• 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 two things? To get codepush while writing Dart as usual?

@SpajicM that only works _because_ it's not using Dart, instead, it probably 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.

Scratch that, it uses Lua bytecode, which is against store policy in every way shape or form.

@miyoyo why is that specifically against store policy?
@SpajicM it's purely additive. Typescript pieces can be embedded into a larger Dart app. As small as single pieces of text, or entire screens.

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 .

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

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

@miyoyo

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. If code push is integrated into the Flutter engine, Apple could decide to ban all Flutter apps.

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

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/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)

@ardyfeb People like you give the react community a bad rep, please troll somewhere else.

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.

If somebody needs Over-the-air updates just for app translations, here is a sample Flutter app: 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?