Flutter - free resource mobile app, desktop, web

Impeller has been the only renderer on iOS for years and the default on Android API 29+ for a while. Flutter 3.47 finishes the job: Impeller is now the default on macOS, Windows and Linux. Only Flutter Web still runs on Skia.

If you ship desktop apps, this is the change in 3.47 most likely to alter how your app actually looks and feels — and the one most likely to surface a rendering bug you have never seen before.

The problem Impeller was built to solve

Skia compiles shaders at runtime, on demand, the first time a particular drawing operation appears. That is why a Flutter app could stutter the first time you opened a specific screen, ran a specific animation, or applied a specific blur — and then run perfectly forever after. It was not your code. It was the renderer compiling a program mid-frame.

Impeller compiles a smaller, simpler set of shaders offline, at engine build time. Pipeline state objects are built upfront rather than per frame. Caching is explicit and engine-controlled rather than implicit. The result is not necessarily a higher peak frame rate — it is predictable frame timing, which is what users actually perceive as smoothness.

The design goals are worth naming because they explain the trade-offs:

• Predictable performance — everything compiled offline
• Instrumentable — graphics resources are tagged, and animations can be captured and persisted without perturbing frame times
• Portable — shaders authored once, converted per backend
• Modern APIs — uses Metal and Vulkan features without requiring them
• Concurrent — a single frame’s work is spread across threads

Which backend runs where

Vulkan on Windows and Linux is the line to read twice. Your users’ driver situation is now part of your rendering stack in a way it was not before, and that variability is exactly why you should test on real hardware rather than one developer machine.

Wide gamut color on macOS

Alongside the renderer switch, wide gamut color is enabled by default on macOS. On a P3 display, saturated colors will render more saturated than they did under the previous default. This is correct behaviour, but it is a visible change: if your brand colors were tuned by eye against an sRGB-clamped render, they will look different. Check your palette against design before assuming it is a bug.

How to opt out, per platform

The escape hatches exist, and the release notes are explicit that fallback options will be removed in a future release. Use them to unblock a shipping deadline and to file a bug — not as a long-term configuration.

For debugging on any desktop platform:

flutter run --no-enable-impeller

For release builds, macOS — in Info.plist, under the top-level <dict>:

<key>FLTEnableImpeller</key>
<false />

For release builds, Linux — in linux/runner/my_application.cc:

g_autoptr(FlDartProject) project = fl_dart_project_new();
fl_dart_project_set_enable_impeller(project, FALSE);

For release builds, Windows — in windows\runner\main.cpp:

flutter::DartProject project(L"data");
project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);

On Android the equivalent is a manifest entry (io.flutter.embedding.android.EnableImpeller set to false). On iOS there is no opt-out at all — which is a preview of where desktop is heading.

What to actually re-test

Renderer swaps surface issues in a predictable set of places. Prioritise:

• Blurs and shadows — BackdropFilter, ImageFilter.blur, elevation shadows. Historically the highest-variance area between renderers.
• Custom painters and shaders — anything using CustomPainter, FragmentProgram, or blend modes beyond srcOver.
• Text rendering at small sizes — subpixel positioning and hinting differ.
• Colors on P3 displays — see wide gamut above.
• Clipping and anti-aliasing edges — especially nested clips with rounded corners.
• Startup on low-end GPUs — the Vulkan path on Windows and Linux is the new variable.

The Q2 2026 survey puts Windows satisfaction at 74% and Linux at 73% — the two lowest platform scores after Cupertino. Desktop is where Flutter has the most ground to make up, which cuts both ways: this release is a real investment in those platforms, and it is also the area with the thinnest prior testing.

Filing a useful bug

If you find a regression, the Flutter team asks for a specific bundle, and reports missing it tend to stall:

1. Prefix the issue title with [Impeller].
2. Include device specifications, including the exact chip and GPU driver version.
3. Attach screenshots or a screen recording, ideally side by side with --no-enable-impeller.
4. Attach a zipped performance trace export.
5. State the Flutter version and channel from flutter --version.

The side-by-side comparison is the highest-value item. It converts “this looks wrong” into a reproducible rendering difference.

Your upgrade checklist

1. Build your desktop targets on 3.47 before touching anything else.
2. Run your visual regression suite, or if you do not have one, walk your five most complex screens manually.
3. Compare against --no-enable-impeller for anything that looks off, so you know whether the renderer is actually the cause.
4. Test on at least one low-end Windows GPU and one Linux distribution you do not develop on.
5. Re-check brand colors on a P3 display if you ship on macOS.
6. File [Impeller]-prefixed bugs now, while the fallback still exists.
7. Do not ship the opt-out permanently. Track it as technical debt with a removal date.

The bottom line

Impeller on desktop is the right change and a slightly risky one. The upside is structural: shader jank stops being a category of bug you have to chase, and frame timing becomes predictable. The cost is a one-time re-verification pass over your visual layer, and a new dependency on Vulkan driver quality on Windows and Linux. Do that pass now, while --no-enable-impeller still exists to tell you whether the renderer is at fault — because it will not exist forever.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

