WinUI の歴史とアーキテクチャ

はじめに

Windows 向けのアプリ開発には、これまで数多くの GUI 開発フレームワークが存在してきました。WPF、WinForms、MFC、UWP など、どれを選ぶかは開発者によってさまざまですが、筆者が高校生の時に初めて使い始めて、今も Files などのオープンソースプロジェクトなどで日常的に使い続けているフレームワークが WinUI です。

Windows 10 からはデフォルトの多くのアプリケーションが WinUI ベースの UI へと置き換えられ、OS 全体のデザイン一貫性が大きく向上しました。これにより、「今後の UI フレームワーク は WinUI が中心になる」という方向性が明確になりました（2025 年現在で WebView2 ベースのアプリが急増し、WinUI のパッケージ更新が大幅に少なくなり、ネイティブ UI の投資を軽んじている印象がありますが）。インターネット上には WinUI の誤情報や誤解が多数存在し、評判についてはおよそ好評ではありません。しかし、Windows 上の技術の革新は著しく、最新の Windows の技術について触れておくことは非常に重要です。

この記事では WinUI の歴史に重きを置いて WinUI について説明していきます。内容に不備がありましたらご容赦ください。

ほかの WinUI 関連の記事...

• Qiita (「WinUI」の検索結果)
  • WinUI3開発経緯とその存在意義について
  • 脱WPFを目指してWinUI 3 アプリを調べてみた。(その1)
  • WinUI3でポモドーロタイマーを作ってみよう！#1
  • WinUI3を諦めた話
  • アプリの起動速度を試すとWPFよりもWinUI 3+NativeAOTの方がだいぶ速いようです（ただし0.5秒未満の差）
• その他
  • 【2025年版】WinUI 3とは何か？企業が知っておくべき「できること・できないこと」徹底ガイド
  • WinUI 3 で開発を行うための準備をする
  • WinUI 3 のいいところ

歴史

Windows 7 以前（2009 年）

Windows Vista（2006 年）で WPF（Windows Presentation Foundation） が登場し、Windows の UI 技術は大きな転換点を迎えました。WPF は DirectX ベースの描画エンジンと XAML による宣言的 UI を採用し、従来の Win32/GDI アプリとはまったく異なる設計思想を持っていました。

その後、WPF のコンセプトを軽量化してウェブブラウザ上で動作させるためのプラグイン技術として Silverlight がリリースされます。Silverlight は後に消えてしまいましたが、その UI モデル・XAML 設計思想は Windows の後続技術へ受け継がれていきます。

Windows 8（2012 年）

Silverlight の設計思想を受け継ぐ形で、Windows 8 では Metro/System XAML（コードネーム "Jupiter"）が登場します。これは「Metro スタイルアプリ」と呼ばれる新しいアプリモデルの UI フレームワークで、Windows Phone を強く意識しており、タッチ操作やフルスクリーン表示を前提に設計されていました。

ただし、Metro アプリは「堅牢なサンドボックス」「Win32 API へのアクセス制限」「マルチタスクができない」などの制約が多く、従来の Windows デスクトップ文化とは大きな隔たりがありました。

Windows 10 1507（2015 年）

Windows 10 の初期バージョン（1507）では、Windows 8 の Windows Phone を意識した Metro アプリの開発は UWP XAML （ユニバーサル Windows プラットフォーム）として受け継がれ、XBox や HoloLens などの他のプラットフォームでも使えるようになりました。ウィンドウ化が可能になり、よりデスクトップアプリに近づきましたが、依然として従来のさまざまな制約が残り、UWP への完全移行へは多大なコストがかかりました。

とはいえ、この頃の電卓・設定アプリなどの標準アプリはすでに UWP XAML ベースで実装されており、Windows の UI は着実にモダン化していきます。また、ちなみに Windows 10 の初期の開発において、Windows 設定アプリチームが内部で WinUI 1 として UWP XAML の UI 部分を分離させてライブラリ化し、設定以外のアプリでも使えるようにしていました¹。

2018 年 11 月頃

Windows 設定アプリチームが開発した UI ライブラリ、WinUI 1 はのちに XAML チームへ受け継がれ、WinUI 2 として NuGet パッケージに公開され²、WinUI のソースコードが GitHub に公開されました³。

Windows 10 1903

UWP で問題となっていたのは、その堅牢なセキュリティ制約です。Win32 API などを使用しないアプリケーションは比較的楽に移行できることが予想されていましたが、OS の機能を使う Win32 アプリの開発者は UWP に移行したくても移行できずにいました。

そこで Microsoft は UWP に移行しなくても、最新の UI ライブラリを使用できるような仕組みを開発し始めました。これは「XAML Island」とよばれ、初期の XAML Island v1 は Windows OS に組み込まれた UAP API として機能し、Win32 や WinForms、WPF など Windows 上のどのプラットフォームからでも WinUI 2 を利用できるようになりました。この初期の実装のユーザーからのフィードバックから、XAML Island を使用するためだけに専用の WPF や WinForms といったプラットフォームのプロジェクトを作成していることや、C++ 開発者が MFC の後継として XAML に関心を寄せていたことがわかりました⁴。

