search

flutter / flutter

Flutter makes it easy and fast to build beautiful apps for mobile and beyond
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
162.27k stars 26.66k forks source link

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

Open eseidelGoogle opened 6 years ago

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

Code push for Flutter is available as a third-party product from shorebird.dev, as discussed in this comment: https://github.com/flutter/flutter/issues/14330#issuecomment-2099442823

This comment gives a brief overview of various kinds of "hot update" features, 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.

SunshowerC commented 5 years ago

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

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

eseidelGoogle commented 5 years ago

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.

zcyc commented 5 years ago

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.

mmcc007 commented 5 years ago

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 😂👍).

zcyc commented 5 years ago

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

Taxi4you commented 5 years ago

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

LNeway commented 5 years ago

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

KinsomyJS commented 5 years ago

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

LNeway commented 5 years ago

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验证可行性. 哈哈哈~

neiljaywarner commented 5 years ago

Please share with brief snippet or blog post or comment here or cc njwandroid@gmail.com in the email...

neiljaywarner commented 5 years ago

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

neiljaywarner commented 5 years ago

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

siddshadab commented 5 years ago

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

mohamedsharaf commented 5 years ago

@dahabdev

matthewlloyd commented 5 years ago

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.

jamesdixon commented 5 years ago

@matthewlloyd lots of great points!

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

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

truongsinh commented 5 years ago

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

Hixie commented 5 years ago

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:

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.

kunit1 commented 5 years ago

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.

lanistor commented 5 years ago

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

yaronlevi commented 5 years ago

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.

FaisalAbid commented 5 years ago

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

AmitJoki commented 5 years ago

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.

0xc0d3r commented 5 years ago

Any update?

TheRusskiy commented 5 years ago

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

neiljaywarner commented 5 years ago

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

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

VistianOpenSource commented 5 years ago

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

Hixie commented 5 years ago

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

billzhouGitHub commented 5 years ago

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

感谢您透明地传达团队的理性。

我同意

catalsdevelop commented 5 years ago

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

maplerichie commented 5 years ago

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?

vinceramcesoliveros commented 5 years ago

@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

0-php commented 5 years ago

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

yaronlevi commented 5 years ago

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.

matthewlloyd commented 5 years ago

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

faustinoribeiro commented 4 years ago

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.

OrangeKnife commented 4 years ago

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

krmao commented 4 years ago

really disappointing :)

sweetbot commented 4 years ago

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

AllenLiberty commented 4 years ago

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

amorenew commented 4 years ago

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

dancojocaru2000 commented 4 years ago

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 commented 4 years ago

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

truongsinh commented 4 years ago

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

kangwang1988 commented 4 years ago

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

kasogg commented 4 years ago

we'll consider use flutter if it supports code push

miyoyo commented 4 years ago

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

truongsinh commented 4 years ago

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.

miyoyo commented 4 years ago

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