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

宣伝
Files という、WinUI でエクスプローラーの代替アプリケーションを開発するプロジェクトにリード開発者（Lead dev）としてチームに参加しています。是非、ダウンロードしてみてください。

はじめに

Windows 向けのアプリ開発には、これまで数多くの GUI 開発フレームワークが存在してきました。WPF、WinForms、MFC、UWP など、どれを選ぶかは開発者によってさまざまですが、筆者が高校生の時に初めて使い始めて、今も Files などのオープンソースプロジェクトなどで日常的に使い続けているフレームワークが WinUI です。これは従来の Win32 プラットフォーム上から最新 UI を使え、WinRT のプロジェクションサポートのある言語であれば開発することができます（公式は C++/WinRT と C#/WinRT のみ）。

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

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

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

• Qiita (「WinUI」の検索結果)
  • WinUI3開発経緯とその存在意義について（AI を使った記事のため誤情報に注意）
  • 脱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 部分を分離させてライブラリ化し、Groove Music などの設定以外のアプリでも使えるようにしていました¹。

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 Islands」を開発しました。初期の XAML Island v1 は Windows OS に組み込まれた UAP API として機能し、Win32 や WinForms、WPF など Windows 上のどのプラットフォームからでも WinUI 2 を利用できるようになりました。この初期の実装のユーザーからのフィードバックから、XAML Islands を使用するためだけに専用の WPF や WinForms 等のプロジェクトを作成していることや、C++ 開発者が MFC の後継として XAML に関心を寄せていたことがわかりました⁴。

2020 年 5 月頃

XAML Island v1 のフィードバックから、C++ と C# 共通で、WPF や WinForms 経由ではなく、独立した専用のフレームワークを作ることにより、XAML Islands のより簡素な開発を目指せるようにしました。これは WinUI 3 の一部となり、このソースコードも同じ GitHub レポジトリ上で公開されました。また、従来 UWP 専用で提供されてきた API（UAP API）を Win32 デスクトップアプリケーションでも使用できるように、「Windows App SDK（コードネーム：Project Reunion）」と呼ばれる新たな API 群が開発され、WinUI 3 はこの Windows App SDK の一部として出荷されています。

また、もう一つ UWP が問題だったのは、そのリリースサイクルです。UWP は Windows OS の一部として出荷されていたため、Windows Update のリリースサイクルに縛られ、緊急のバグ修正があっても即座に反映されませんでした。そのため、この新たな API フレームワーク Windows App SDK + WinUI は 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.6 / CsWinRT 2.1 で AOT コンパイルモードにも対応しましたが⁷、RyuJIT の AOT モードでは IL スタブは生成しないため、従来のトリミング互換の手法は使用できません。そのため、リフレクションや既存の組み込み COM Interop は利用できず、ソース生成ベースの P/Invoke（LibraryImport）や COM Interop（GeneratedComInterface）などを使用する必要があります。

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://blogs.windows.com/windowsdeveloper/2024/09/04/whats-new-in-windows-app-sdk-1-6 ↩

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