2020 年 5 月頃

XAML Island v1 のフィードバックから、専用のフレームワークを作ることにより、XAML Islands のより統一した開発を目指せるようにしました。これは WinUI 3 となり、このソースコードも同じ GitHub レポジトリ上で公開されました。また、UWP の API（UAP API）を Win32 デスクトップアプリケーションでも使用できるように新たな API フレームワークが開発され、Windows App SDK（コードネーム：Project Reunion）と呼ばれました（WinUI 3 は Windows App SDK）。

もう一つ UWP が問題だったのは、そのリリースサイクルです。UWP は Windows OS の一部として出荷されていたため、Windows Update のリリースサイクルに縛られ、緊急のバグ修正があっても即座に反映されませんでした。そのため、この新たな API フレームワークと UI フレームワークは OS から分離（デカップリング）され、NuGet を通してアプリ開発者がすぐアップデートできるようになりました。

2024 年 9 月頃

多大なリソースを投じて UWP / WinUI 2 へ移行した、あるいは UWP で新規にアプリを開発した開発者にとって、Windows App SDK / WinUI 3 という Win32 デスクトップアプリへの再移行は、再び大きな負担となりました。UWP と Windows App SDK アプリでは使用されるコンパイラが異なるため、コードによっては名前空間や参照を更新しただけでは正しく動作しないケースもありました（後述）。また、レガシ UWP が .NET Core 2.0 上で動作していたことから .NET Core 2.0 のサポート終了を受けて、Microsoft はモダン .NET である .NET 9 と SDK スタイルプロジェクトへの対応に着手しました（モダン UWP）⁵。これにより、Windows App SDK / WinUI 3 とおなじコンパイラと開発手法により、移行がはるかに楽になりました。

コンパイラの違い

レガシ UWP アプリケーションは .NET Native コンパイラを使用します。.NET Native は標準で中間言語（IL）ではなくネイティブコードを生成するため、コンパイル時に IL スタブを生成できます。この仕組みにより、アセンブリデスクリプタを使用してトリミング互換を確保することが可能でした。モダン UWP は Windows App SDK と同様にモダン .NET の RyuJIT を使用しますが、ストアに配布する際は AOT コンパイルモードを使用する必要があります⁶。

一方、Windows App SDK / WinUI 3 はデスクトップアプリであるため、モダン .NET の RyuJIT を使用します。Windows App SDK 1.4 / CsWinRT で AOT コンパイルモードにも対応しますが、従来のトリミング互換の手法は使用できません。そのため、リフレクションや既存の組み込み COM Interop は利用できず、ソース生成ベースの P/Invoke（LibraryImport）や COM Interop（GeneratedComInterface）などを使用する必要があります。これは UWP から Windows App SDK への移行の障壁の一つです。

WinUI のいま

WinUI 2 は現在、活発な開発が行われていませんが、WinUI 3 は引き続き開発が進められています。しかし、近年の AI ブームやウェブ開発（PWA、Progressive Web Apps）の影響により、Microsoft 内でネイティブ UI ライブラリへの投資は減少しており、WinUI 3 自体のアップデートも極端に少なくなっています。WinUI 2 の時代には GitHub 上でコミュニティによる貢献が可能でしたが、WinUI 3 ではプロジェクトのビルドすら困難でした。しかし、この状況は 2025 年 8 月の Microsoft プロダクトマネージャの声明により変わりつつあります。2025 年 11 月にはすでにビルドが可能となり、2026 年 1 月末までにコミュニティが貢献できる環境の整備が予定されています⁷。

さいごに

WinUI はバグや WPF とのギャップが多く存在し、パフォーマンスも良いとは言えませんが、このまま最近のコミュニティ貢献に向けた Microsoft の取り組みにより、WinUI が発展していけば Windows の古い UI も徐々に更新され、拡張性やパフォーマンスが大きく改善すれば、と筆者は期待します。

1. https://github.com/gus33000/InteropTools/blob/InteropTools/UI/Microsoft.UI.Xaml-1.17081.170906002-nuget170811709061708.zip ↩

2. https://www.nuget.org/packages/Microsoft.UI.Xaml/2.0.181011001 ↩

3. https://github.com/microsoft/microsoft-ui-xaml/tree/d883cf3593912ded1a1fcc73f38768fda8ee3a45 ↩

4. Miguel Ramos (7/7/2022), "A deep-dive into WinUI 3 in desktop apps", https://blogs.windows.com/windowsdeveloper/tag/xaml-islands ↩

5. Sergio Pedri (9/11/2024), "Modernize your UWP app with preview UWP support for .NET 9 and Native AOT", https://devblogs.microsoft.com/ifdef-windows/preview-uwp-support-for-dotnet-9-native-aot ↩

6. ufcpp (4/3/2014), ".NET Native", https://ufcpp.wordpress.com/2014/04/03/net-native) ↩

7. https://github.com/microsoft/microsoft-ui-xaml/discussions/10700 ↩