Flutter - free resource mobile app, desktop, web

macOS 26, named Tahoe, is Apple’s current Mac operating system, and it carries two stories at once. The first is cosmetic and immediate: the Mac now wears Liquid Glass, its biggest design change since 2013. The second is structural and final: Tahoe is the last version of macOS to support Intel Macs. Together they make this a transitional release worth understanding whether you use a Mac or build software for one.

Liquid Glass on the desktop

Apple brought its new translucent material to the Mac, and it goes deep: desktop icons, folders, the Dock, in-app navigation, menus, toolbars, and Control Center all pick up the glass treatment. A transparent menu bar makes the display feel larger, and Liquid Glass sidebars and toolbars reflect and refract the content behind them. Apple also added personalization borrowed from iOS — light, dark, and clear icon tints, plus custom accent and text-highlight colors.

A Phone app on the Mac

One of the more genuinely useful additions is a Phone app for Mac, powered by Continuity, that relays cellular calls from a nearby iPhone. It brings Call Screening, Hold Assist, Live Translation, Recents, Contacts, and Voicemail to the desktop. It is the kind of feature that quietly removes a reason to pick up your phone during focused work.

Spotlight grows up, Launchpad retires

Spotlight is smarter in Tahoe: it surfaces apps, recent and suggested files, actions you can take, and even clipboard history. In exchange, Apple retired Launchpad, replacing it with an App Library–style “Applications” view that organizes apps by category. It is a meaningful change to muscle memory for long-time Mac users.

The Intel cutoff

The most important line for developers is this: macOS Tahoe is the last macOS to support Intel Macs. From macOS 27 — expected in fall 2026 under the name Golden Gate — Intel Macs will not be supported. Tahoe runs on all Apple-silicon Macs plus a small set of Intel models released since 2019.

If you ship a Mac app, this is a planning milestone. Universal binaries and Intel testing have a clear expiry date. Teams can start treating Apple silicon as the sole target for the next major release cycle.

What it means for Flutter and cross-platform desktop

Flutter’s macOS desktop support tracks the current toolchain, and recent releases fully support macOS 26. For teams shipping a Flutter desktop app, Tahoe is a prompt to confirm your builds run cleanly on Apple silicon and to retire any lingering Intel-specific assumptions ahead of the macOS 27 cutoff.

The bottom line

macOS 26 Tahoe is a “look forward, close the door behind you” release. Liquid Glass and the new Phone app modernize the experience, Spotlight becomes genuinely more capable, and the Intel cutoff draws a clean line under a multi-year transition. For developers, the action item is simple: get comfortable on Apple silicon now, because from the next release it is the only game in town.

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

Multi-window is the oldest item on the Flutter desktop wishlist. A desktop app that cannot open a second window is not really a desktop app — no detached inspector, no tear-off panel, no floating tool palette, no proper context menu that escapes the main window’s bounds.

Flutter 3.41 shipped experimental multi-window APIs for desktop. Flutter 3.47 fills in a large amount of the plumbing underneath them. What it does not do is make them stable, and being clear about that distinction will save you a painful quarter.

What actually landed in 3.47

The desktop work in this release is mostly engine-level, and it is substantial:

Popup windows. Win32 and Linux both got popup window implementations. This is the foundation for menus, tooltips, and dropdowns that render outside the parent window’s bounds — a category of UI that Flutter desktop has faked with overlays until now.

Sized-to-content windows. Regular and dialog windows can now size themselves to their content on Win32, and the decorated flag was removed from the windowing API in the process. A dialog that is exactly as tall as its text is a small thing that makes an app feel native.

An API rename. preferredSize became size, and preferredConstraints became constraints. If you have been tracking the experimental API on main, this one will break your code, and the rename is a signal in itself: the team is tidying the surface, which usually precedes stabilisation.

Platform handles are now exposed. The multi-window API can hand you platform-specific window handles — the escape hatch you need for native integration that Flutter does not model.

A public API to post tasks to the platform thread on Windows. Unglamorous, and necessary for anything that has to touch Win32 from Dart.

--flavor support for Windows and Linux desktop builds. Long overdue. Multiple build flavors — dev, staging, production — finally work on desktop the way they do on mobile.

The status you need to internalise

The Flutter team’s own framing on the tracking issue is explicit. The multi-window APIs are experimental, and the stated goals are to build confidence by letting customers dogfood them on Flutter’s main release channel, while retaining the ability to change them.

Both halves of that sentence matter:

• Main channel, not stable. You are not getting these APIs on the stable release you ship from.
• Ability to change them. The preferredSize → size rename in this very release is proof that they mean it.

