Windows(および他のプラットフォーム)開発の未来
キーポイント
原文(投稿日：2021/05/18)へのリンク
2015年にWindows 10が発表された時、Microsoftは、Windows 10の動作するすべてのデバイス上で動作するアプリケーションを開発する新たなフレームワークとして、Universal Windows Platform (UWP)に関する情報も同時にリリースしました。UWPにはアプリケーション開発を容易にするための新機能が数多く提供されていましたが、一方で既存のアプリケーションの移行をほぼ不可能にするような制限もたくさんありました。UWPは失敗し、結果的に採用は広がらず、Windows開発者コミュニティは分裂した状態のままでした。最近になってMicrosoftは、Windows開発者コミュニティを再統合しようという野心的なプログラムとして、Project Reunion(Windows UI(WinUI)を含む)のバージョンリリースを開始しました。今回の記事では、Windows開発者のさまざまなグループが、Project Reunionをどのように導入できるかを見ていきます。また、Project ReunionをUno Platformと併用することで、WindowsアプリケーションをiOS、macOS、Android、Web、さらにはLinuxへと拡張可能にする方法についても確認してみたいと思います。
簡単な経緯
時間を少し遡って、Project Reunionとは何かを説明しましょう。そのためには、さらに前に戻って、その背景や歴史を少し説明する必要があります。Windowsは常に、開発者にとって、サードパーティアプリケーションの開発と配布を可能にするプラットフォームでした。その開発者の使用するツールやテクノロジやフレームワークは、時代とともに発展し、変化していきました。ここでWindowsアプリを開発可能なテクノロジを、すべて紹介しようとは思いませんが、その代わりに、開発者のWindowsアプリケーション開発を、理屈の上からは、容易にするとMicrosotが喧伝している、最近の変化に注目したいと思います。
ここではWindowsアプリ開発の歴史を少し縮めて、Windows Forms(WinForms)から始めたいと思います。WinFormsには(2002年のリリース以来)20年近い歴史があります。簡単に開発を始められるドラッグアンドドロップデザイナが用意されていることから、現在もなお、最も人気のあるアプリケーション開発フレームワークのひとつです。WinFormには一定の制限があるため、Microsoftは2006年、Windows Presentation Foundation(WPF)をリリースしてその修正を目指しました。WPFでは、XAMLで記述されたページレイアウトおよびコントロールと、C#またはVB.NETで記述されたアプリケーションロジックが、明確に分離されています。
Windows Phoneが登場したことで、アプリケーション間を明確に分離可能であることや、クリーンなインストール/アンインストールプロセスを用意することの必要が生じるとともに、アプリケーションがデバイスや他のアプリケーションに対して行えることに制限が設けられました。この結果、Windows Store (後にMicrosoft Storeと改名されました)経由で配布可能なアプリケーション開発の基礎を提供する、Windows PhoneおよびWindows用のSDKが続々と登場したのです。この時期には、Windowsプラットフォームの収束も行われました。Windows 10のリリースに伴って、Microsoftは、携帯、タブレット、デスクトップ、Surface Hub、さらにはXboxデバイス用にひとつのオペレーティングシステムを用意する、と宣言したのです。Windows 10と合わせて、その対象デバイスすべてに対応する単一アプリケーションの開発が可能な、Universal Windows Platform(UWP)も発表されました。UWPではアクセシビリティ、ローカライゼーションなどの組み込みサポートも提供されました。さらに重要なのは、個々のアプリを相互からも、基盤にあるオペレーティングシステムからも分離するという、堅牢なセキュリティモデルが提供されたことです。
レイアウト定義にXAMLを使用し、アプリケーションロジックの定義にC++、C#、VB.NETを使う点はWPFと同じですが、UWPはより広い開発者に採用されることを目標にしていました。すべてのデバイスを対象にした単一アプリケーションを記述可能であるという価値提案は、しかしながら誇大に過ぎるものでした。Windows Phoneが消滅し、Surface Hubのアップデートが滞り、すべてのリビングルームにXboxを配置する計画が失敗したことにより、UWPによるメリットは極めて限定的になりました。その上、UWPの使用には重大な制約がありました。Microsoftが境界を置いた、閉じたサンドボックス内にその実行が限定されていたのです。ほぼ自由にWindowsにアクセスすることのできた開発者たちは、UWPとMicrosoft Storeの設定したこの制限を拒絶しました。
UWPが企業内開発者の間で採用を広げられなかったもうひとつの理由は、開発モデルが非常に厳格に決められていて、企業自身が望んでいた環境管理方法と相容れなかったことでした。WinFormsやWPFであれば、アプリケーションをデプロイする方法は無数にあります。単純にアプリケーションをコピー・アンド・ペーストする(xcopyデプロイメントとよく言われます)ことも可能ですし、その他にも、独自のインストーラを作成する、ClickOnceを使ってアプリとアップデートをデプロイする、単純にダウンロードして実行できるような単一ファイルとしてアプリケーションを生成する、といった方法があります。UWPアプリケーションを開発すると、これらの方法はいずれも使用できなくなるのです。
方向転換
この時点で読者は、一体何が問題なのか、疑問に思っていることでしょう — 確かに、それほどUWPのできが悪いのであれば、なぜMicrosoftは投資をストップして、WinFormやWPFといったテクノロジの方に注力しようとしないのでしょうか？はっきり言いましょう、彼らはまさに、そうしたのです。ですが、その前に、この問題が思うほど単純なものでない理由を見てみましょう。
これまで見てきたように、UWPがWindowsで実行したいアプリケーションすべてには適していない、という理由はいくつもあります。一方でUWPには、基盤となるテクノロジスタックに対する長年の投資の蓄積としての豊富な機能がありますから、おいそれと捨てる訳にはいきません。この中には、XAML UIレイヤ、さまざまなローカライゼーション用リソースを管理する方法、画面解像度とデバイスのファミリ、アプリケーションの停止と再開を効率的に処理可能なアプリライフサイクルなどが含まれています。開発者が自身の選択したテクノロジを離れる意思を持っていないとすれば、Microsoftはこれらの機能をUWPから抜き出して、任意のWindowsアプリケーションで使用できるようにパッケージ化する方法を見付けなくてはなりません。これがProect Reunionの目的なのです。
時間を少し先へ進めましょう。昨年のProject Reunionの発表よりも前、Microsoftは数多くのテクノロジに取り組んでいました。WinFormsとWPFが依然としてUWPよりもはるかにポピュラーである、という事実を認めたMicrosoftは、ゴールポストを移動する作業に取り掛かったのです。WinFormsとWPFの両方にいくつかのアップデートを実施して、旧い.NET Frameworkから.NET Coreへ、さらに.NET 5へのアップデートを経て、将来的には.NET 6に移行しようとしています。事前にインストールされている.NET Frameworkのバージョンに依存しないという意味で、このマイグレーションは重要なものでした。ARM64のサポートも開発中です。これにより、ハードウェアデバイスの新たな波へのサポートが拡張されることになります。
それと並行して、Microsoftは、既存のWinFormsおよびWPFアプリケーションをパッケージしてMicrosoft Storeでの配布を可能にする、新たなパッケージテクノロジであるMSIXを開発しました。また、これを使って、UWPアプリケーションを"完全信頼(full trust)"コンポーネントとすることで、サンドボックスの外に踏み出すことも可能になります — 例えばシステムトレーを操作するような、複雑な作業を行うコンポーネントを構築することができるのです。
さらにMicrosoftは、UWPコンポーネントを既存のWinFormsやWPFアプリケーションに統合するメカニズムを提供するXAML Islandsや、UWP XAMLフレームワークをWindows OSから独立させる次世代のWindows UIコントロールライブラリの開発にも投資しています。これによって、XAMLフレームワークがオペレーティングシステムから独立してバージョンアップ可能になるだけでなく、非UWPアプリケーションでも使用できるようになります。XAMLフレームワークをUWPから独立させてWinFormsやWPFアプリケーションでも使用できるようにするならば、他のコンポーネントと同じ機能を持たせなければならない、という点についても、Microsoftは認識していました。Project Reunionは、UWPコンポーネントをWin32ベースアプリケーションに提供するという目的の達成手段(ship vehicle)になったのです。
ここで私が、"WinFormsおよびWPF"という表現を、"Win32ベースのアプリケーション"に変えたことに気付かれたかも知れませんが、これは現在、WinForms、WPF、UWP以外の新たなタイプのアプリケーションが存在するからです。現時点では"WinUI 3 in Desktop"と呼ばれていますが、Project Reunionがバージョン1.0に到達する頃には、もっとよい名前になっているだろうと推測しています。基本的にWin32アプリケーションである点はWinFormsやWPFと同じですが、WinUIを使って定義されたユーザインタフェースを使用する点が異なります。
Microsoftはまたも、アプリケーション開発用の新たなフレームワークを導入しようというのでしょうか？- そのとおりです。そして、過去に私たちが見てきたような、開発者とツールのフラグメンテーションが繰り返されるのでしょう。違いがあるとすれば — GitHubで行われている議論、Windows Communityの要求、ビルド発表など、すべての背景において、Windows開発者を団結させようという共通目標があるように見られることです。"むちゃくちゃだ"、"また新しいフレームワークを作るつもりなのか"と思ったり、場合によっては大声を上げたりするのは、Windows開発者という立場から見て正しいと言えます。これはMicrosoftの責任以外の何物でもありません。
Windowsアプリケーション開発の展望
それでは、Project ReuionとWinUIのリリースとロードマップを基に、Windowsアプリケーション開発が今後どのようなものになるか、詳細に見ていきましょう。Project Reunionの中心となる信条は、開発に使用するテクノロジが何であっても、Windows 10プラットフォームの持つすべての機能を利用できるようにする、というものだと思われます。この中には、Win32ベースの大量のAPI(Desktop APIなど)やWinRT API(UWP APIなど)も含まれています。アプリケーションライフサイクルや通知の関連するもののような、アプリケーションレベルの機能も含まれるはずです。
Project Reunionは、統合されたAPIセットを通じて、Windowsアプリ開発者を再統合しようという試みである[出典:Windows Blog]
言葉を換えるならば、Windowsアプリ開発の将来的なビジョンは、既存のアプリケーション開発であっても、古いテクノロジを使用しても、新しいアプリケーションを始める場合でも、何ら変わることはありません。Project ReunionのBuilding Awesome Apps for Windows(BAAW)ツールキットを使えば、Windowsプラットフォームのパワーを活用できるに違いありません。
最後の方はちょっと冗談ですが、Microsoftが本気でこのビジョンを売り込みたいのであれば、Project Reunionよりよい名前を考え出す必要はあるでしょう。
このビジョンを説明するために、出発点の異なる開発者にとって、これがどのように見えているのか考えてみましょう。すべてを網羅する訳にはいきませんが、他のシナリオにどのように適用されるのかを理解するには十分だと思います。ただし、これらのシナリオは、現時点でのリリースと、現在発表されているロードマップに基づいた将来予測であることに注意してください。
新しいアプリケーション — これは最も単純なシナリオで、Visual Studioの"Blank App (Windows)"を使って、新たなアプリケーションを作ればよいのです。アプリケーションをパッケージ(Microsoft Store用)にするか、パッケージにしないでさまざまな方法で配布可能にしておくかは、開発者が選択できます。ただし、一部のプラットフォーム(Xbox、HoloLens、Windows 10Xなど)を対象にする時は、コンテナ内の実行や特定のAPI使用の制限といった制約が課される場合があります。
既存のWinForms / WPFアプリケーション — WinFormsおよびWPFアプリケーションで新しい機能を活用するためには、.NET 5に(理想としては、.NET 6 LTSリリースが利用可能になればそちらに)移行する必要があります。移行が完了すれば、Project Reunionへの参照を加えることで、漸次追加される新機能のメリットを享受できるようになります。例えば、アプリケーションにWinUIのコントロールやページを組み込んだり、通知を使用したり、電源管理により優れたアプリモデルを採用したりすることが可能になるのです。つまり開発者は、アプリケーションの一部ないし全体をWinUIに移行するか、あるいはまったく移行しないかを選択可能であると同時に、いずれを選択した場合においても、Project Reunionによって公開されるWindowsプラットフォームの機能を活用することができる、ということです。
既存のUWPアプリケーション — 今日開発されているUWPアプリケーションは、引き続き実行可能なサポート対象となります。ただし、このグループのテクノロジが現在の状態から大きく進展することはないでしょう。従って、Project Reunionに追加されるWindowsプラットフォームの機能を活用するためには、UWPアプリケーションはWinUI 3 in Desktopアプリケーションに移行する必要があります。
UWP以降
最後に挙げたシナリオは、私が前に"Microsoftは今後UWPに投資しない"、と述べたことに関連しています。ここで補足として説明しておきましょう。Project ReunionとWinUI 3のプレビュー版には、"WinUI 3 in Desktop"と"WinUI 3 in UWP"という、2つのプロジェクトタイプがありました。しかし、Project Reunionの0.5リリース時には、"WinUi 3 in Desktop"のみがサポートされていたのです。これに対して、見捨てられたと感じたUWP開発者から大きな反発がありました。
これは、Microsoftが"WinUI 3 in UWP"を提供する上で問題があったためです — "WinUI 3 in UWP"という名称からは、これで既存のUWP開発者がWinUI 2.xの時と同じような方法でWinUI 3コントロールを簡単に統合できるようになる、と考えるのが論理的でしょう。ですが、そうではありません。2つのXAMLフレームワークは本質的に競合しているため、そのように機能する可能性はほとんどないのです。結果として、WinUI 3をデスクトップとUWPの両方でサポートするということは、サードパーティがサポートする必要のある新たなテクノロジが、ひとつではなく、ふたつリリースされるということになるのです。バイナリは共通なのだから、ベンダはコントロールを1回ビルドするだけでよいのではないか、と思うかも知れませんが、問題なのはテストとサポートのマトリクスが制御不可能なほど膨張する点にあります。
Microsoftが"WinUI 3 in UWP"をリリースしてサポートするには、それが開発者にとって大きなメリットを提供するものであることが必須です。現在のWin UI 3はUWP XAML + WinUI 2.xとほぼ同等なので、得られるメリットはそれほど多くはありません。さらに、Project Reunionへの投資は、UWP機能をWin32アプリ開発者が使えるようにするためであって、UWPプロジェクトにとって、Project Reunionが使用可能になることのメリットは皆無なのです。UWP開発者はこのままUWPに留まって、UWPアプリケーションが利用している機能セットをProject Reunionが提供可能になるまでWinUI 2.xの参照を続けるというのが、論理的に考えられる、進むべき方向です。
例えば、基本的な機能を使用したXAMLだけの非常に簡単なUWPアプリケーションであれば、現在にWinUI 3 in Desktopアプリに移行することは可能です。しかし、UWPのアプリケーションライフサイクルや通知といった機能を使用しているのであれば、Project Reunionのバージョン1.0に切り替えられるようになるまで待ちたい、と思うことになるでしょう。XboxあるいはWindows 10Xをターゲットにする必要のある場合は、切り替えの可能なProject Reunionの将来バージョンを待たなくてはならない可能性が大です。これらのプラットフォームの制限により、現時点では、Win32ベースのアプリケーションは実行できないのです。適切な回避手段が開発されるまで、Project Reunionアプリケーションがこれらのプラットフォームで動作可能になることはないでしょう。これがWindows 10Xの、そしてもちろん、2019年にMicrosoftが発表してコミュニティを驚かせたSurface NeoのようなデュアルスクリーンWindowsデバイスの、巷で噂される遅延の一因なのかも知れません。
UWPからProject Reunionへの移行に関して最後に言いたいのは、すべてのUWPアプリケーション開発者は今すぐ検討を開始するべきだ、ということです。製品アプリケーションを実際に切り替えるのは、6か月、12か月、あるいはもっと先のことかも知れませんが、回避不可能である以上、計画は始めておく必要があります。私としては、アプリケーションロジックの大部分を共有ないしマルチターゲットのプロジェクトに移行しておいて、そのプロジェクトを参照するプロジェクトをUWPとWinUI 3 in Desktopの両方で開発する、という方法を推奨します。その上でアプリケーションを段階的にテストして改良し、アプリケーションに必要な機能がProject Reunionに揃ったならば、UWPバージョンは廃止して、WinUI 3 in Desktopバージョンのみを公開すればよいのです。
2021ロードマップ
Windows用アプリケーション開発のビジョンがどのようなであるのかを一通り見てきましたが、では、今現在はどの位置にいるのでしょうか。これについては、WinUI 2021 Roadmapが概要を見せてくれます。Project Reunionのバージョン0.5に合わせたWinUi 3の最初のリリースと、その後いくつかの重大な問題に対処した0.5.5、0.5.6のリリースについては、すでに見てきました。Project Reunionが今後バージョン1.0へと進む中で、移行を望むUWP開発者にとって重要なギャップのいくつかが、さらに克服されていくものと期待できます。この中には、アプリケーションライフサイクル、通知、既存のWinFormおよびWPFアプリケーションをWinUIコンポーネントに統合可能にするXAML Islandなどが含まれます。
WinUIとProject Reunionのロードマップ [出典: Windows UI Library Roadmap on GitHub]
WinFormsとWPFの開発者にとって、Project Reunionの現在のリリースには、簡単に使用できる機能が多くありません。リソース(文字列とイメージ)管理の最新アプローチを実現するMRTCoreも使用できますが、本当の意味でのWinUIのビルディングブロックテクノロジとしては提供されていないのです。WinFormsとWPFの開発者がWinUIの提供する革新的UIを本格的に活用できるのは、1.0リリースが間近に迫って、XAML Islandsが使えるようになるまで待つことになるでしょう。
よく耳にするもうひとつの疑問は、Project Reunion / WinUIと.NETの相互関係です。タイムラインを見れば、Project Reunionのバージョン1.0のリリース予定が、11月に予定されている.NET 6のリリースより前であることに気付くでしょう。このことは、Project Reunionに対してMicrosoftが採用している独立的なアプローチを示しています — Windows 10のバージョンへの依存が最小であるのと同じように、.NETへの依存も最小限に抑えられているのです。Project Reunionのコア機能はネイティブ実装なので、C++アプリケーションと.NETアプリケーションのいずれからも使用することができます。.NET 6によって、Project Reunionアプリケーションはさらなる進化を見せることでしょう。例えば、AOTのサポートを加えるための開発が行われていて、アプリの起動パフォーマンスに大きな影響を与える可能性があります。
マルチプラットフォーム
ここまでの説明では、Windows用アプリケーションを構築する開発者のために、現在および将来的なビジョンを説明することに重点を置いてきました。しかしながら、アプリケーションのほとんどは、他のプラットフォームもターゲットにする必要があります。大部分のコンシューマアプリケーションは、iOS、Android、Webをターゲットにしなくてはなりません。企業アプリケーションでは通常WindowsとWebバージョンが望まれますが、macOSユーザをサポートするニーズも増えてきています。Windowsアプリケーションの開発者としては、そのアプリケーションが他のプラットフォームでも動作すれば最高だと思いませんか？
そこで登場するのがUno Platformです。当初のUnoPlatformはUWPベースのアプリケーションを対象として、そのすべてまたは一部をiOSとAndroid上で動作可能にするためのものでしたが、最近のイノベーションにより、Web(WebAssembly経由で)やmacOS、Linux(SkiaとGTKを使用)、さらには古いバージョンのWindows(SkiaとWPFホストを使用)も対象とするようになりました。さらに、WinUI / Project Reunionアプリケーションの開発を望む開発者もサポートできるようになったことで、すべてのプラットフォームを対象にすることが可能になりました。
WinFormsとWPFを使用する開発者がアプリケーションのパーツにProject ReunionやWinUIを使い始めたように、Uno Platformが他のプラットフォームにどの程度リーチできるかを知ることは重要です。例えば、WinUIを使って新たなページセットをアプリケーションに加えるならば、Uno Platformを使うことで、これらの同じページをすべてのアプリケーションロジックと一緒に、他のプラットフォーム用のアプリケーションとしてパッケージ化することが可能になります。
寄与
今後6~12か月の間に、Windowsアプリケーション構築に関する開発者エコシステムは変わるでしょう。Microsoftはすべての開発者に対して、Windows開発者プラットフォームの将来の促進を支援するように、GitHubを通じたWinUIとProject Reunion両チームへの参画を呼び掛けています。Windowsアプリケーションを開発しているのであれば、Project Reunionがもたらすメリットについて理解すると同時に、Uno Platformを使用して自身のアプリケーションのリーチを他のプラットフォームやデバイスへと拡張することを検討してみるとよいでしょう。
著者について
Nick Randolph氏は、さまざまなテクノロジを駆使したクロスプラットフォーム開発を専門とするコンサルティング会社のBuilt to Roamを主宰しています。氏はWindows他のプラットフォーム用アプリケーション開発に20年以上のキャリアを持つMicrosoft MVP(Windows Development)で、オープンソースプロジェクトやユーザグループ、カンファレンス、ブログ記事などを通じて活動しています。