The most interesting consequence of Impeller is not smoother scrolling. It is that Flutter now has a rendering backend modern enough to expose a low-level graphics API — flutter_gpu — and that a real 3D engine has been built on top of it.

Now that Impeller is the default renderer on every platform except web, that API’s reach is wider than it has ever been. This article is about what actually exists today, and where the line between “impressive demo” and “ship it” currently sits.

What Flutter GPU is

flutter_gpu is a thin, low-level API over Impeller’s rendering primitives — command buffers, render passes, textures, and shader pipelines. It is not a scene graph and it is not widgets. It is the layer you use when you want to draw things Flutter’s painting API cannot express: custom renderers, particle systems, post-processing, 3D.

Shaders are authored separately and compiled into shader bundles at build time, using flutter_gpu_shaders and build_runner. That is consistent with Impeller’s whole philosophy: pay the compilation cost during the build, never mid-frame.

The mental model that helps: CustomPainter gives you a canvas, FragmentProgram gives you one shader stage over a rectangle, and flutter_gpu gives you the actual pipeline.

flutter_scene: the engine on top

Writing raw GPU code is not what most developers want. flutter_scene — published by the verified bdero.dev publisher, currently at 0.20.0 — describes itself as a flexible realtime 3D engine for Flutter games and apps, with glTF models, physics, skeletal animation, and PBR lighting.

The API is shaped the way a Flutter developer would expect:

• SceneView — the widget you drop into a tree to render a scene
• SceneNode, SceneMesh, SceneModel — the declarative widget API for scene contents
• glTF import at runtime, or a pre-converted .fsceneb binary at build time
• .fscene as a scene description format, with prefab support

That last pair matters for real apps. Parsing glTF at runtime is convenient during development and expensive at startup; the pre-converted .fsceneb path is what you ship.

Platform coverage follows Impeller — iOS, Android, macOS, Windows, Linux — plus web via WebGL2, which is notable given that Impeller itself is not yet available for Flutter Web.

Getting set up

The setup is more involved than a normal package, because native assets and GPU access both have to be turned on:

flutter config --enable-native-assets
flutter config --enable-dart-data-assets   # optional, for DataAssets

flutter create . --platforms=macos,ios,android,linux,windows,web

flutter run --enable-flutter-gpu --enable-impeller

The one that will stop you: flutter_scene currently requires the Flutter master channel, not stable. Version 0.19.0 needed a master build from June 9, 2026 or later for render-to-mip-level support. That is the single most important fact in this article for planning purposes.

How capable is it really

Community demos are the honest evidence here, and they are more convincing than the version number suggests. Brandon DeRosier — the author of flutter_scene — has demonstrated a Scene Editor running on Flutter 3.47 stable, and a port of Godot’s Third Person Shooter demo: roughly 617 MiB of cooked content, 1,795,763 unique vertices, 659,079 unique triangles, and 320 collision meshes, rendering through Flutter GPU and Impeller.

The framing he uses is the part worth repeating: no forks, no platform views, no secondary rendering context. This is not a Unity view embedded in a Flutter app. It is Flutter’s own graphics stack drawing the scene, which means your 3D content and your widgets share a compositor, a frame budget, and an input pipeline.

Other developers have reported flutter_gpu plus Impeller rendering on the order of 20,000 images at roughly 120fps across multiple platforms — the kind of throughput that was simply not expressible through the widget layer before.

Choosing between the layers

Read that table as a ladder, and take the lowest rung that solves your problem. Most apps asking for “3D” want a rotating product model or a data visualisation, and flutter_scene handles that comfortably. Very few want an engine.

The honest maturity assessment

Things that are genuinely true today: the graphics stack is real, the performance numbers are real, and the integration story — one compositor, no platform views — is better than any embedding approach.

Things you should weigh before betting a roadmap on it:

• Master-channel requirement means no stable-channel guarantees, no long-term support window, and a real chance of breakage on any given day.
• 0.x versioning means the API can change under you.
• The package is a community project by an individual publisher, not a Google-supported product. The Q2 2026 survey found developers trust community “battle-tested” features at 41% versus 26% for Google-built ones, so that is not automatically a negative — but it is a different support model.
• Tooling is thin. There is a Scene Editor, but nothing resembling Unity’s ecosystem.

If you want to try it

1. Switch a scratch project to the master channel. Do not do this in your production repo.
2. Enable native assets and generate platform stubs with the commands above.
3. Run with --enable-flutter-gpu --enable-impeller and confirm you get a frame before writing any real code.
4. Start with flutter_scene, not raw flutter_gpu. Drop a SceneView in and load a glTF model.
5. Pre-convert assets to .fsceneb as soon as you care about startup time.
6. Profile on your worst target device early — GPU-bound work exposes hardware differences far faster than widget code does.
7. Pin your Flutter commit hash in CI, since master moves daily.

The bottom line

