自分で分断しちゃったUWPとデスクトップアプリの両環境を
再度結合しようとしているマイクロソフト

　マイクロソフトはオンラインカンファレンスのBuild Windowsで「Project REUNION」を発表した。かなりプログラミング寄りの話なので、今回は誤解を恐れず、大胆な省略と例えを使って解説する。

　「Project REUNION」って、なんかすごいもののようだが、実際には大したことはない。というのも、そもそもマイクロソフトがWindows 8でデスクトップ環境とモダン環境を“分断”しなければ、REUNIONは必要なかったからだ。つまり、自分で2つに分けちゃっておきながら、今になって再結合って言い出しているわけで、例えて言えば、「花瓶割っちゃったので接着剤で付けました」的な話である。

　マイクロソフトがUWPからデスクトップアプリ（Win32アプリ）に回帰しようとしているという話は、本連載にも随分前に書いている（「UWPからデスクトップアプリに原点回帰か」）。

　この記事を書いたのは2018年の11月、XAML Islandsが発表された頃だ。今回のProject REUNIONの最初の動きは、これをベースに従来UWPでしか利用できなかったWinUI（現在のバージョンは2.0）を、次期バージョンとなるWinUI 3.0でWin32アプリケーションからも利用可能にするという話だ。

　WinUI 3.0以前は、無理をすればWinUI 2.0をWin32アプリでも利用できたが、WinUI 3.0では大きな制限なくWin32アプリ側から利用できるようだ。なぜこのタイミングなのかというと、1つには、WinUI 3.0がプレビューできる程度には完成したこと、EdgeのChromium化により、主力ブラウザーがWin32アプリケーションになったことで、WebViewコンポーネントがUWP／Win32の両方で使えるようになったからである。

　WinUIもWin32アプリも同じWPFという技術の上にあるが、実際には、Win32側のUIコンポーネント（XAMLコントロールなどと呼ばれる）とWinUI側のUIコンポーネントは、似たような機能のものがあっても見た目などが大きく違っていた。

　たとえば、Windows 10の設定アプリでよく見かける「トグルスイッチ」（ToggleSwitch）は、同じ機能の「トグルボタン」（ToggleButton）がWin32／WPF側にもある。しかし、スライドスイッチではなく、単にボタンの色が変わるだけのUI部品でしかない。

　同じようなアプリをUWPとWin32で作れば、どう見ても後者のアプリが「みすぼらしい」ものになる。Win32アプリでもWinUIのコントロールが絶対に使えないわけではないし、自分で完全にカスタマイズして同じような外観にすることも不可能ではない。しかし、WinUIを使うのは結構面倒だし、他人の作ったものは評価しないと安心しては使えない。そもそもプログラマーとは基本“怠惰”なので、「UIパーツ」の見た目にそれほど手間をかけたくはないものだ。

　Win32側では、見栄えを良くするには労力を掛ける必要があったのに対して、UWP側は優れた見た目のUIが簡単に作れる。これをUWPの「魅力」として強調することがマイクロソフトのUWP普及戦略の1つだったわけだ。

　だが、よく考えてみると、どちらもマイクロソフトが作ったもので、使わせてくれたっていいじゃないか？ と開発者は思っていた。またUWP自体に制限が多く、Win32アプリでは普通にできたいたことが大体できないか、細かく対象を指定して実行許可をユーザーに求める必要がある。このため、アプリの種類によってはWin32であることが必須という場合も少なくなかった。

じゃあ、そもそもなんで分離するような真似をしたんだ
黒歴史になろうとしているWindows 8

　話は、Windows 8にさかのぼる。いまやマイクロソフトの黒歴史として封印されつつあるWindows 8には、モダン環境とデスクトップ環境の2つのアプリケーション実行環境が作られた。

　このモダン環境用に作られたAPIセットがWindows Runtimeだ。短縮してWinRTとも表記されることがあるが、Windows RTとは違うことだけはおさえておきたい。

　WinRTは、AndroidやiOSのAPIを参考に、カジュアルなアプリケーションを作りやすいAPIとして策定された。それまで使われてきたWin32/64 APIは、WordやExcelのような巨大なアプリケーションを作ることも想定されているため、APIひとつひとつの機能は非常に細かい。Win32/64APIでは細かな機能を自分で組みあわせてどんなアプリにでも作ることができる。

　これに対してWinRTは想定しているアプリケーションを作りやすいようになっているが、どんなアプリケーションにも向いているわけではない。たとえていえば、Win32/64APIは、レゴのようなもので、小さな部品を組みあわせてアプリを作るものだ。これに対して、WinRTはもう少し部品が大きく、ある程度の用途が想定されていて、プラモデルの部品のようなイメージだ。だから、あらかじめ想定したアプリは簡単に作れるが、そうでないものはかなり制限がキツい。量産型ザクのガンプラを買ってきて、シャア専用ザクにするぐらいなら簡単なのだが、ガンダムにするのは大変という感じである。

