The bad news
Thermal renewal/dynamism has been a key point since I came into contact with Flutter, and it is also an important factor or even the primary factor for many Internet manufacturers whether to choose Flutter. Previously, I attended the face-to-face activity with Flutter engineers held by Google in Beijing office. One of the most frequently asked questions about Flutter from programmers from various manufacturers is its support for hot updates. It was nice to see that There is support for hot updates in the Roadmap for 2019 at the beginning of the year. However, when I looked at the related issue a while ago, I found this disappointing news that The Flutter official will not be developing Code push updates for the time being.
The original text reads as follows:
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.
Github.com/flutter/flu…
A brief translation:
This feature (code push) was originally in the Flutter roadmap for 2019. But after going over the details we’ve decided not to do it for now.
We made this decision for several reasons:
According to the rules of the Android and iOS app stores as we understand them. Code push is limited to JIT Code on the Android platform. On iOS it is limited to interpreting the code executed. We are not confident that this limited solution will perform as well as we expected on iOS. (In other words, “it’s going to be painfully slow.”)
Then there are safety concerns. Because patches allow arbitrary code to be executed. This makes patches an attractive vehicle for rogue software. This risk can be mitigated by forcing the patch to be signed with the same key as the app, but this is also error-prone, and a single error can lead to serious consequences. This is also the fundamental problem that plagues some platforms that allow third-party code to be executed. This can be mitigated by building updates into the platform, but this defeats our goal of providing a platform-independent patching mechanism.
There is currently no open source solution for delivering patches out of the box. So either we throw the problem at the user and let them configure it on their own Web server, or we have to integrate third-party proprietary services, or we create our own solution. However, we do not want to do it ourselves, the customer to configure, they may make the above security mistakes. Relying on third-party services puts Flutter in an awkward position. We had to choose one of the many third party services, and there was a possibility that a third party service could make its own rules to affect the Code push function of Flutter.
At present we prefer to devote our resources to other problems. We will continue to verify this feature and may decide to do a Code push again in the future (for example, we may need to update the SOLUTION to the PC Flutter app). But probably not this year.
feeling
The launch of Flutter is truly amazing, written once and running on multiple platforms (Android/iOS/PC/ browser). Comparable to the native running experience. However, I do not think Flutter is complete or revolutionary without thermal renewal. Only a disruptive change to the existing mobile development paradigm/ecosystem can be considered revolutionary.
Why do you say that? App or H5, for users and Internet manufacturers, its essence is service. Users can use the services of Internet manufacturers in various ways, which can be accessed in APP, browser or even through voice interaction (such as various smart speakers on the market). What is the most convenient way for users to experience the best way to use which. For Internet manufacturers, it is their goal to provide stable and secure personalized services for users quickly and conveniently. Can the service reach users quickly and efficiently? At present, in the form of APP, new services and new needs need to be released to the market through the new version of APP, which can only be accessed after the market review is passed and users upgrade.
There are two problems with this. One is the cost in terms of time. Take the App Store for example. Another is the risk of rejection. I’m sure many developers have experienced app approval failure. This will tell to Internet manufacturer, have a kind of out-of-control feeling. So what is the ideal model for Internet manufacturers? That’s the H5-like model, where the service is in the hands of the user from launch to touch. The popularity of plug-in solutions in recent years partly reflects this demand from Internet manufacturers.
If Flutter can support hot updates, it opens a window to change the current model of app development and distribution, from small online problem fixes like hot patches, to rapid deployment of new services like the H5 that reach users instantly and are completely controllable. At the same time, it can achieve comparable performance to native. That’s a paradigm shift. That’s revolutionary.
However, from the three reasons mentioned in the previous issue, it is really difficult to support Code push. Performance issues (mainly iOS), security issues and patch release systems are not fixed in a short period of time or are not suitable to be addressed by the authorities. From the perspective of the Flutter team, there is no way to provide a lower-standard thermal update solution that does not address these issues, since it has to be officially endorsed. However, I think this is also a technology direction worth studying for Flutter developers of various Internet manufacturers. Compared with the general high standard hot update solution, developers can weigh the technical risks and technical benefits and make some trade-offs to implement their own hot update solution of Flutter. For example, iOS cannot be implemented. Can we do it on Android first? How much impact will the security problems mentioned by the authorities have on my APP? Have I ever encountered similar security problems on H5? Is there anything I can do to avoid these security issues? As to patch release system, it is Internet manufacturer, oneself do one should it doesn’t matter a problem.
We have seen that Xianyu has been working on a hot update solution for Flutter supporting iOS and Android. Basically, there is no loss of performance, and it is also a solution suitable for our business after making some trade-offs. I hope to learn more technical details later.
hope
Let’s talk about hope again about Flutter hot update.
Possible hope: As can be seen from the issue above, the Flutter team is open to third parties developing their own hot updates. Don’t count on hot updates on iOS. But at least on The Android platform there is a decent open source hot update solution. After all, previous plug-in technologies are increasingly limited. Hopefully, at least on The Android platform, this hot update solution will be as easy to deploy as the H5, while providing performance comparable to the native operating experience.
Unrealistic hope: Flutter officials will soon be able to bring the hot update feature back on the agenda. After all, official support is the best kind of support.
Whimsical hope: Though unlikely, it is hoped that Apple will give Flutter platform-level thermal update capabilities to help build a new app development/release model.
If you have anything to say about this official statement, please post it in the comments.