Flutter GPU is the clearest evidence that Impeller was an architectural investment rather than a performance patch. A single developer building a credible 3D engine on top of it — one that ports a Godot demo with 1.8 million vertices without forking the framework — says more about the foundation than any release note. Just be clear-eyed about the current state: this is a master-channel, 0.x, community-maintained stack. Prototype on it enthusiastically. Ship on it only if you are comfortable tracking master.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Flutter 3.47 landed on August 13, 2026, and for once the headline is not a feature — it is an architectural split. The design system is moving out of the SDK. Add Impeller becoming the default renderer on every desktop platform and Widget Previews going stable, and this is the most structurally significant Flutter release in years.

The numbers behind it: 1,356 commits from 169 contributors, 66 of them first-timers, shipping as Flutter 3.47.0 • Dart 3.13.0 • DevTools 2.60.0.

Material and Cupertino become packages you choose

The change everyone is talking about: material_ui and cupertino_ui are now standalone packages on pub.dev, both at 1.0. The libraries still live inside the SDK for now, but the SDK copies are scheduled for formal deprecation in the November stable release.

Why this matters more than it sounds:

• Design systems can now ship on their own clock. Instead of waiting for a quarterly SDK release, Material and Cupertino can iterate weekly. Cupertino in particular needs it — see the survey numbers below.
• You can pin your design system independently of your framework version. Upgrading Flutter no longer means swallowing every widget change at the same time.
• Apps that use neither can drop both. If you ship a fully custom design system, the Material tree stops being a mandatory dependency.

Migration is a one-liner:

dart fix --apply --code=migrate_design_widgets

For the messy middle — your app migrated but a dependency still imports the old paths — there is a MaterialUiCompatibilityBridge to keep both worlds talking.

Impeller is now the default on macOS, Windows and Linux

Impeller replaces Skia as the default renderer across all three desktop platforms. The practical payoff is the same one mobile got: shaders are compiled at build time, so shader compilation jank goes away. On macOS, wide gamut color is on by default as well.

There are opt-outs per platform, but the blog is blunt that fallback options will be removed in a future release. Treat the opt-out as a bug-reporting window, not a long-term strategy.

Widget Previews graduate to stable

Widget Preview is no longer experimental. The stable version adds local caching for faster startup and abstract theme APIs, so a preview can be rendered against multiple themes without wiring up a full app shell. If you tried previews in an earlier release and found them slow, this is the version to retry.

The upgrade tax: iOS 15 and macOS 12 minimums

To support Xcode 27, the floors moved:

Apps also need to adopt the UIScene lifecycle for iOS 27 compliance. If you skipped that migration when 3.44 flagged it, this is where it stops being optional.

Web: Wasm keeps inching toward default

The WebAssembly story from the 2026 roadmap continues. You can build with:

flutter build web --release --wasm

New this release: experimental deferred loading for Wasm behind --enable-wasm-deferred-loading. The prerequisite is still the same — migrate off legacy dart:html to package:web before you expect any of this to work cleanly.

On the plugin side, 92 of the top 100 iOS plugins have migrated to Swift Package Manager. The CocoaPods era is ending faster than most upgrade guides assume.

What the Q2 2026 survey says about where Flutter actually hurts

Google published the Q2 2026 survey results the same week — 3,500+ complete responses collected June 8–22, 2026 — and it reads as the subtext for this release.

The good news is unusually good:

• 93% overall satisfaction, with 58% “very satisfied” (up 6 points from Q4 2025)
• 83% trust Flutter to meet their needs, up from 77%
• For the first time, every developer subgroup cleared 90% satisfaction

Then the outlier:

• Cupertino widgets: 61% satisfaction, down 6 points — the lowest-rated area in the survey, against 92% for Dart, 91% for Android, 90% for the core framework.

Which is exactly why decoupling Cupertino into a package that can ship weekly is the fix, not a refactor for its own sake.

The top pain points name the rest of the release, too: platform/ecosystem maturity (44%), driven by version-matrix complexity during upgrades, then tooling and IDE experience (33%), then bugs and stability (24%).

One more number worth sitting with: developers trust community “battle-tested” features at 41% versus 26% for Google-built features, and trust in Flutter runs 20+ points ahead of trust in Google (83% vs 62%).

The AI trend line: agents are now a first-class Flutter workflow

The survey’s AI section is the clearest signal of where the ecosystem is heading. On adoption:

• Claude Code — 32%
• Antigravity — 23%
• GitHub Copilot — 19%
• Cursor — 18%
• Codex — 17%

Agentic tools now lead the pack, ahead of the autocomplete generation. VS Code (66%) and Android Studio (40%) remain the editors those agents run inside.

Google is building for that directly. Skills for Dart and Flutter, announced in May 2026, are task-oriented instruction sets that teach an AI agent how to do a specific Flutter job — the initial five cover integration testing, localization, responsive layouts, pattern-matching refactors, and test coverage. The framing from the announcement is the useful mental model: MCP gives an agent tools; a Skill gives it the blueprint and the professional know-how. They load progressively, only when relevant, which keeps token usage down.

