The Dart Platform, on which Flutter is built, provides unique abilities for
us to push code to your applications without redeploying the app.
Dynamic patching on Android, allowing for code updates to deployed to Flutter
applications running on Android directly from a servers.
Dynamic extension loading to allow lazy loading of occasionally used parts of
这里的Dynamic patching on Android指的是热更新，Dynamic extension loading
Dropped support for Dynamic updates in 2019. See this bug for details.
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
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.