CONTENT
こんにちは、エンジニアのKです。今回はMAUIについての個人的所感です。
研究開発のPJで数か月インターバルを挟みつつ、計半年ほど触った感覚です。
★MAUIとは
ひとまずMAUIとはなんぞやというところですね。
マウイ島（マウイとう、Maui）は、アメリカ合衆国ハワイ州（ハワイ諸島）の・・・ではなく、
.NET MAUI（.NET マルチプラットフォーム アプリ UI）
C#とXAMLを使用してネイティブモバイルおよびデスクトップアプリを作成するためのクロスプラットフォームフレームワークです。
引用：https://learn.microsoft.com/ja-jp/dotnet/maui/what-is-maui?view=net-maui-9.0
Xamarinの後継ですね。ひとつのコードからAndroid、iOS、macOS、Windowsで実行できるアプリの開発が可能なのが一番の特徴です。WindowsはWinUI、macOSとiOSはswift、AndroidはJavaみたいにPJも言語も分けて開発する必要はありません。
ひとつのコードベースでひとつのアプリ、そんな奇跡のような魔法のようなフレームワーク。みんなはっぴーです。奇跡も魔法もあるんだよ。
★仕組み
なぜMAUIなら上記4つのOSで動作するのか。
答えは簡単で、MAUIのAPI使ってコードを書けば、MAUIがビルド時に各ネイティブプラットフォーム用APIに解釈しなおしてくれます。
MAUIでLabalと書いたら、WinにはWin用のLabel、macOSにはmacOS用のLabelを使ったと解釈してくれる、みたいな感じですかね。つまり、ビルド結果がOSの数だけあるんですよ、MAUI。
★利点
ここまで書いたら明白かもしれませんが、ひとつのコードベースで4つのOSに対応出来ることです。
単純計算で1/4のコード量で4つのアプリが作れます。テストは流石に全プラットフォーム個別で必要ですが、業務ロジック部分などは差異が出にくい部分です。
上手くやればOS毎の差異はUI絡みだけで済むかもしれません。知識もC#とXAMLだけでいいので、JavaもSwiftもみたいな欲張りスキルセットが要求されません。
HTMLのノリで取り組むと痛い目見がちなXAMLですが、実質C#の構造化テキストと考えればそこまで難しくはないです。なので、C#出来るならある程度即戦力でアサイン出来るのも魅力ですね。
あとは.NETなので豊富なライブラリ群の恩恵を受けやすいです。.NET Standard準拠のライブラリなら「ある程度」使えます。MicrosoftLeanが充実しているのもありがたいですね。
機械翻訳チックではありますが、慣れれば公式ドキュメントとしては読みやすい部類に入ります。とりあえず英語読まなくていいのは楽でいいです。
★短所
だったらこれだけ使ってればいいよねとはなりません。クロスプラットフォームの代償は重いです。
下手するとコード一元化のメリットなんて吹き飛ぶほどの重さです。
1.バグ多い
正式にリリースされてからまだ3年経ってません。当然、フレームワーク起因のバグは大量にあります。
gitのissues3.7kは伊達じゃありません。winFormsは655とかです。流石に比べるのはかわいそうですが。
5、6画面のアプリを作って、5件くらい遭遇してます。大抵は迂遠な方法で回避するか、仕様変更で回避するかになります。
2.当然ライブラリのバグも多い
有償無償問わず、MAUIのライブラリもバグが多いです。細かいことやりはじめるとなんか一つは出てくる印象です。困ったことに、原因がMAUIなのかライブラリなのかの判断が付かないことも多いです。
3.バグの解析に時間がかかる
上記の1、2はあくまでも自分のコードが合っている前提です。
つまり、このコードは正しいはずだけど、なんか期待通り動かないことに対して解析と理由付けが必要になります。ライブラリのコード覗きに行く日常の始まりです。
4.画像処理が絡むと辛い
WindowはGDI+で画像処理してますが、macにそんなものありません。互換性あるとされてたgdiplusは正式にmicrosoftから見捨てられています。
SkiaSharpあたりを使うことになりますが、こちらも怪しいです。svg画像を生成するときに使ったライブラリで「テストしてないけど多分動くよ！」みたいなこと書いてるのもありました。
動かなかったですね。普通にフォントのグリフ関連の座標の処理が間違ってました。
これのせいで印刷用PDFにsvg画像が使えず、画質がいまいちなものになりました。これはホントに鬼門だと思います。
画像加工したり生成したりをメインでするならMAUI使うのは一旦考えた方がいいです。
.NET Standard準拠のライブラリなら動くとありますが、macで使えないけど.NET Standardだよみたいなこと言ってるライブラリもいるので注意が必要です。
5.インストーラーが曲者
インストーラーの作り方は全プラットフォーム別々です。まぁ、これは仕方ないところではありますが、如何せん参考文献の少なさに悩まされることになります。ストアに出さず、野良アプリ形式で行こうとすると特に厳しいです。
macOS関連はAplleから公証貰わないとインストール出来ません。Winも証明書周りをきっちりやらないとインストール出来ません。
そもそも、msxi形式がデフォルトなので、exeとかで配布してみたいな感じではないです。（出来ないこともないですが、現状は現実的ではない）iOSとAndroidは未経験ですが、たぶん苦戦します。
6.ビルドにMACが必要
mac用のアプリを発行するのにmacが必要なので、結局macは必要です。xcodeのversionに.NETが引っ張られるので、xcodeも必要です。xcodeのバージョンアップにmacOSのversionも必要です。つまり、古いmacだと厳しいです。
いまだとmacOS14以上は必要だった気がします。これは仕方ないですね・・・
7.MACだと明らかに動作が遅い
Windowsで動作させているとき比べ、何故か動作がワンテンポ遅く感じます。
なぜだ......
8.重たいことするのに向いてない
正直なところ、Windowsでも動作は軽くないです。数万点の点を打つグラフを14個くらい生成するのに10秒くらいかかります。
ライブラリによっては5GBくらいメモリ食いつぶしてクラッシュします。特にイベント管理はしっかりしないと参照リークが多発します。これはMAUIに限らずですが.NET系はイベントのsubscribeが原因になってることも多いです。
止まらないのでそろそろお開きにします。
★今後
散々言いましたが、Xamarinのサポートが打ち切られる以上、Xamarinで作ってたアプリの移行先はおおよそMAUIで決まりだと思います。
単純な動作をさせるだけならMAUIは最適解かもしれませんし、細かいところで重宝されるかもしれませんね。WebAPI投げて取得結果表示するだけみたいなアプリとかが向いてますかね。グラフも多少ならイケると思いますが、マシンパワーの要求値は高めです。
ちなみに、BlazorHybridというBlazor＋MAUIという胸やけしそうな組み合わせもあるみたいです。
興味があればぜひ。