The problem being solved is the one every Flutter developer using an LLM has hit: the framework moves faster than model training data. A release like 3.47, which changes import paths for the two most-used libraries in the ecosystem, is exactly the kind of change a stale model will get confidently wrong.

Your upgrade checklist

1. Run dart fix --apply --code=migrate_design_widgets and move to material_ui / cupertino_ui before the November deprecation.
2. Audit dependencies for packages still importing the SDK design libraries; use MaterialUiCompatibilityBridge while you wait on them.
3. Bump your deployment targets to iOS 15 / macOS 12 and finish the UIScene migration.
4. Smoke-test desktop builds under Impeller — and file bugs now while the Skia fallback still exists.
5. Retry Widget Previews if the experimental version put you off.
6. Test a Wasm build and check whether deferred loading helps your bundle.
7. Point your AI agent at the Dart & Flutter Skills so it stops generating 3.44-era imports.

The bottom line

Flutter 3.47 is the release where Flutter stops being one monolith. Material and Cupertino become packages you version yourself, Impeller finishes its takeover on desktop, and previews become a normal part of the loop. The survey explains the strategy: satisfaction is high almost everywhere, Cupertino is the exception, and shipping design systems on their own schedule is how you fix that without holding the SDK hostage. Budget an afternoon for the migration — but do it before November, when the old imports start warning.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Impeller đã là renderer duy nhất trên iOS nhiều năm và mặc định trên Android API 29+ được một thời gian. Flutter 3.47 hoàn tất công việc: Impeller giờ là mặc định trên macOS, Windows và Linux. Chỉ còn Flutter Web chạy trên Skia.

Nếu bạn ship app desktop, đây là thay đổi trong 3.47 dễ làm app của bạn nhìn và cảm nhận khác nhất — và cũng dễ làm lộ ra một lỗi render bạn chưa từng thấy nhất.

Vấn đề Impeller sinh ra để giải

Skia biên dịch shader lúc chạy, theo yêu cầu, ngay lần đầu một thao tác vẽ cụ thể xuất hiện. Đó là lý do một app Flutter có thể giật ở lần đầu bạn mở một màn hình, chạy một animation, hay áp một hiệu ứng blur cụ thể — rồi sau đó chạy mượt mãi mãi. Không phải do code của bạn. Là do renderer biên dịch một chương trình ngay giữa khung hình.

Impeller biên dịch một tập shader nhỏ hơn, đơn giản hơn, ngoại tuyến, lúc build engine. Các pipeline state object được dựng trước thay vì dựng theo từng khung hình. Cache là tường minh và do engine kiểm soát thay vì ngầm định. Kết quả không nhất thiết là frame rate đỉnh cao hơn — mà là nhịp khung hình dự đoán được, thứ mà người dùng thực sự cảm nhận là mượt.

Các mục tiêu thiết kế đáng gọi tên vì chúng giải thích những đánh đổi:

• Hiệu năng dự đoán được — mọi thứ biên dịch ngoại tuyến
• Đo đạc được — tài nguyên đồ hoạ được gắn nhãn, và animation có thể được ghi lại, lưu trữ mà không làm nhiễu thời gian khung hình
• Khả chuyển — shader viết một lần, chuyển đổi theo từng backend
• API hiện đại — dùng tính năng của Metal và Vulkan mà không bắt buộc phải có
• Đồng thời — công việc của một khung hình được trải ra nhiều luồng

Backend nào chạy ở đâu

Vulkan trên Windows và Linux là dòng đáng đọc hai lần. Tình trạng driver của người dùng giờ là một phần trong stack render của bạn theo cách trước đây không phải, và chính sự biến thiên đó là lý do bạn nên test trên phần cứng thật thay vì một máy dev duy nhất.

Wide gamut color trên macOS

Song song với việc đổi renderer, wide gamut color bật mặc định trên macOS. Trên màn hình P3, các màu bão hoà sẽ render bão hoà hơn so với mặc định trước đây. Đây là hành vi đúng, nhưng là thay đổi nhìn thấy được: nếu màu thương hiệu của bạn từng được canh bằng mắt trên bản render bị kẹp về sRGB, chúng sẽ trông khác. Hãy đối chiếu bảng màu với design trước khi kết luận đó là lỗi.

Cách tắt, theo từng nền tảng

Các lối thoát vẫn tồn tại, và release notes nói rõ rằng các phương án fallback sẽ bị gỡ trong một bản phát hành tương lai. Hãy dùng chúng để gỡ kẹt một mốc phát hành và để báo lỗi — không phải làm cấu hình dài hạn.

Để debug trên mọi nền tảng desktop:

flutter run --no-enable-impeller

Bản release, macOS — trong Info.plist, dưới <dict> cấp cao nhất:

<key>FLTEnableImpeller</key>
<false />

Bản release, Linux — trong linux/runner/my_application.cc:

g_autoptr(FlDartProject) project = fl_dart_project_new();
fl_dart_project_set_enable_impeller(project, FALSE);

Bản release, Windows — trong windows\runner\main.cpp:

flutter::DartProject project(L"data");
project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);

