お客様から、Xamarin(MicroSoftの開発したiOS,Androidのクラスプラットフォーム)のサポートが2024年5月1日にサポートが切れるため、Xamarinで作られたアプリを別の言語に移植＋画面レイアウトの刷新してほしいとのご依頼をいただきました。
アプリはiOS,Android向けの音声配信アプリです。
移植先の言語には、いくつか選択肢がありましたが、既存コードをある程度流用できればと思い、Xamarinの後継言語の .NET MAUIを選択しました。
開発期間は1月から5月末までの約5か月間。サーバー側の不具合修正も同時に行ったため、.NET MAUIアプリ移植はそのうち3か月ほどになります。
筆者のモバイルアプリ開発経験は、Androidアプリ開発(java, kotlin)約10年、iOSアプリ開発(swift)約2年。他のクロスプラットフォーム開発の経験は無いため、ネイティブアプリ開発に比べて.NET MAUIを選んでよかった点、苦労した点をこの記事にまとめたいと思います。
目次
.NET MAUIの良かった点
言語がC#、画面作成も含めて言語が比較的シンプル
C#言語とXAMLによる画面作成は、昔のjavaでのAndroidアプリ開発に似ていて、ライフサイクルなども無く、言語としてはかなりシンプルです。そのうえ、MVVMアーキテクチャなど比較的新しく、Android技術者に馴染みやすいものもあり、レガシーだがイマドキというレトロゲームのリメイクみたいな言語です。
kotlin, swiftのネイティブアプリ開発が年々複雑になっており、複数人で開発すると知見の差のすり合わせが必要なことも多く、昔のjavaのAndroid開発者や.NETでの業務アプリ開発者など、人を集めやすそうな言語だと感じました。
コード量が減る
これはクロスプラットフォーム全般のメリットですが、コードの共通化は、特にビジネスロジックで影響が大きく、ネイティブで両OS対応する場合に比べ、単純にコード量とテスト量を半分近く減らせます。（DB関連など一部は両OSを別けて対応したため実際は半分よりは多いです。）
逆に、UIについては下記の苦労点で記載にもありますが、共通化による問題も大きいため一長一短です。
Visual Studioが使える
筆者がVisual Studioで初開発だったため、詳しくは伝えられない項目にはなりますが、これまでのVisual Studioと.NETで、開発者にとって慣れ親しんだ開発環境とこれまでの資産やライブラリを活用できるのは、メリットだと思います。
今回利用した限りでは、Visual Studioのコードの静的解析などは他のIDEよりも便利に感じました。
.NET MAUIの苦労した点
.NET MAUIに不具合が多い
.NET MAUIは正式リリースしているにもかかわらず、まだまだ不具合が多い印象です。特にiOSアプリでの一部コンポーネントを使うたびにメモリーリークする不具合がかなり厄介で、サムネイル画像をリスト表示するためのCollectionViewと、画面のモーダル表示なメモリーリークが必ず発生してアプリが落ちていたため、リリース直前で別のコンポーネントに差し替えて対応するということがありました。
また、iOSでの確認（エミュレータ・実機問わず）する際は、WindowsのVisual Studioからmacをリモート接続する必要がありますが、macのOSアップデートやVisual Studioのアップデートの関係で、朝起きたら接続できなくなるなど、目立つ頻度で発生していました。
そのような突発の障害に関しては、同じ問題に遭遇した開発者が、問題を回避する方法をisuuesに記載している場合もありますので、何かあったらisuuesを確認してみるとよいと思います。
https://github.com/dotnet/maui/issues
上述以外にも不具合を上げるときりがなく、アプリをリリースした2024年5月末時点では、商用アプリ開発に.NET MAUIを利用するのは難しいかもしれないというのが正直な感想です。
実際のメモリーリークの検知方法のついては別途記事にしましたので合わせてご確認ください。
「技術ソリューション事例【.NET MAUI#2】MemoryToolkitを使ったメモリーリーク検知」
UIの一部実装が複雑（Android,iOSの個別実装が必要）
UIコンポーネントのうち、XAMLファイルのみでカスタマイズできる場合は問題ないのですが、例えばEntry(入力フォーム)など、AndroidとiOSでデフォルトで見た目が違い、XAMLからカスタマイズしきれないものがあり、それを同じ見た目にしようとするとAndroid,iOSのネイティブの知識も必要になるため難易度がぐっと上がります。
UIの実装については別途記事にしましたので合わせてご確認ください。
「技術ソリューション事例【.net maui#3】EntryをAndroidとiOSで同じ見た目にする」
UI実装後の確認・試験は体感ネイティブアプリよりも時間がかかる
上記の「UIの一部実装が複雑」の項目も含む話になりますが、UIのOS依存する箇所が結構多く、実際にやってみると頻繁に問題が起きて詰まります。
例えば、アプリのツールバーを透明にする修正をする際、Androidの場合、ツールバーの上のシステムバー（時計やバッテリーなどが表示される領域）も透明にしたのですが、iOSの場合、システムバーがコンポーネントとして無かっため、アプリを起動すると無言でクラッシュすることがありました。
それ以降、開発する際は１日１回はAndroidとiOSで実機インストールし、不具合が無いか確認する時間を設けるようにしました。
.NET MAUIにおいてUIが共通コードでかけるのは、確認の手間とカスタマイズの手間が大きくデメリットの方が多い印象です。
IDE(統合開発環境)でAndroid Studio, xcodeが使えない
ビルド環境がAndroid Studio, xcodeでないのは、個人的には地味にきつかった部分で、この評価だけでもflutterやKMP(Kotlin Multiplatform)を選ぶ方がよいといえるかもしれません。
上述の通り、iOSの開発をするためにWindowsの他にmacをリモート接続をする必要がありますが、リモート接続>ビルドの手順の時間的ロスが大きかったです。
また、リリースする際も、特にiOSでは、Visual Studioからパブリッシュに失敗したときの切り分けに苦労することが多いです。ビルドとリリースはネイティブのIDEの方が困ることは少ないでしょう。
ここは、Visual Studioに慣れてるかどうかで評価が逆転する項目だと思います。
ネットに情報が少ない
この記事に挙げた苦労に対しての情報が、日本ではまったく見当たらず、公式ドキュメントとisuuseを見ながらトライアンドエラーを繰り返すしかないのが、今の状況です。
総括
現状ですと、.NET MAUIは不具合が多い言語のため、商用アプリに使うのは難しいのが素直な感想ですが、C#でアプリが作りやすいなどのメリットもあり、不具合が落ち着くことがあれば、言語選定の選択肢として検討の余地はある思います。
今後、言語選定の選択肢に上がったときのために、今回得た知見を、社内にとどまらず一般に共有できればという思いで、今回の記事執筆に至りました。