「なぜ誰もWindowsネイティブアプリを書かないのか」——現役開発者が語る混沌の実態
Chromiumの開発に携わったこともあるベテラン開発者のDomenic氏が、自作のWindowsユーティリティ「Display Blackout」を開発した経験をもとに、Windowsネイティブアプリ開発の現状を赤裸々に語ったブログ記事が、Hacker Newsで400以上のポイントを獲得し大きな反響を呼んでいる。
マルチモニター環境向けユーティリティを作ってみたら……
Display Blackoutは、3画面環境でゲームプレイ中に左右のモニターを「ブラックアウト」するシンプルなツールだ。OLEDディスプレイでは真っ黒な画面を表示することで実質的にピクセルをオフにできる。機能要件は、ディスプレイの列挙、ボーダーレスウィンドウの配置、グローバルホットキー、スタートアップ起動、設定の永続化、システムトレイアイコンの表示——いずれもシンプルに見える。
しかし開発を始めると、技術選択の段階から地獄が口を開けていた。
Windowsプログラミングの「地層」
WindowsのUI開発スタックは、歴史的な地層のように積み重なっている。
- Win32 API（1990年代〜）: C言語ベースの原始的なAPI。今も現役で使われている
- MFC（Microsoft Foundation Classes）: C++でWin32をラップしたライブラリ
- Windows Forms（.NET 1.0 / 2002年）: Win32コントロールのC#ラッパー
- WPF（.NET 3.0 / 2006年）: XAMLによるマークアップとGPUレンダリングを導入した刷新版
- UWP（Universal Windows Platform / 2015年）: Windows 10向けの「次世代」プラットフォーム
- WinUI 3（2021年〜）: UWPのUIレイヤーを切り出したもの
問題は、これらが互いに競合し、それぞれ異なる制限を抱えており、Microsoftが何度も「これが未来だ」と宣言しながら方針転換を繰り返してきた点だ。
UWPという「失われた10年」
特に批判が集中するのがUWP（ユニバーサルWindowsプラットフォーム）だ。Windows 10と同時に登場し、Microsoftが全力で推進したにもかかわらず、サンドボックス制限の厳しさや既存APIとの非互換性から開発者に敬遠され、事実上の失敗に終わった。Win32 APIの多くの機能がUWPサンドボックスから使えず、グローバルホットキーのような基本的な機能の実装にすら回り道が必要だった。
なぜElectronが選ばれるのか
この混沌が、Electron（Webテクノロジーを使ったデスクトップアプリフレームワーク）が広く普及した理由を雄弁に物語っている。VS Code、Slack、Discord——著名なデスクトップアプリの多くがElectronを採用しているのは偶然ではない。メモリ消費が大きいという批判はあれど、単一のコードベースでクロスプラットフォーム対応でき、Web標準という安定した基盤の上に乗れるというメリットは絶大だ。
日本の開発者への示唆
Windowsデスクトップアプリを業務システムとして開発・保守している日本企業にとっても、この問題は他人事ではない。WPFで書かれた社内ツールがWinUI 3へ移行できずにいる、UWPで開発した資産が宙ぶらりんになっているといった状況は珍しくない。Microsoftが「次世代」を何度宣言しても、10年後に同じ問題に直面する可能性は十分にある。
Microsoftには、開発者が安心して長期投資できる一貫したビジョンが求められている。