Trên Android tương đương là một mục trong manifest (io.flutter.embedding.android.EnableImpeller đặt false). Trên iOS thì không có lối tắt nào cả — và đó là bản xem trước của nơi desktop đang đi tới.

Nên test lại những gì

Đổi renderer thường làm lộ vấn đề ở một nhóm chỗ có thể đoán trước. Ưu tiên:

• Blur và đổ bóng — BackdropFilter, ImageFilter.blur, bóng theo elevation. Trong lịch sử đây là vùng lệch nhiều nhất giữa các renderer.
• Custom painter và shader — mọi thứ dùng CustomPainter, FragmentProgram, hoặc blend mode ngoài srcOver.
• Render chữ ở cỡ nhỏ — định vị subpixel và hinting khác nhau.
• Màu trên màn hình P3 — xem phần wide gamut ở trên.
• Cạnh clip và khử răng cưa — nhất là clip lồng nhau với góc bo.
• Khởi động trên GPU yếu — đường Vulkan trên Windows và Linux là biến số mới.

Khảo sát Q2 2026 đặt mức hài lòng Windows ở 74% và Linux ở 73% — hai điểm nền tảng thấp nhất sau Cupertino. Desktop là nơi Flutter còn phải bù nhiều nhất, và điều đó có hai mặt: bản phát hành này là một khoản đầu tư thật cho các nền tảng đó, đồng thời cũng là vùng có nền tảng kiểm thử mỏng nhất trước đây.

Báo lỗi cho hữu ích

Nếu bạn tìm thấy hồi quy, đội Flutter cần một bộ dữ liệu cụ thể, và các báo cáo thiếu nó thường bị đứng:

1. Thêm tiền tố [Impeller] vào tiêu đề issue.
2. Ghi cấu hình thiết bị, gồm cả chip chính xác và phiên bản driver GPU.
3. Đính kèm ảnh chụp màn hình hoặc video, lý tưởng là đặt cạnh bản --no-enable-impeller.
4. Đính kèm bản export performance trace đã nén.
5. Nêu phiên bản và channel Flutter từ flutter --version.

Bản so sánh cạnh nhau là thứ giá trị nhất. Nó biến “cái này trông sai” thành một khác biệt render tái hiện được.

Checklist nâng cấp của bạn

1. Build các target desktop trên 3.47 trước khi động vào bất cứ thứ gì khác.
2. Chạy bộ visual regression, hoặc nếu chưa có, đi tay qua năm màn hình phức tạp nhất.
3. So với --no-enable-impeller cho bất cứ chỗ nào trông lạ, để biết renderer có thực sự là nguyên nhân không.
4. Test trên ít nhất một GPU Windows yếu và một bản phân phối Linux bạn không dùng để phát triển.
5. Kiểm tra lại màu thương hiệu trên màn hình P3 nếu bạn ship trên macOS.
6. Mở issue có tiền tố [Impeller] ngay bây giờ, khi fallback còn tồn tại.
7. Đừng ship bản tắt Impeller vĩnh viễn. Hãy ghi nó là nợ kỹ thuật kèm ngày gỡ.

Kết luận

Impeller trên desktop là thay đổi đúng và hơi rủi ro. Mặt lợi mang tính cấu trúc: giật do shader thôi là một loại bug bạn phải săn, và nhịp khung hình trở nên dự đoán được. Cái giá là một lượt kiểm chứng lại toàn bộ lớp hiển thị, cộng thêm một phụ thuộc mới vào chất lượng driver Vulkan trên Windows và Linux. Hãy làm lượt đó ngay bây giờ, khi --no-enable-impeller còn tồn tại để cho bạn biết renderer có phải thủ phạm hay không — vì nó sẽ không tồn tại mãi.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Hệ quả thú vị nhất của Impeller không phải cuộn mượt hơn. Mà là Flutter giờ có một backend render đủ hiện đại để phơi ra một API đồ hoạ cấp thấp — flutter_gpu — và một engine 3D thật đã được dựng lên trên nó.

Giờ khi Impeller là renderer mặc định trên mọi nền tảng trừ web, tầm với của API đó rộng hơn bao giờ hết. Bài này nói về thứ thực sự tồn tại hôm nay, và ranh giới hiện tại giữa “demo ấn tượng” với “ship được”.

Flutter GPU là gì

flutter_gpu là một API mỏng, cấp thấp, đặt trên các nguyên thuỷ render của Impeller — command buffer, render pass, texture, và shader pipeline. Nó không phải scene graph và không phải widget. Nó là tầng bạn dùng khi muốn vẽ thứ mà API vẽ của Flutter không diễn đạt được: renderer tuỳ biến, hệ hạt, hậu xử lý, 3D.

Shader được viết riêng và biên dịch thành shader bundle lúc build, dùng flutter_gpu_shaders và build_runner. Điều đó nhất quán với toàn bộ triết lý của Impeller: trả chi phí biên dịch lúc build, không bao giờ giữa khung hình.

