After the recent “Flutter: I hear you’ve been telling people I’m disbanding? After the recent “Flutter: I heard you’ve been telling people that I’m disbanding?” event, many people are more concerned about the progress of Flutter, so I’m going to do a brief summary here to report on some of the popular issues/roadmaps in the past quarter, and I’m also going to read the comments on the articles and the public number messages these days.

iOS Privacy

You may be familiar with the privacy checklist that was made mandatory by iOS starting in May, but if you haven’t yet, you can read the detailed explanation in the past:

• 
  2024 Flutter iOS Privacy List is online, have you received “ITMS-91053”?
• 
  What exactly is the privacy checklist for iOS in Spring 2024?

According to recent developments, the enforcement of a number of things will be limited to dynamic frameworks starting May 1, but the enforcement of static build requirements for plugins is expected to return in the future, and from this perspective, the adaptation requirements for Flutter Plugin are much lower, provided it is not on the list of third-party SDK requirements:

Android 14 TLHC cannot be displayed

This issue appeared and was fixed in #146499, which was initially filed as a Samsung-specific issue from #139039, where PlatformView-related content was occasionally not rendered correctly, and then moved to 146499, where the issue was considered an Androd 14 system bug.

There’s an interesting twist here, which is that the other side believes that this is a bug in Samsung’s system that developers can only wait for the manufacturer to fix and release on their own, and that the issue has actually been fixed in Android 15, and that such a statement has led to the two aforementioned issues being so loud that they’re forced to lock calmly.

It was finally discovered that the bug encountered on Android 14 is indeed a bug in Android itself. The PlatformView stops getting drawing information from Android when memory is pruned, resulting in a transparent platform view even though the underlying view exists and can be interacted with, so this set of triggers is not unique to Flutter, and the corresponding API will also fail for native Android apps. So this set of triggers is not unique to Flutter, and the corresponding API will also fail for Android native apps.

Currently the main trigger should be “out of memory” so it will appear in the background, and since flutter 3.19 onwards, for PlatformView no longer caches the last frame and draws it on Resume, the current situation occurs.

So for now, the temporary pr solution is to add getPlatformViewsController().onResume() and resetSurface processing, and Flutter has already communicated with the Android Team to push forward the landing of the relevant Android 14 patch:

This is a sad message, in fact, from last year’s PC after the departure of the relevant PM, PC’s advancement has been “very slow”, and multi-window as a “call” one of the biggest features, currently ushered in the progress of the suspension of the personal speculation is still and the financial factors of the layoffs, after all, Google’s financial adjustments under the majority of the project are “open apes cut off the flow of flow”, and Flutter PC this year have not been “big! movement” in the case of further reducing resources to ensure that the “core” roadmap is inevitable, well, you can continue to sing the praises of 😏.

Many Flutter PC users, have opted out because of the lack of multiple windows.

Eric, one of the founders of Flutter, has been working on Flutter-related startups since he left the company, and recently Shorebird, which he was responsible for, has finally released version 1.0+, officially supporting Flutter hot updates on Android and iOS.

Eric said that Shorebird, as a Flutter hot update tool, can be a performance-neutral (even after patching) experience while adhering to Apple and Google store policies because it doesn’t use hot reloading (or Dart’s JIT compiler), but instead implements a Dart-specific interpreter to do so.

Shorebird exists as a branch of Flutter with code push added to it, and Shorebird is not a replacement for Flutter, but a replacement for the Flutter engine, and while it looks good, it is, however, paid.

skwasm

There have actually been articles about Wasm Native before this, so check them out:

In fact, this is the shrewdness of the Flutter Web project, “knowing the trade-offs and resources”, when deciding to promote Dart’s Wasm Native, it was decided that Flutter Web was promoting a “cutting-edge” technology capability, no matter whether the final landing was as expected or not, because it was involved in the promotion of the WasmGC is not just for Flutter Web, so it can have topics and resources. So it can have topicality and resources.

At the same time, in order to better “concentrate” the resources, Flutter Web made the issue of abandoning Html renderer, which was certainly opposed by many users, after all, there are still a lot of practical problems with skwasm, but as a directional decision, I personally feel that it is still quite good for Flutter Web, after all, the advantage of Html renderer is not very big and it needs more resources to be adapted, at least for the time being, Flutter Web can avoid the same “no breakthrough” dilemma as PC team. After all, the advantage of Html renderer is not big, and there are more resources to be adapted, at least for the time being, Flutter Web going to Wasm Native can avoid falling into the predicament of “no breakthrough progress” like PC team.

For more future progress and planning, you can see Flutter 2024’s roadmap, and this year’s Google I/O is coming up, so if you’re interested, you can also pay attention to it: io.google/2024/intl/