Windows11時代のデスクトップアプリの状況
先日の6月24日MicrosoftはデスクトップOSの次期バージョンである「Windows11」を正式発表した。
また、同時に現行のWindows10は2025年10月25日にサポートを終了する事も宣言した。
Windows11は新機能も追加されているが、どちらかと言えばWindows10までの古い機能や規格を廃止して、新しい機能や規格だけでデスクトップOSを再構築する側面が強いと、考えられる。
Windows11は新しい機能で大きく重くなるのではなく、古い機能を廃止して軽量化する事が予想される。
これまでWindows10用に開発されてきたデスクトップアプリの規格も整理される可能性が高い。
実際、既に.NET Framework から、.NET Core 系列の.NET5.0と、次期バージョンの.NET6.0のプレビュー版が提供され、旧.NET Frameworkは緩やかに廃止される方向に向かっている。
Windows10のデスクトップアプリにはいくつか種類があり、一般のITエンジニアではない人には、その種類の区別が付きにくい。
この記事では、まずWindows10のデスクトップアプリの種類の解説を行い、次にMicrosoftの進めているデスクトップアプリ改革の解説をする。
それを踏まえて、今後のWindows11で予想されるデスクトップアプリの体系と種類について考察してみたいと思う。
記事はITエンジニアではない、一般のIT素人さん向けに書く。
文体はいつものように「常体」で簡潔に無駄に長くならないように書く。
Windows10のデスクトップアプリの種類
Windows10のデスクトップアプリは大きく二つのカテゴリーに分かれる。
「従来型アプリ」と「UWPアプリ」である。
一般的に広く使われているWindowsアプリはほとんどが「従来型アプリ」である。
UWPはWindows8から始まったアプリの実行基盤で、それまでのWindowsアプリとは実行環境が全く異なる。
アプリを作る側から見ると、「従来型アプリ」と「UWPアプリ」では、「動作するOSが違う」と考えて差し支えないぐらいに異なる。
UWPはその昔「メトロUI」と呼ばれており、Apple社のiPhone,iPadや、GoogleのAndroidに対抗して、MicrosoftがWindowsタブレット端末やWindows Phone を提供するための、アプリ実行基盤として開発したものだ。
「メトロUI」という呼称は著作権の問題で廃止され、今はUWPで通用している。
UWP実行基盤は、Apple社の製品に例えると、iPhoneの「iOS」や iPadの「iPadOS」に該当する。
タブレット端末などに相応しいアプリ実行基盤として開発されている。
操作はキーボードやマウスより指でタッチやスワイプにより操作し易いように設計されており、アプリのマルチタスク性能は「従来型アプリ」より制限されメモリリソースを消費しない仕様になっている。
セキュリティ管理をiPhoneアプリのように厳しくしているため、複数の「UWPアプリ」が互いに干渉できないし、OSの領域にもアクセスできない。
UWPはセキュリティ面で安全だが、ある程度以上複雑なソフトウェアを開発する事ができない。
Windows8からWindows10までのWindowsは、「従来型アプリの実行基盤」と、「UWP」という、まるで「二つのOSが同居している」ような設計のOSになっている。
それぞれのアプリの開発の仕方も全く異なる。
但し、開発言語やライブラリーなどは同じものが、使用できたりする。
それぞれの実行基盤に、一部の同じ規格の道具が提供されている。
C#,XAMLなどによる開発はどちらの基盤でもできる。
さらに詳細なアプリの分類
従来型アプリの中でも、Microsoftだけではない、各ソフトウェアベンダーによる新しい実行環境が提供されている。
主要なWindowsのデスクトップアプリの実行環境には以下の種類がある。
○ネイティブアプリ(Win32,WinRT,WinUI,コンソールアプリなど)
○.NETアプリ(WindowsForms,WPF,コンソールアプリなど)
○Javaアプリ
○サービスアプリ(Win32,WinRT,WinUIなど。.NETもある)
○UWPアプリ
○Xamarin(MAUI)アプリ
○WSL系Linux用アプリ
○Androidアプリ(Windows11以降のみ)
これらの内、「ネイティブアプリ」と「.NETアプリ」と「Javaアプリ」と「サービスアプリ」は、全て「従来型アプリ」に含まれる。
続いて詳細を解説する。
ネイティブアプリ
「ネイティブアプリ」とは最も古くから存在するWindowsアプリの実行環境である。
世間で流通するWindowsアプリのほとんどがこの「ネイティブアプリ」である。
MicrosoftのWord,ExcelなどOfficeもネイティブアプリだ。
C言語やC++、古くはDelphiなどで開発されている。
「ネイティブアプリ」はコンパイラによってマシン語の命令群に変換されて作られた実行ファイルだ。
OSから見るとマシン語の命令群を先頭から逐次実行するだけの単純なアプリだ。
メモリ管理など自動化されていないのでプログラム側でメモリなどリソースを管理している。
GUIアプリもコンソールアプリも存在する。
開発は困難で高い技術が必要であり、生産性は低い。
32bit版と64bit版を厳格に区別する。両者を間違えると動作しない。
Windows用に開発したネイティブアプリはWindowsでしか動作しない、MacやLinuxでは動かない。
「ネイティブアプリ」はWindowsだけあれば動作するので、実行する為に仮想マシンなどの実行環境を別途必要としない。(ソフト部品やミドルウェアを使用している場合は別)
実行ファイルの拡張子はEXEとDLLになる。
ただ、後で紹介する.NETアプリも拡張子はEXEとDLLなので、これだけで区別できない。
.NETアプリ
.NETという実行環境は、その昔サンマイクロシステムズが提供したJavaという仮想マシン実行環境に対抗してMicrosoftが提供した仮想マシン実行環境である。
通常はC#で開発されるが、VB.NETやF#・J#など多数の言語に対応している。
OSの上で仮想マシン(CLR:Common Language Runtime)が稼働し、その仮想マシンの上でアプリが動作する。
実行ファイルは抽象的な仮想CPUのマシン語(MSIL:Microsoft Intermediate Language)にコンパイルされ、実行時に仮想マシン(CLR)により「CPUのマシン語」に翻訳しながら実行する。
アプリが仮想マシンの支配を受けるので、メモリ管理の自動化や、プロセスやスレッドなどの管理の自動化、アプリとアプリの干渉の管理などを、仮想マシンがアプリに変わって行ってくれるので、ネイティブアプリに比べて安全に簡単にアプリを開発できる。
Windows10では.NET Frameworkが主流だったが、Windows11では.NET Core系列の .NET6.0が主流になる。
NET6.0に対応したアプリは、Windowsだけではなく、MacやLinuxでも動作する。
GUIアプリもコンソールアプリも存在する。
ネイティブアプリよりは開発が容易で生産性が高い。
但し専用の技術や機能が豊富でその知識が必要になる。その代わりより多くのことができる。
32bit版と64bit版を区別するが、設定次第でどちらでも動作するアプリを作る事ができる。
実行ファイルの拡張子は基本はEXEとDLLになる。他にも設定ファイルなど色々な拡張子のファイルを必要とする。
.NETは複数バージョンの共存が可能で、.NET Frameworkと .NET Core や .NET5.0 .NET6.0との共存も可能である。
.NET環境は標準でWindowsに組み込まれている。
また、最新バージョンの.NET環境の追加インストールも容易にできる。
Javaアプリ
.NETは、このJavaを参考に開発された。
当初MicrosoftはJavaを一部仕様変更してWindowsに導入しようとしていたが、開発元のサンマイクロシステムズが訴訟を起こして仕様変更を拒否してきたため、独自の仮想マシン実行環境として「.NET Framework」を開発した。
Javaは仮想マシン実行環境の先駆けである。
Java言語で開発され、コンパイルされた仮想CPUのマシン語(byte code)を、CPUのマシン語に翻訳しながら実行する。
現在はデスクトップアプリの実行環境としては少数派で、あまり使用されていない。
しかし、サーバー側の実行環境としてはおそらく企業の業務システムでは最も使用されている実行環境である。
現在ではJava仮想マシンは、業務用のWebアプリのサーバー側の実行環境として広く使われている。
デスクトップアプリの実行環境として、Oracle社のツールなどいくつか使用しているアプリもあるが、少数派である。
Java仮想マシンは現在ではOracle社の製品であり、Windowsには標準装備されていない。
Javaにはいくつか種類があり、Javaをよく知る人でなければ正しいインストールができない。
また、環境変数などの設定で複数バージョンの導入がやや面倒である。
ITエンジニアではない一般の人にはJavaのセットアップは任せられないのが、普通である。
Javaで開発されたアプリはWindows,Mac,Linuxなど、どこのOSでも動作する。
32bit版と64bit版を区別する。
通常はデスクトップアプリの実行環境として選択されない。サーバー側の実行環境としてよく選択される。
大半の一般ユーザーの選択肢には入らないだろう。
サービスアプリ
通常は「サービス」と呼ぶ。サービスアプリとは呼ばれないが、サービスという言葉が広く様々な意味で使用されているので、ここでは他と区別して「サービスアプリ」と呼ぶ。
サービスアプリはUNIXやLinuxでは「デーモンプログラム」とか、省略して「デーモン」と呼ばれる。
画面を持たず、バックグラウンドに常駐起動していて、画面を持つ他のプログラムから呼び出されて、機能を提供するソフトウェアの事を「デーモンプログラム」と呼び、Windowsでは同様のソフトウェアの事を「サービス」と呼ぶ。
通常は「デーモン」や「サービス」には、それと通信する画面を持つ管理ソフトウェアが存在し、管理ソフトウェアを通じて設定変更や起動終了などを操作する。
この「サービス」は実行環境としては、ネイティブアプリと.NETアプリとJavaアプリがそれぞれ存在する。
「サービス」は「従来型アプリ」に該当する。
開発者から見れば「画面を持つアプリ」と「画面を持たないサービス」は本質的には同じプログラムである。画面を表示するかしないかの違いに過ぎない。
Windowsでは「サービスアプリ」は、Windowsの標準ツールの「サービス」というツールで管理する。
Linuxの「デーモン」は、systemctl などのツールを使用して管理する。
「サービスアプリ」は、SQL Server, Oracle, MySQL, PostgreSQLなどのDBMSや、Apache, nginx, tomcat などのWebサービスやアプリケーションサーバーなど、画面を持たないソフトウェアとして開発されている。
Windowsのバックグラウンドには多数の「サービスアプリ」が起動している。
サーバー側のアプリはほとんどが「サービスアプリ」である。
身近な物ならウイルス検索ソフトなどがある。
UWPアプリ
UWPは、Apple社のiPhone, iPad と、Google社のAndroidスマホに対抗して開発されたWindows上の実行基盤である。
Windows内部でも「UWP」は「従来型アプリの実行基盤」とは独立した別のOSのように存在している。
アプリ開発言語は特に決まっていない、C#,C++,JavaScriptなど様々な言語が使用可能である。
.NETと似ているが、直接関係は無い。
UWPで開発したアプリは、「従来型アプリ」と連携するのは難しく、互いに通信するのも一苦労である。
UWPは、Windowsデスクトップ, Windowsタブレット端末, Windows Phone, XBOXなど、Microsoftの様々なデバイスで、同じアプリが実行できるように設計されている。
しかし、Windows Phone はiPhone,Androidスマホとの競争に敗れ消滅した。
Windowsタブレット端末もiPad,Chromebookなどとの競争が激しく、劣勢を強いられている。
実質的にゲームを除くと、市場で通用しているのはWindowsデスクトップとWindowsサーバーだけであり、UWPを必要とする端末はデバイスのレベルで、あまり使用されていない。
UWPはマウスやキーボードによる操作より、指でタッチやスワイプとペン入力などの操作がし易いように設計されている。
また、タブレット端末やスマホなどリソースの少ない端末を活用できるように、機能を削っている。
例えば、マルチタスクだが、UWPは画面を最小化したり、他のアプリに切り替えたりしてバックグラウンドに移行したときメモリ空間から消滅する。
ストレージにメモリ空間のデータを保存してメモリを空けるように出来ている。
これは「バックグラウンドでデータ処理を行う」ようなタスクは実行できない事を意味する。
UWPではサービスは開発できないし、そのような使い方は想定していない。
また、UIは単純な一つの画面で操作するデザインでなければならず、昔のMDIのように複数の画面を持つアプリを作成するのに適さない。(作れないわけではない)
UWPはファイル読み書きなど基本的クラスライブラリーも従来型アプリとは異なるものが用意されていて、アプリの作り方が従来型アプリとは異なる。
繰り返しになるが、UWPはWindowsデスクトップ環境とは異なる独立したOSに近い存在である。
ストレージへのアクセスも厳しく制限され、エクスプローラーのようなファイラーも実質的にはアクセス制限が厳しすぎて開発できない。
無理矢理開発しても使用する度にユーザーにストレージへのアクセス権を付与してもらわなければならないので、実用的ファイラーにならない。
「閉じ込められた実行環境」という呼び名が相応しいと思う。
不自由だが「不正アプリによる悪さ」もやり難い。
他のアプリやネットワークへのアクセスなど全てそのように厳しく制限されるので、UWPでデスクトップ専用のアプリを開発するのは不便である。
だから、Windowsアプリの開発者(社)は皆UWPを使用しないで「従来型アプリ」を開発する。
制限の厳しさはセキュリティ面では安全性の向上に繋がるので、厳格なセキュリティを必要とする単一画面のアプリには良いと思う。
ゲームとか動画配信サービスやSNSやECには良いかも知れない。
サーバーとの通信は通常はソケットを使用する。
gRPCやREST-APIやWCFなどは使用できない。
配布はMicrosoft Storeで行うか、同一の機構を使用して「サイドローディング」という仕組みで社内配布などを行う。
従来型アプリのように自由にダウンロード配布は出来ない。
不自由だが規制が厳しく安全でもある。
現在、Microsoftは従来型アプリとUWPの開発用に「WinUI3」という新しい規格を導入しようとしている。
これを導入すると従来型アプリとUWPアプリで同じクラスライブラリーを使用して開発する事ができる。
従来型アプリとUWPアプリの開発の仕方を統一しようといているのだ。
今のところ、UWPの独立性を廃止する話は出ていない。
しかし、私にはUWPの将来の方向性に「迷い」のようなものを感じる。
今後、UWPをどのように活用しようとしているのかMicrosoftの将来方針が見えてこない。
詳しくは「Project Reunion 0.5」を参照。
将来追加されるのWindowsアプリ
従来のWindows10までは、これまでに説明した従来型アプリ基盤とUWPだけが実行基盤の全てになる。
これからMicrosoftはAndroidタブレット端末の開発に本格的に参入する。
少し前からMicrosoftはWSL(Windows Subsystem for Linux) という、Windows環境でLinux環境を動作させる仕組みを導入している。
Windows11ではAndroidアプリが稼働できるようになる。
Windows11では新機能の導入と旧機能の廃止が行われる。
これらの変化の流れから、今後Windows環境に登場するか、これから広まるかも知れない実行環境の解説をする。
Xamarin(MAUI)アプリ
Xamarin(ザマリン)とは、.NETを使用してAppleのiOSや、GoogleのAndroid用のアプリを開発し実行する実行基盤である。
Windows10で稼働するアプリではない。
従来ならXamarinをWindowsデスクトップアプリに含むことはなかった。
しかし、Windows11ではAndroidアプリが稼働できるようになる。
Androidアプリを開発できる開発環境は、Java,Kotlinなどいくつかあるが、その一つにMicrosoftが提供しているXamarinがある。
Xamarinは、開発言語としてはC#になる。
Windows11でAndroidアプリをMicrosoftが提供するとしたら、常識的に考えて開発環境はXamarinを積極的に提供してくる、と考えるのが自然だと思う。
XamarinはMicrosoftが完全に支配しているので、その仕様はMicrosoftが自由に変更したり拡張したりできる。
「WindowsでもAndroidでも稼働するアプリ実行基盤」は、
今は存在しないが、Microsoftがその気になれば作る事は容易だ。
現在、MicrosoftはMAUI(Multi-platform App UI)というXamarinの後継規格らしきものを発表している。
このMAUIのカバーする端末やデバイスがもう少し明確になるとUWPの位置づけもハッキリしてくると思う。
現時点では分からないが、将来的にはUWPを無実にして、代わりにXamarinをスマホやタブレットやデスクトップなどで、デバイス横断的に使用できる実行基盤として提供してくるかも知れない。
このタブレット端末のOSはAndroidである可能性が高いと思う。
WSL系Linux用アプリ
MicrosoftはWindows10のUpdateの途中から、Windows上でLinuxを手軽に実行できるWSLという実行基盤を提供している。
バージョンアップを繰り返し、現在はLinuxのGUIアプリも動作するようになっている。
サービスアプリに該当するデーモンプログラムは動作しない。
しかし、Dockerコンテナや、Hyper-V仮想環境にUbuntu Serverなどをインストールしてそちらでデーモンプログラムを稼働させて、WSLから通信すれば問題無く使用できる。
つまり、現時点でほぼLinuxアプリはWindowsデスクトップで動作するようになっている。
LinuxアプリをWindows環境で活用する事ができるということだ。
現状はWSLを活用したソフトウェア製品は存在しないが、将来的には出てくるかも知れない。
WSLは主にLinuxサーバー側ソフトウェアの開発環境としての活用が予想できる。
Androidアプリ(Windows11以降のみ)
Windows11ではAndroidアプリが稼働できるようになる。
Xamarinではない通常のAndroidアプリもWindows11で稼働するようになる。
もし、ITベンダーが開発コストを最小減にして、iPhone,AndroidスマホとタブレットとWindowsデスクトップで稼働する製品を開発するとすれば、フロント側はiOSとAndroidだけ開発して、Windows用アプリは開発しない選択肢も有り得る。
今後は業務システムの現場でも、システム開発コスト削減のためWindowsPCでAndroidアプリの業務システムを使用して仕事をするようになるかも知れない。
Windowsデスクトップアプリのこれまでの経緯
Windows8以降のMicrosoftのデスクトップアプリ戦略は、一言で言えば「スマホやタブレットとの戦い」だったと言える。
AppleのiPhone,iPadとGoogleのAndroidスマホへの対抗手段としてMicrosoftはWindows8のメトロUIをリリースした。
メトロUIは現在のUWPの事である。
メトロUIはWindowsの中で独立したOSのように構築され、スマホやタブレット端末用に、タッチやペン入力での操作に特化したUIとして設計された。
つまりMicrosoftはデスクトップパソコンとタブレット端末を同一の端末内に構築した。
一方、GoogleはAndroid端末とは別にChromebookを提供していた。
これはPCとして提供していたが、アプリとシステムの大半をクラウド上に配置したため、端末内のソフトウェアは軽量となり安価で物理的にも軽量なPCとなった。
このChromebookは消費者からはPCとしてではなく、タブレット端末として受け入れられて普及していった。
MicrosoftもSurfaceというPC型のタブレット端末を提供していた。
当初はUWP(メトロUI)での使用を想定してSurfaceを提供していたが、消費者はPCとしてデスクトップパソコンの機能を使用していた。
UWPはあまり活用されなかった。UWPアプリもほとんど開発されなかった。
iPadはペン入力型タブレット端末として広く普及した。
この三者の展開によりタブレット端末は、iPadのようなペン入力型タブレット端末と、ChromebookやSurfaceのようなキーボード入力型タブレット端末の二種類の製品に分かれたと、私は思う。
iPadとChromebook を用途別に併用する人もいる。
両者は明らかに異なるタブレット端末となっている。
Surfaceも明らかにキーボード入力型タブレット端末として消費者に受け入れられており、iPadの競合にはなっていないように見える。
両者は別の種類の製品である。
ハードウェアの進歩はWindows10を軽量なモバイルPCで快適に動作させるレベルに到達している。
こうなるとUWPの存在意義が失われる。
当初はUWPアプリの配布をメインにしていたMicrosoft Storeも、その後デスクトップアプリも配布できるようになり、UWPの存在感が低下しているようにも見える。
現在、Microsoftはこれまで「UWP」と「従来型アプリ実行基盤」と「Xamarin」のOSとのAPIの部分の仕様を統一しようとしている。
アプリがOSの機能を呼び出すクラスライブラリをWinUI3という規格に統一する事が計画されている。
Windowsデスクトップアプリのこれから
Microsoft社も「Surface Duo」というAndroidタブレット端末を発表した。
Windows11ではAndroidアプリが稼働できるようになる。
Androidアプリのサーバー側の実装はLinuxで行われる。
Windows10ではしばらく前からWSLを実装しており、まだ開発段階だが、Windows環境でLinux用ソフトウェアの開発が出来るようになってきている。
以上の事実から推測するに、MicrosoftはAndroid端末をペン入力型タブレット端末市場に投入し、キーボード入力型タブレット端末市場は通常のデスクトップOSのWindows11で市場制覇を狙う方針であろうと思う。
iPhone,iPadに対してはAndroid端末を、Chromebookに対してはWindows11を競合させて行くつもりだろう。
元々、iPadに対して、Windows10のUWPは、全く対抗できていなかった。
一方でキーボード入力型タブレット端末では、ハードウェア性能の進歩で通常のWindowsデスクトップOSで、充分に快適に動作する状況が生まれている。
この状況だとUWPの存在感はない。XBoxとアプリを共有できる点だけだろう。
Microsoftは、おそらくペン入力型タブレット端末はAndroidとXamarin(MAUI)アプリを主軸に変更し、UWPは競争前線から退くことになると思う。
キーボードタブレット端末では、古い機能を削除して軽量化したWindows11を主軸にしてChromebookに対抗するだろう。
主なアプリはUWPではなく、「従来型アプリ」である。
そしてオフィスなどで使用されるデスクトップパソコンも大半がWinodws11になる。
企業で働く人にはWindows11以外の選択肢はないだろう。
以上のことから、UWPにはゲーム以外の将来性はないと思う。
HoloLens などの今後の展開で採用される可能性も否定しないが、今のところUWPの出番はしばらく無いと思う。
今後のWindowsアプリの主役は、従来型アプリとXamarin(MAUI)アプリの二つになると思う。
また、Kotlinなど他のAndroid開発環境も無視できない。今より盛り上がると思う。
Androidのアプリ実行環境はJavaVMである。
JavaVMも無視できないということになる。
AndroidアプリがMicrosoft製品の主流の仲間入りをするなら、サーバー側のLinuxも仲間入りすることになる。
だからWSLに注力しているのだろう。
纏めると、
フロントエンド側は従来型アプリとAndroidとXamarin(MAUI)アプリ・JavaVM+Kotlinに、
バックエンド側はWindows Server, Azure, Linux(WSL)という構成が、
今後のMicrosoftのアプリ開発環境の主流になると思う。
全てに共通してC#(.NET6.0)が使用できる点も陰の要点だと思う。
(注意: MAUIの詳細は不明ですがC#は使用できるでしょう)
以上、Windowsアプリの種類の解説と、その将来の変化の予想でした。
最後まで、お読みいただきありがとうございます。