Mô hình tư duy dễ nhớ: CustomPainter cho bạn một canvas, FragmentProgram cho bạn một tầng shader trên một hình chữ nhật, còn flutter_gpu cho bạn cả cái pipeline.

flutter_scene: engine nằm ở trên

Viết code GPU thô không phải thứ phần lớn lập trình viên muốn. flutter_scene — do publisher đã xác minh bdero.dev phát hành, hiện ở 0.20.0 — tự mô tả là một engine 3D thời gian thực linh hoạt cho game và app Flutter, với model glTF, physics, skeletal animation, và ánh sáng PBR.

API có hình dạng đúng như một lập trình viên Flutter mong đợi:

• SceneView — widget bạn thả vào cây để render một scene
• SceneNode, SceneMesh, SceneModel — API widget khai báo cho nội dung scene
• Import glTF lúc chạy, hoặc bản nhị phân .fsceneb đã chuyển đổi trước lúc build
• .fscene làm định dạng mô tả scene, có hỗ trợ prefab

Cặp cuối cùng quan trọng với app thật. Phân tích glTF lúc chạy thì tiện khi phát triển và đắt lúc khởi động; đường .fsceneb chuyển đổi trước mới là thứ bạn ship.

Độ phủ nền tảng bám theo Impeller — iOS, Android, macOS, Windows, Linux — cộng thêm web qua WebGL2, điều đáng chú ý vì bản thân Impeller vẫn chưa có cho Flutter Web.

Thiết lập

Việc thiết lập rắc rối hơn một package thông thường, vì cả native asset lẫn quyền truy cập GPU đều phải bật:

flutter config --enable-native-assets
flutter config --enable-dart-data-assets   # tuỳ chọn, cho DataAssets

flutter create . --platforms=macos,ios,android,linux,windows,web

flutter run --enable-flutter-gpu --enable-impeller

Thứ sẽ chặn bạn lại: flutter_scene hiện yêu cầu channel master của Flutter, không phải stable. Bản 0.19.0 cần một build master từ ngày 09/06/2026 trở đi để có hỗ trợ render-to-mip-level. Đó là dữ kiện quan trọng nhất trong bài này cho việc lập kế hoạch.

Thực sự làm được tới đâu

Các demo cộng đồng là bằng chứng trung thực ở đây, và chúng thuyết phục hơn con số phiên bản gợi ý. Brandon DeRosier — tác giả của flutter_scene — đã trình diễn một Scene Editor chạy trên Flutter 3.47 stable, và một bản port demo Third Person Shooter của Godot: khoảng 617 MiB nội dung đã nấu, 1.795.763 đỉnh duy nhất, 659.079 tam giác duy nhất, và 320 collision mesh, render qua Flutter GPU và Impeller.

Cách anh diễn đạt mới là phần đáng nhắc lại: không fork, không platform view, không ngữ cảnh render phụ. Đây không phải một view Unity nhúng trong app Flutter. Đây là chính stack đồ hoạ của Flutter vẽ ra scene, nghĩa là nội dung 3D và widget của bạn dùng chung một compositor, một ngân sách khung hình, và một pipeline nhập liệu.

Các lập trình viên khác ghi nhận flutter_gpu cộng Impeller render cỡ 20.000 ảnh ở khoảng 120fps trên nhiều nền tảng — mức thông lượng trước đây đơn giản là không diễn đạt được qua tầng widget.

Chọn giữa các tầng

Hãy đọc bảng đó như một cái thang, và lấy bậc thấp nhất giải được vấn đề của bạn. Phần lớn app đòi “3D” chỉ muốn một model sản phẩm xoay được hoặc một hình ảnh hoá dữ liệu, và flutter_scene xử lý thoải mái. Rất ít nơi thật sự cần một engine.

Đánh giá độ chín một cách trung thực

Những điều đúng thật hôm nay: stack đồ hoạ là thật, các con số hiệu năng là thật, và câu chuyện tích hợp — một compositor, không platform view — tốt hơn mọi cách nhúng khác.

Những điều cần cân trước khi đặt cược lộ trình vào nó:

• Yêu cầu channel master nghĩa là không có bảo đảm của kênh stable, không có cửa sổ hỗ trợ dài hạn, và có rủi ro thật là hỏng vào bất kỳ ngày nào.
• Đánh số 0.x nghĩa là API có thể đổi dưới chân bạn.
• Package là dự án cộng đồng của một publisher cá nhân, không phải sản phẩm được Google hỗ trợ. Khảo sát Q2 2026 cho thấy lập trình viên tin các tính năng cộng đồng “thử lửa” ở mức 41% so với 26% cho tính năng do Google xây, nên đó không tự động là điểm trừ — nhưng là mô hình hỗ trợ khác.
• Tooling còn mỏng. Có một Scene Editor, nhưng chưa có gì giống hệ sinh thái của Unity.

Nếu bạn muốn thử