So what do you actually use today

If you need multi-window in a production app on the stable channel, the answer is still a community package — desktop_multi_window being the most established of them. It creates additional native windows and runs a separate Flutter engine instance in each, with a message channel between them.

That architecture has a consequence worth understanding before you adopt it: each window is a separate engine, so they do not share Dart state. Your Provider, your Bloc, your singletons — none of them cross the window boundary. Everything is message passing:

// Conceptually: each window runs its own engine and entry point.
// Shared state must be serialised across a channel, not read directly.
void main(List<String> args) {
  if (args.firstOrNull == 'multi_window') {
    // Secondary window entry point — separate isolate, separate state.
    runApp(const SecondaryWindowApp());
    return;
  }
  runApp(const MainApp());
}

Design for that from the start. Teams that bolt multi-window onto an app with a single global store spend most of their time reimplementing state synchronisation.

The experimental framework API takes a different approach — multiple windows within one engine — which is why it is the better long-term answer and why it is taking time to get right.

Where desktop stands more broadly

Some context from the Q2 2026 survey: Windows satisfaction is 74%, Linux is 73% — the lowest platform scores after Cupertino. The top developer pain point overall is platform and ecosystem maturity at 44%.

Multi-window is a big part of why. Flutter desktop has been production-capable for years, but the gap between “works” and “feels native” has been filled with missing window management primitives. The 3.47 changes — popup windows, sized-to-content, flavors — are unglamorous and directly target that gap.

A practical plan

1. If you ship on stable today, use a community multi-window package and design for message passing between engines from day one.
2. If you are tracking main, adopt the experimental API now and expect to fix renames each release. The preferredSize → size change is a template for what is coming.
3. Adopt --flavor on Windows and Linux immediately. This one is not experimental and it is a straightforward win for your build pipeline.
4. Audit your overlay-based menus and tooltips. Once popup windows are available on your channel, anything that currently clips at the window edge can be fixed properly.
5. Do not architect around shared global state across windows. Serialise, or you will rewrite it.
6. Test window behaviour on multi-monitor setups with mixed DPI. This is where desktop window bugs actually live.
7. File bugs against the experimental API. Dogfooding is the stated purpose; feedback now shapes what stabilises.

The bottom line

Flutter 3.47 is a serious desktop release even though the headline feature list barely mentions desktop. Popup windows on two platforms, sized-to-content windows, exposed platform handles, and flavor support are exactly the unexciting primitives that separate a port from a native-feeling application. The multi-window API itself is still experimental and still main-channel, so ship with a package for now — but the direction is unambiguous, and the API rename in this release suggests the team is cleaning up ahead of stabilisation rather than still exploring.

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

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.

macOS 26, tên Tahoe, là hệ điều hành Mac hiện tại của Apple, và nó mang hai câu chuyện cùng lúc. Thứ nhất là thẩm mỹ và tức thì: Mac giờ khoác Liquid Glass, thay đổi thiết kế lớn nhất kể từ 2013. Thứ hai là cấu trúc và dứt điểm: Tahoe là bản macOS cuối cùng hỗ trợ Mac chạy Intel. Cùng nhau, đây là một bản chuyển tiếp đáng hiểu dù bạn dùng Mac hay làm phần mềm cho nó.

Liquid Glass trên desktop

Apple đưa vật liệu trong suốt mới lên Mac, và đi khá sâu: biểu tượng desktop, thư mục, Dock, điều hướng trong app, menu, thanh công cụ và Control Center đều mang chất “thủy tinh”. Thanh menu trong suốt khiến màn hình như rộng hơn. Apple cũng thêm cá nhân hóa mượn từ iOS — tông sáng, tối, trong cho biểu tượng, cùng màu nhấn và màu tô sáng văn bản tùy chỉnh.

App Điện thoại trên Mac

Bổ sung thực sự hữu ích là app Điện thoại cho Mac, chạy nhờ Continuity, chuyển tiếp cuộc gọi di động từ iPhone gần đó. Nó mang Call Screening, Hold Assist, Live Translation, Recents, Contacts và Voicemail lên desktop — lặng lẽ bớt đi một lý do phải cầm điện thoại lên khi đang tập trung.

Spotlight lớn lên, Launchpad nghỉ hưu

Spotlight thông minh hơn trong Tahoe: nó gợi ý app, tệp gần đây và đề xuất, hành động bạn có thể làm, và cả lịch sử clipboard. Đổi lại, Apple bỏ Launchpad, thay bằng giao diện “Applications” kiểu App Library sắp xếp app theo danh mục — một thay đổi đáng kể với thói quen của người dùng Mac lâu năm.