　ただし、WinRTに関していえば、従来からのWin32/64APIの「置き換え」ではなく併用するものなので、これは、これで意味があった。問題だったのは、モダン環境とデスクトップ環境をほぼ完全に分離したことだ。最初の段階では、モダンアプリとデスクトップアプリでは、テキストのコピー＆ペースト程度が可能な程度で、たとえば、モダンアプリからデスクトップアプリを起動したり、その逆もできなかった。

　つまり、従来のWindowsであるデスクトップ環境の中に完全独立したモダン環境を埋め込んだようなものだった。これは、ストアでアプリを有料販売するということから高いセキュリティを保つというのが理由だった。また、マイクロソフトは、ストアアプリをWindowsアプリケーションの本流と位置付け、その普及に力を入れた。WinRTを普及させ、Windowsのエコシステムをモダン環境側に移行させ、スッキリしたAPIセットの世界に移行することを夢見ていたようだ。

　しかし現実には、ストアアプリは開発者には受けなかった。すでにAndroidやiOSのアプリストアがあり、ビジネスは十分そっちできたため、仕組みがまったく違うWindowsのストアアプリに新規参入する開発者は少なく、また既存の開発者は、Win32アプリを作り続けた。そして、もちろんWindows 8は評価が上がらず、黒歴史と化した。

　これを挽回しようと導入されたのがUWPとUWPアプリだ。こんどは、UWPアプリに対して、スマートフォンやウェブアプリへの可能性を加えた。UWPで開発すれば、すぐにAndroidやiOSのソフトウェアにも簡単に変換できるとして、一石三鳥を主張した。このためにスマートフォンアプリ開発用のプラットフォームのXamalinを買収したり、AndroidやiOSのアプリを簡単にWindowsやWindows Mobileに移植できる「ブリッジ」プロジェクトを発表した。

　また、Nokiaからスマートフォンビジネスを買収し、Windows Mobileのスマートフォンまで自ら提供した。これも夢に終わる。Windows Mobile自体がほとんど普及せず、自社でのスマートフォンプラットフォームは終了した。

　多数のプラットフォームでの動作を目指したため、UWP側には、Windows固有の機能が削除された、“中途半端”なAPIだけが残った。そしてWin32側は、UWPと比べると見劣りするUIコンポーネントのまま、気がつけば、どっちも寂れたプラットフォームになりかかっていたわけだ。すでに台数ベースでは、スマートフォンに抜かれ、タブレット市場でもWindowsは劣勢だ。しかも、GoogleはChromebookでLinuxを動かし、Androidのソフトウェア開発も可能にしようとしている。

　そういうわけで、今やらねばならないことは、まだ多くの開発者がいるWin32デスクトップ環境を「魅力的」なプラットフォームとして復活させることだ。このときマイクロソフトは、2つの分野を足がかりにしようとしている。1つは開発プラットフォームとしてのWindowsだ。

　Windowsアプリはもちろん、組み込みやさまざまな言語など、Windowsを搭載したPCはいまや開発者の標準環境である。これをなんとしてでも守り、さらに拡大させることがWindowsの生き残りにつながる。そこで登場したが、一連の開発ツールとWSLである。VSCodeやWindows Terminalといったオープンソースのソフトウェアは、開発者をWindows上につなぎ止めるために用意されたものだ。今回のBuild WindowsでWSL2のロードマップが示されたのも、この方向を強化するという「メッセージ」だ。

　もう1つは、従来のWindowsとそのユーザー向けのWindowsアプリケーション市場だ。寂れたとはいえ、企業では多数のWindows PCを使って日々仕事をしているはずだし、多くの一般家庭でも使っているだろう。こうしたWindowsユーザー向けのアプリケーション市場にはまだ一定以上の規模がある。Project REUNIONは、UWPアプリ向けの「リッチ」なUIコンポーネントやさまざまな技術をWin32アプリ側に導入し、Win32デスクトップ環境やWin32デスクトップアプリの地位を同等にするためのものだ。

　Windowsの復活は、Win32デスクトップアプリ市場の復活にかかっているといってもいい。マイクロソフトのOfficeしか売れないような市場に「活気」があるとは言えず、新規の開発者の参入が望めなければ、市場としては衰退していくしかない。今年1年でどれだけ変わるか、場末のサンデープログラマーである筆者としてはとても気になるところだ。