1. Chuyển một project nháp sang channel master. Đừng làm việc này trong repo production.
2. Bật native asset và sinh platform stub bằng các lệnh ở trên.
3. Chạy với --enable-flutter-gpu --enable-impeller và xác nhận bạn có một khung hình trước khi viết code thật.
4. Bắt đầu với flutter_scene, không phải flutter_gpu thô. Thả một SceneView vào và nạp một model glTF.
5. Chuyển đổi trước asset sang .fsceneb ngay khi bạn quan tâm tới thời gian khởi động.
6. Profile trên thiết bị đích tệ nhất từ sớm — công việc nặng GPU làm lộ khác biệt phần cứng nhanh hơn nhiều so với code widget.
7. Ghim commit hash của Flutter trong CI, vì master đổi hàng ngày.

Kết luận

Flutter GPU là bằng chứng rõ nhất rằng Impeller là một khoản đầu tư kiến trúc chứ không phải bản vá hiệu năng. Một lập trình viên đơn lẻ dựng được một engine 3D đáng tin lên trên nó — engine port được demo Godot 1,8 triệu đỉnh mà không cần fork framework — nói lên nhiều điều về cái nền móng hơn mọi release note. Chỉ cần tỉnh táo về hiện trạng: đây là stack chạy channel master, phiên bản 0.x, do cộng đồng duy trì. Hãy nhiệt tình prototype trên nó. Chỉ ship trên nó nếu bạn thoải mái với việc bám theo master.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Flutter 3.47 ra mắt ngày 13/08/2026, và lần này tiêu điểm không phải một tính năng — mà là một cú tách kiến trúc. Hệ thống thiết kế đang rời khỏi SDK. Cộng thêm việc Impeller thành renderer mặc định trên mọi nền tảng desktop và Widget Previews lên stable, đây là bản phát hành có ý nghĩa cấu trúc nhất của Flutter trong nhiều năm.

Con số đứng sau: 1.356 commit từ 169 người đóng góp, 66 người lần đầu tham gia, phát hành dưới dạng Flutter 3.47.0 • Dart 3.13.0 • DevTools 2.60.0.

Material và Cupertino thành package bạn tự chọn

Thay đổi ai cũng đang bàn: material_ui và cupertino_ui giờ là package độc lập trên pub.dev, cả hai đều đạt 1.0. Các thư viện cũ vẫn nằm trong SDK ở thời điểm này, nhưng bản trong SDK đã được lên lịch deprecate chính thức ở bản stable tháng 11.

Vì sao điều này quan trọng hơn vẻ ngoài của nó:

• Design system giờ chạy theo nhịp riêng. Thay vì chờ bản SDK hàng quý, Material và Cupertino có thể ra bản mới hàng tuần. Cupertino đặc biệt cần điều này — xem số liệu khảo sát bên dưới.
• Bạn pin được design system độc lập với phiên bản framework. Nâng cấp Flutter không còn đồng nghĩa nuốt trọn mọi thay đổi widget cùng lúc.
• App không dùng cả hai thì bỏ được cả hai. Nếu bạn ship design system tự viết hoàn toàn, cây Material thôi là dependency bắt buộc.

Việc migrate chỉ một dòng:

dart fix --apply --code=migrate_design_widgets

Cho giai đoạn lưng chừng — app bạn đã migrate nhưng dependency vẫn import đường dẫn cũ — có MaterialUiCompatibilityBridge để hai thế giới còn nói chuyện được với nhau.

Impeller là mặc định trên macOS, Windows và Linux

Impeller thay Skia làm renderer mặc định trên cả ba nền tảng desktop. Lợi ích thực tế giống hệt thứ mobile đã nhận: shader được biên dịch lúc build, nên hiện tượng giật do biên dịch shader biến mất. Trên macOS, wide gamut color cũng bật mặc định.

Vẫn có tuỳ chọn quay lại theo từng nền tảng, nhưng blog nói thẳng rằng các phương án fallback sẽ bị gỡ trong một bản phát hành tương lai. Hãy coi opt-out là cửa sổ để báo lỗi, không phải chiến lược dài hạn.

Widget Previews lên stable

Widget Preview không còn là thử nghiệm. Bản stable thêm cache cục bộ giúp khởi động nhanh hơn và API theme trừu tượng, nên một preview có thể render với nhiều theme mà không cần dựng cả vỏ ứng dụng. Nếu bạn từng thử preview ở bản trước và thấy chậm, đây là bản đáng thử lại.

Cái giá của nâng cấp: tối thiểu iOS 15 và macOS 12

Để hỗ trợ Xcode 27, sàn phiên bản đã dâng lên:

App cũng cần áp dụng vòng đời UIScene để tuân thủ iOS 27. Nếu bạn đã bỏ qua việc migrate này khi 3.44 cảnh báo, đây là lúc nó không còn là tuỳ chọn.

Web: Wasm tiếp tục tiến gần mặc định

Câu chuyện WebAssembly từ lộ trình 2026 vẫn tiếp diễn. Bạn build bằng:

flutter build web --release --wasm

Mới ở bản này: deferred loading thử nghiệm cho Wasm sau cờ --enable-wasm-deferred-loading. Điều kiện tiên quyết vẫn vậy — chuyển khỏi dart:html cũ sang package:web trước khi mong mọi thứ chạy sạch.