Mốc cắt Intel

Dòng quan trọng nhất với dev là: macOS Tahoe là bản macOS cuối cùng hỗ trợ Mac Intel. Từ macOS 27 — dự kiến thu 2026 với tên Golden Gate — Mac Intel sẽ không được hỗ trợ. Tahoe chạy trên mọi Mac Apple silicon cùng một số ít Mac Intel ra từ 2019.

Nếu bạn ship app Mac, đây là mốc lên kế hoạch. Universal binary và kiểm thử Intel có hạn dùng rõ ràng. Đội ngũ có thể bắt đầu coi Apple silicon là mục tiêu duy nhất cho chu kỳ phát hành lớn tiếp theo.

Ý nghĩa với Flutter và desktop đa nền tảng

Hỗ trợ macOS desktop của Flutter bám bộ công cụ hiện tại, và các bản gần đây hỗ trợ đầy đủ macOS 26. Với đội ship app Flutter desktop, Tahoe là dịp để xác nhận bản build chạy sạch trên Apple silicon và loại bỏ mọi giả định riêng cho Intel trước mốc cắt của macOS 27.

Kết luận

macOS 26 Tahoe là bản “nhìn về phía trước, khép cửa sau lưng”. Liquid Glass và app Điện thoại làm mới trải nghiệm, Spotlight thực sự mạnh hơn, và mốc cắt Intel kẻ một đường rõ dưới quá trình chuyển đổi nhiều năm. Với dev, việc cần làm đơn giản: quen với Apple silicon ngay, vì từ bản sau nó là lựa chọn duy nhất.

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.

Đa cửa sổ là món cũ nhất trong danh sách mong ước của Flutter desktop. Một app desktop không mở nổi cửa sổ thứ hai thì chưa thật sự là app desktop — không có inspector tách rời, không có panel kéo ra, không có bảng công cụ nổi, không có context menu tử tế thoát ra khỏi biên cửa sổ chính.

Flutter 3.41 ra mắt API đa cửa sổ thử nghiệm cho desktop. Flutter 3.47 lấp một lượng lớn phần đường ống bên dưới chúng. Thứ nó không làm là biến chúng thành stable, và rạch ròi được điều đó sẽ cứu bạn khỏi một quý đau đớn.

Thực sự có gì trong 3.47

Phần việc desktop ở bản này chủ yếu ở tầng engine, và khá dày:

Popup window. Cả Win32 lẫn Linux đều có bản cài đặt popup window. Đây là nền móng cho menu, tooltip, và dropdown render ra ngoài biên cửa sổ cha — một loại UI mà Flutter desktop tới giờ vẫn giả lập bằng overlay.

Cửa sổ tự co theo nội dung. Cửa sổ regular và dialog giờ tự co theo nội dung trên Win32, và cờ decorated bị gỡ khỏi windowing API trong quá trình đó. Một dialog cao đúng bằng đoạn chữ của nó là chi tiết nhỏ khiến app có cảm giác bản địa.

Một lần đổi tên API. preferredSize thành size, và preferredConstraints thành constraints. Nếu bạn đang bám theo API thử nghiệm trên main, thay đổi này sẽ làm hỏng code của bạn, và bản thân việc đổi tên là một tín hiệu: đội ngũ đang dọn dẹp bề mặt API, thứ thường xảy ra trước khi ổn định hoá.

Handle nền tảng giờ được phơi ra. API đa cửa sổ có thể trao cho bạn handle cửa sổ đặc thù nền tảng — lối thoát bạn cần cho những tích hợp native mà Flutter không mô hình hoá.

Một API public để post task sang platform thread trên Windows. Không hào nhoáng, và cần thiết cho mọi thứ phải chạm tới Win32 từ Dart.

Hỗ trợ --flavor cho build desktop Windows và Linux. Quá muộn nhưng đã tới. Nhiều flavor build — dev, staging, production — cuối cùng cũng chạy trên desktop như trên mobile.

Trạng thái bạn cần thấm

Cách chính đội Flutter diễn đạt trên issue theo dõi là rõ ràng. Các API đa cửa sổ là thử nghiệm, và mục tiêu được nêu là xây dựng độ tin cậy bằng cách để khách hàng dùng thử trên channel main, đồng thời giữ quyền thay đổi chúng.

Cả hai vế đều quan trọng:

• Channel main, không phải stable. Bạn không có các API này trên bản stable mà bạn ship.
• Quyền thay đổi. Việc đổi tên preferredSize → size ngay trong bản này là bằng chứng họ nói thật.

