Microsoft has recently announced a significant enhancement in the performance of WinUI 3, the current native framework for Windows applications. According to Beth Pan, the lead software engineer, there has been a notable 25 percent improvement in the performance of File Explorer components that utilize this framework. The data shared indicates a reduction of 41 percent in memory allocations and a 45 percent decrease in function calls. However, Pan cautioned that some of these optimizations may involve breaking changes, which will be optional for developers initially. The intention is to eventually make these enhancements the default in future iterations of WinUI and the Windows App SDK, with the option to opt out when necessary.
Performance Challenges Persist
Despite these advancements, the announcement carries a bittersweet undertone for developers who have long grappled with performance issues associated with WinUI 3. While Microsoft touts it as a native framework, many argue that this characterization is somewhat misleading. WinUI 3 is built on WinRT (Windows Runtime), a component interface that has been in use since Windows 8, which acts as an intermediary between application code and the more traditional Win32 API. This distinction raises questions about the true native nature of WinUI 3.
One of the key advantages of WinUI 3 lies in its support for Fluent UI, the design system that embodies the Windows 11 aesthetic. Developers can achieve the modern look and feel of Windows 11, but at the cost of optimal performance. As one developer aptly noted, “WinUI 3 is currently measurably slower than both WPF and UWP… this is NOT OK.” Another echoed the sentiment, stating, “you can’t build a WinUI app and call it smooth at the same time.”
Industry Perspectives
Concerns regarding WinUI 3’s performance are not isolated. Component vendor DevExpress has also weighed in, highlighting that while the architecture of WinUI components holds promise for rapid rendering and animation, the reliance on WinRT interop for each component action significantly hampers speed. This presents a challenge to Pavan Davuluri’s aspirations for enhanced performance in Windows 11 through increased utilization of WinUI 3, unless the framework itself undergoes substantial improvements, as Pan suggests.
Another persistent issue among Windows developers is the inconsistency with which Microsoft’s developer division’s frameworks have been embraced by the Windows and Office teams. Historical tensions date back to the early development of “Longhorn,” the code name for Windows Vista, which faced significant rework due to performance concerns with .NET, leading to a lingering skepticism about its reliability within the Windows team. A developer remarked, “What you need to do is actually use your framework across the company,” to which Pan responded, asserting that “that’s the push.” While this reassurance is welcomed by WinUI 3 developers, the complex history of Windows UI frameworks suggests that a cohesive and lasting company-wide strategy may remain elusive.
