変わるWindowsのアプリ戦略 UWPからデスクトップアプリに原点回帰か

変わるWindowsのアプリ戦略 UWPからデスクトップアプリに原点回帰か

  • ASCII.jp
  • 更新日:2018/11/11

UWPのエコシステムは期待したほどに盛り上がらず デスクトップアプリに原点回帰!?

Windows 10が2015年7月に出荷されて以来、早くも3年以上が経過した。しかし、当初マイクロソフトが描いていたような「UWP」によるアプリケーションのエコシステムは、いまだ発展途上にある。

No image

開発中のXAML Island技術では、デスクトップアプリケーションからInkCanvasやInkToolbarのようなUWPコントロールを使うことが可能になるという

Windowsから見れば後発のAndroidやiOSのエコシステムは、すでに十分大きくなったのに対して、明らかに不十分な状況だ。また、Officeを始め多くの主要アプリケーションは、いまだにデスクトップ環境で動作しており、UWP環境のアプリはそれほど使われていない。

こうしたなか、Windowsに関するさまざまな発表を見ていくと、マイクロソフトの方針が変更されつつあることがわかる。簡単に言えば、UWPからデスクトップアプリへのシフトだ。

UWPを諦めたわけではないが、Windowsというプラットフォームのメインのアプリケーションはデスクトップアプリケーションだという“原点回帰”の動きが感じられる。たとえば、マイクロソフトはブログで、「XAML Island」と呼ばれる技術を発表している(https://blogs.windows.com/buildingapps/tag/xaml-islands/)。これは、UWPのGUIをデスクトップアプリケーションで実現するためのものだ。

.NET Frameworkの強化点などでも、デスクトップアプリケーション重視の方向にあり、来年登場予定の「.NET Framework 4.8」では、WinRT APIへのフルアクセスを実現する。

UWP環境とデスクトップ環境についておさらい

詳しい状況説明の前に、簡単にUWP環境とデスクトップ環境についておさらいしておこう。デスクトップ環境は、Windowsが以前から持つアプリケーションの「実行環境」だ。Win32APIや.NET Frameworkなどにより、ウィンドウ形式やコンソール形式のアプリケーションを作ることができる。

これに対してUWPは、Windows 8で搭載されたWinRT(Windows Run Time)APIセットを利用し、かつてメトロやモダン環境と呼ばれた「実行環境」でアプリを実行する。デスクトップ環境とはアプリケーションモデルが違い、実行形式、アプリ構造、ライフサイクルにも違いがある。

たとえば、UWPは最小化などで動作しない状態となった場合、Windowsがメモリから実行イメージを削除できるように作られている。再度フォアグラウンドになった場合には、保存していた実行状態を使って、元の状態に復帰する。このためバックグラウンド処理は、特別な方法で記述しなければならない。これに対してデスクトップアプリケーションは、休止状態でもメモリから勝手に削除されることはなく、特に記述しなくてもバックグラウンドで動作し続けることが可能だ。

UWPで使われるAPIセットであるWinRTは、複数のプラットフォーム(AndroidやiOS、Linux)での動作を想定して、特定のプラットフォームに依存しないよう、これらの最大公約数的なAPIを持つ。これに対してWin32APIは、Windowsの能力を最大限に利用するためのAPIセットになっている。

ただし、WinRTは、アプリケーションを簡単に開発できるように、「粒度」の大きなAPIを持つ。たとえば、「カメラで動画撮影」といった機能を簡単に実現できるAPIだ。これに対して、Win32APIは、さまざまなカメラアプリを作るために必要な「粒度」の小さなAPIを持つ。

WinRTは、セキュリティを重視していること、複数プラットフォームでの動作を想定していることから、Win32APIと比べると、制限があり、すべてのWin32APIが利用できるわけではない。しかし、高機能なAPIが使えることから、GUI部品もそれに対応して高機能なものが用意される。

これに対して、デスクトップアプリケーションは、当初から一部のWinRT APIを利用することができた。また、セキュリティへの懸念から、WinRTが実装されたWindows 8では、モダン環境アプリとデスクトップアプリの間のコミュニケーションは制限されていた。UWPでは、簡易なアプリを作るのは簡単だが、デスクトップアプリで可能だったことがすべてできるわけではない。

デスクトップアプリケーション強化への動きを強める

当初、マイクロソフトは、各種のブリッジソフトウェアを利用することで、AndroidやiOSのアプリケーションを簡単にUWP化してWindows 10へ持ってこられるようにして、アプリケーションの充実を図る計画だった。

そのために、Project Astoria(Android Bridge for Windows)やProject Islandwood(Windows Bridge for iOS)の開発が発表されていたが、Android Bridge for Windowsは2016年に開発中止。Windows Bridge for iOSは、iOS側の開発環境が変わったこともあり、オープンソース化した。

一方で、デスクトップアプリをMicrosftストアで扱える形式に変換する「Windows Bridge for Classic Windows アプリ(Project Centennial)」は残った。しかも、もはやデスクトップアプリケーションを「Classic Windows アプリ」とは呼ばなくなり、「デスクトップブリッジ」「デスクトップAPPコンバーター」といった名称になっている。

デスクトップアプリケーションの配布には、マイクロソフトはほとんど関わってこなかった。このため、いわゆる「フリーソフト」「オンラインソフト」としてインターネットでファイルとして流通が行われ、有償のソフトウェアは自身で販売サイトを立ち上げたり、販売ではなく寄付を依頼するという形式も取られた。

これに対して、デスクトップアプリケーションをMicrosoftストアで扱うことができるAppX形式にパッケージすることが可能になる。これならばデスクトップアプリの流通・販売をMicrosoftストア経由ででき、アップデートなどもMicrosoftストアで可能になっている。

デスクトップブリッジがリリースされたのち、マイクロソフトは段階的にUWPとデスクトップアプリの連携を強化してきた。現在では、UWPアプリからデスクトップアプリを起動したり、相互に連携して動作することも可能になっている。こうした強化は、当初、デスクトップアプリケーションのUWP化を促進するために作られた。デスクトップアプリにUWP的な機能を搭載していくことで、段階的にUWPに移行させるというのが当初のシナリオだったわけだ。

そのシナリオとしては現在も残っているとは思われるが、現実にはUWPへの移行は、それほど進んでいるわけでもない。UWP化が進まない理由の1つは、UWPに課せられた制限やアプリケーションモデルにある。

従来のデスクトップアプリケーションは、ファイルに自由にアクセスし、Windowsの機能を最大限に利用するように作られた。このため、UWPが持つ制限と相容れない部分がある。逆にUWP側は、サンドボックス内での実行という原則があり、なんでもかんでも可能にするわけにもいかない部分がある。たとえばファイルには、ユーザーから許可を得た場合のみ、必要なフォルダ以下のみアクセス可能といった制限がある。

UWP用のGUIを利用し、動作環境などに影響されにくい デスクトップアプリを開発できるように

その点、最近追加されたXAML Islandや.NET Framework 4.8は、デスクトップアプリケーションの強化になるものだ。

UWPは、これまでのWinFormやWPFでの経験を元にGUIフレームワークを作り直している。たとえば、画面サイズや解像度、フォームファクター(スマートフォン、タブレット、ノートPC、デスクトップでは、ディスプレイとユーザーの位置関係が違う)に影響されにくいGUIをデザインできる。

XAML Islandは、UWP用に用意したGUI機能、具体的にはXAMLで記述したGUIデザインをデスクトップアプリケーションから利用できるようにしたものだ。WPFでもXAMLによるGUI記述は可能だったし、利用が推奨されていたが、UWPのものとはオブジェクト構造(記述方法)が違っていた。

.NET Framework 4.8は、現在Windows 10に搭載されている4.7の後継となるもので、「Windows 10(AKA "WinRT")API全般へのアクセス」、「WPFおよびWindowsフォームアプリケーションでUWP XAMLコントロールをホストする機能」(XAML Islandの利用)、「UWPブラウザ(Edge)とメディアコントロールをホストする能力」といった特徴を持つ。また、Windows 10の高DPI対応機能についてもWinFormやWPFが対応する予定だ。

.NETは、Windowsに組み込まれている「.NET Framework」とは別に、オープンソースで更新速度の速い「.NET Core」がある。.NET Coreは、プラットフォームに依存しない.NETの実装で、特定のプラットフォームの事情や細かい互換性を考慮しないため、新機能がすぐに搭載され、更新の速度も速い。

現在では、.NET Coreとその標準ライブラリとなる.NET Standardによりデスクトップアプリケーションの開発も可能になっている。こちらは.NET Frameworkの仕切り直し的な部分があるが、デスクトップアプリケーション側から見れば、アプリケーションモデルの選択が増えた格好になる。

.NET Core 3.0では、WPFやWinFormがサポートされた。また、複数バージョンの.NET Coreを共存させることも可能になり、アプリケーションは、特定バージョンの.NET Coreを使い続けることができるようになった。アプリケーションに.NET Coreを組み込んで出荷することも可能であり、ホストシステム側のバージョンに依存しない実行環境を維持できる。

ARMプロセッサを搭載するWindows On ARMでは、64bit ARMコードによるWin64APIアプリケーションの開発を可能にすると発表している。つまり、デスクトップ環境で動作するARM64アプリケーションが開発できるようになるわけだ。このあたりからも、マイクロソフトがデスクトップアプリケーションを重視しだしたことがうかがえる。

UWPを次世代のアプリケーション環境としてスタートしたWindows 10だが、出荷から3年が経過し状況も変わってきた。デスクトップアプリケーションの強化に方向転換したマイクロソフトだが、開発者の目は、AndroidやiOSに向いたままだ。次にマイクロソフトは何をするのかに注目したい。

この記事をお届けした
グノシーの最新ニュース情報を、

でも最新ニュース情報をお届けしています。

外部リンク

IT総合カテゴリの人気記事

グノシーで話題の記事を読もう!
広告なしで視聴できる「YouTube Premium」が日本上陸!追加料金なしでGoogle Playミュージックも利用可、月額1180円から
Chromeの「後で読む」機能がめっちゃ便利だからみんな使ってみて!
iPhone4s/5/5s/5cが利用不可!au、2022年3月で3Gサービス終了
YouTubeが広告入りで無料の映画提供を始めた、次はAmazonもか?
Instagramで一部ユーザーのパスワードが流出するバグが発生
  • このエントリーをはてなブックマークに追加