Vậy hôm nay dùng gì

Nếu bạn cần đa cửa sổ trong app production trên channel stable, câu trả lời vẫn là một package cộng đồng — desktop_multi_window là cái phổ biến nhất. Nó tạo thêm cửa sổ native và chạy một instance engine Flutter riêng trong mỗi cửa sổ, với một kênh nhắn tin giữa chúng.

Kiến trúc đó có một hệ quả đáng hiểu trước khi áp dụng: mỗi cửa sổ là một engine riêng, nên chúng không dùng chung state Dart. Provider của bạn, Bloc của bạn, các singleton — không cái nào vượt qua ranh giới cửa sổ. Mọi thứ là truyền thông điệp:

// Về mặt khái niệm: mỗi cửa sổ chạy engine và entry point riêng.
// State dùng chung phải được tuần tự hoá qua một kênh, không đọc trực tiếp.
void main(List<String> args) {
  if (args.firstOrNull == 'multi_window') {
    // Entry point cửa sổ phụ — isolate riêng, state riêng.
    runApp(const SecondaryWindowApp());
    return;
  }
  runApp(const MainApp());
}

Hãy thiết kế theo hướng đó ngay từ đầu. Những nhóm gắn đa cửa sổ lên một app có store toàn cục duy nhất sẽ dành phần lớn thời gian để cài đặt lại việc đồng bộ state.

API thử nghiệm trong framework đi hướng khác — nhiều cửa sổ trong cùng một engine — và đó là lý do nó là câu trả lời dài hạn tốt hơn, cũng là lý do nó cần thời gian để làm cho đúng.

Desktop đang đứng ở đâu, nhìn rộng hơn

Chút bối cảnh từ khảo sát Q2 2026: mức hài lòng Windows là 74%, Linux 73% — hai điểm nền tảng thấp nhất sau Cupertino. Điểm đau hàng đầu nói chung là độ trưởng thành nền tảng và hệ sinh thái, ở mức 44%.

Đa cửa sổ là một phần lớn của lý do. Flutter desktop đã dùng được cho production nhiều năm, nhưng khoảng cách giữa “chạy được” và “cảm giác bản địa” bị lấp bằng những nguyên thuỷ quản lý cửa sổ còn thiếu. Các thay đổi ở 3.47 — popup window, sized-to-content, flavor — không hào nhoáng và nhắm thẳng vào khoảng cách đó.

Một kế hoạch thực dụng

1. Nếu bạn ship trên stable hôm nay, hãy dùng một package đa cửa sổ của cộng đồng và thiết kế theo hướng truyền thông điệp giữa các engine ngay từ ngày đầu.
2. Nếu bạn bám theo main, hãy dùng API thử nghiệm ngay và chuẩn bị sửa các lần đổi tên ở mỗi bản. Thay đổi preferredSize → size là bản mẫu cho những gì sắp tới.
3. Áp dụng --flavor trên Windows và Linux ngay lập tức. Cái này không phải thử nghiệm và là một khoản lợi thẳng cho pipeline build của bạn.
4. Rà lại các menu và tooltip dựa trên overlay. Khi popup window có mặt trên channel của bạn, mọi thứ đang bị cắt ở mép cửa sổ đều sửa được cho đúng.
5. Đừng thiết kế quanh state toàn cục dùng chung giữa các cửa sổ. Hãy tuần tự hoá, nếu không bạn sẽ viết lại.
6. Test hành vi cửa sổ trên thiết lập nhiều màn hình với DPI khác nhau. Đó mới là nơi bug cửa sổ trên desktop thực sự sống.
7. Báo lỗi cho API thử nghiệm. Dùng thử là mục đích được nêu; phản hồi bây giờ định hình thứ sẽ ổn định hoá.

Kết luận

Flutter 3.47 là một bản phát hành nghiêm túc cho desktop dù danh sách tính năng tiêu điểm gần như không nhắc tới desktop. Popup window trên hai nền tảng, cửa sổ tự co theo nội dung, handle nền tảng được phơi ra, và hỗ trợ flavor chính là những nguyên thuỷ buồn tẻ phân biệt một bản port với một ứng dụng có cảm giác bản địa. Bản thân API đa cửa sổ vẫn thử nghiệm và vẫn ở channel main, nên hãy ship bằng package trước — nhưng hướng đi thì không mập mờ, và việc đổi tên API ở bản này gợi ý đội ngũ đang dọn dẹp trước khi ổn định hoá chứ không còn đang dò đường.

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.

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.