Phía plugin, 92 trong 100 plugin iOS phổ biến nhất đã chuyển sang Swift Package Manager. Kỷ nguyên CocoaPods đang kết thúc nhanh hơn phần lớn hướng dẫn nâng cấp giả định.

Khảo sát Q2 2026 nói gì về chỗ Flutter thực sự đau

Google công bố kết quả khảo sát Q2 2026 ngay trong tuần đó — hơn 3.500 phản hồi hoàn chỉnh, thu thập 8–22/06/2026 — và nó đọc như phần ngầm của bản phát hành này.

Tin tốt thì tốt bất thường:

• 93% hài lòng tổng thể, trong đó 58% “rất hài lòng” (tăng 6 điểm so với Q4 2025)
• 83% tin tưởng Flutter đáp ứng được nhu cầu, tăng từ 77%
• Lần đầu tiên, mọi nhóm lập trình viên đều vượt mốc 90% hài lòng

Rồi đến ngoại lệ:

• Cupertino widgets: 61% hài lòng, giảm 6 điểm — mảng bị chấm thấp nhất khảo sát, so với 92% cho Dart, 91% cho Android, 90% cho core framework.

Đó chính là lý do tách Cupertino thành package ra bản hàng tuần là cách sửa, chứ không phải refactor cho vui.

Các điểm đau hàng đầu cũng gọi tên phần còn lại của bản phát hành: độ trưởng thành nền tảng/hệ sinh thái (44%), do độ phức tạp của ma trận phiên bản khi nâng cấp, rồi trải nghiệm tooling và IDE (33%), rồi lỗi và độ ổn định (24%).

Một con số nữa đáng ngồi lại: lập trình viên tin các tính năng đã được cộng đồng “thử lửa” ở mức 41% so với 26% cho tính năng do Google xây, và niềm tin vào Flutter cao hơn niềm tin vào Google hơn 20 điểm (83% so với 62%).

Đường xu hướng AI: agent giờ là quy trình Flutter hạng nhất

Phần AI của khảo sát là tín hiệu rõ nhất về hướng đi của hệ sinh thái. Về mức độ sử dụng:

• Claude Code — 32%
• Antigravity — 23%
• GitHub Copilot — 19%
• Cursor — 18%
• Codex — 17%

Công cụ dạng agent giờ dẫn đầu, vượt thế hệ autocomplete. VS Code (66%) và Android Studio (40%) vẫn là editor mà các agent đó chạy bên trong.

Google đang xây trực tiếp cho xu hướng đó. Skills for Dart and Flutter, công bố tháng 5/2026, là các bộ chỉ dẫn theo tác vụ dạy AI agent cách làm một việc Flutter cụ thể — năm skill đầu tiên phủ integration testing, localization, layout responsive, refactor pattern matching, và đo test coverage. Cách diễn đạt trong bài công bố là mô hình tư duy hữu ích: MCP đưa cho agent bộ công cụ; một Skill đưa cho nó bản vẽ và tay nghề. Chúng nạp dần, chỉ khi liên quan, nên giữ token ở mức thấp.

Vấn đề đang được giải là điều mọi lập trình viên Flutter dùng LLM đều gặp: framework đi nhanh hơn dữ liệu huấn luyện mô hình. Một bản như 3.47, vốn đổi đường dẫn import của hai thư viện được dùng nhiều nhất hệ sinh thái, đúng là loại thay đổi mà mô hình cũ sẽ trả lời sai một cách rất tự tin.

Checklist nâng cấp của bạn

1. Chạy dart fix --apply --code=migrate_design_widgets và chuyển sang material_ui / cupertino_ui trước đợt deprecate tháng 11.
2. Rà soát dependency xem package nào còn import thư viện design trong SDK; dùng MaterialUiCompatibilityBridge trong lúc chờ họ.
3. Nâng deployment target lên iOS 15 / macOS 12 và hoàn tất migrate UIScene.
4. Chạy thử build desktop với Impeller — và báo lỗi ngay khi fallback Skia còn tồn tại.
5. Thử lại Widget Previews nếu bản thử nghiệm từng làm bạn nản.
6. Test một bản build Wasm và xem deferred loading có giúp bundle của bạn không.
7. Trỏ AI agent của bạn tới Dart & Flutter Skills để nó thôi sinh ra import kiểu 3.44.

Kết luận

Flutter 3.47 là bản phát hành mà Flutter thôi là một khối liền. Material và Cupertino thành package bạn tự chọn phiên bản, Impeller hoàn tất cuộc tiếp quản trên desktop, và preview trở thành phần bình thường của vòng lặp phát triển. Khảo sát giải thích chiến lược: mức hài lòng cao gần như mọi nơi, Cupertino là ngoại lệ, và cho design system chạy theo lịch riêng là cách sửa mà không bắt cả SDK làm con tin. Hãy dành một buổi chiều cho việc migrate — nhưng làm trước tháng 11, khi các import cũ bắt đầu cảnh báo.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.