Flutter 3.47 is a feature-and-plumbing release. The headline items people noticed were viable multi-window support on desktop, more progress on the new rendering stack, and a stronger push toward WebAssembly for Flutter web. The release also continues the decoupling of Material and Cupertino so Flutter’s own widget libraries can evolve separately instead of being tied to framework releases. That all reads like a mature platform doing catch-up on long-standing desktop and web gaps rather than unveiling a new direction.
The useful consensus is that Flutter remains very good at one specific job: shipping a consistent app across iOS, Android, and increasingly desktop from one codebase. Even critics mostly conceded that point. Where confidence breaks is everywhere Flutter has to pretend the browser or host platform is just another framebuffer. Web drew the harshest criticism. Because Flutter web is largely canvas-based, it gives up a lot of the
DOM ecosystem that normal web teams rely on for accessibility tooling, analytics, browser automation, session replay, and lightweight first-load performance. Several people also called out desktop as still lagging in the details, with popup windows only now becoming practical and reports of roughness on Linux, Windows, and some desktop apps.
On mobile, the divide was more philosophical. Flutter fans argued that owning the rendering stack is exactly why it works. You get consistent UI, fewer device-specific surprises, and strong performance even on weaker hardware.
React Native supporters made the opposite bet. They prefer staying closer to native platform concepts, hiring from the much larger
TypeScript pool, and keeping a codebase that is easier to bridge or eventually migrate into
Swift and
Kotlin. Nobody seriously claimed either framework eliminates native code. Platform features like widgets,
Live Activities,
Dynamic Island,
NFC, and OS-specific integrations still drag you into native modules either way.
The language question turned out to be less important than the ecosystem question.
Dart got plenty of defenders who described it as a pragmatic, strongly typed language with a good compiler and solid tooling. Even some people ambivalent on Flutter said Dart itself rarely gets in the way. The sharper complaints were about taste and market reality. Teams can hire React and TypeScript developers much more easily than Dart specialists, and that alone shapes decisions more than whether Dart is elegant.
There was also a broader strategic read on why Flutter survives inside Google. People pointed to real internal usage, strong adoption outside Google, and the fact that Flutter and Dart pull developers toward Google’s own cloud and mobile services. That blunted the usual "Google will kill it" reflex, but did not erase it. The trust problem is still there. Plenty of people now think Flutter is stable enough to use. They still do not like being dependent on a product whose long-term ownership and place in Google’s stack remain fuzzy.
A newer undercurrent ran through the whole conversation: AI changes the economics of native development. Several commenters said code generation makes fully native apps much more viable than they were even a year ago, because the old cost of duplicating UI across platforms is falling fast. That did not make Flutter obsolete. It did make the old blanket argument for cross-platform frameworks feel weaker. Flutter now has to justify itself against both React Native and a future where native UI is cheaper to produce than the coordination overhead of living inside a framework abstraction.
flutter.dev