planet-green.com

アプリ開発の話。

クライアントさんに泣きつかれて頼まれてXamarinで作られたスマホアプリの修正をすることになり、少しだけ使ってみる機会がありました。

「Xamarin自体がバグだらけ。新しもの好きで人柱覚悟の人ならいいかもしれないけど、仕事ではちょっと怖くて使えない」

これが正直な感想です。

iPhoneとAndroidのアプリを共通のコードで作成できるというのが売りなのですが、実際に共通化できるのはロジック部分だけと考えた方がよさそうです。

一応、画面周りも共通化できるのですが、用意されているXamarin.Formという仕組みでは細かいレイアウトの調整が出来ないので、結局はiOSとAndroidで個別にネイティブの機能を呼び出すコードを書くことになると思います。

Xamarin.Form標準の機能だけだと、デザインの微調整に制限が多く、痒いところに全然手が届きません。

自社または個人で作るアプリならそうしたレイアウトの細部は無視することが可能かもしれませんが、クライアントさんがいる仕事だと、「ここのフォントサイズを変えてね」と言われて断るのは難しいのではないでしょうか。

そして、不具合が多い。

ライブラリを更新したらビルドエラーが頻発したり、iOSで動くコードが何故かAndroidでは動かなかったり(あるいはその逆も)、よくよく調べてみるとXamarin自体のバグで回避策を考えないといけなかったりとか、そんな不具合が多すぎです。

調べても調べても原因がわからなくて、海外フォーラムの片隅に対処法が載っているのをやっと見つけて解決したり。

例えば私が遭遇したケースだと、DisplayActionSheet() でダイアログを表示した後に CrossMedia.Current.TakePhotoAsync() でカメラを起動するとAndroidでは動作するがiOSでは動作せず、丸1日かけて調べた結果、Task.Delay() で間に300ミリセカンドだけウエイトを入れると動くようになりました。もちろんそんなこと公式のドキュメントには書いてないです。

GitHubから落としたサンプルコードを実行しようとしても、大抵はライブラリ関係でビルドエラーになってゲンナリすることに。

Xamarinに詳しい人のブログ等を読むと、「ビルドエラーが出たらライブラリを前のバージョン戻すと動くこともある」なんて書いてあったりしますが、そういうのが積み重なると苦行のようです。

Xamarinを自動車で例えるなら、

「エンジンが止まったらアクセルを2回踏んで7秒待ってから再始動しろ」
「ワイパーを使う時はカーステレオの上あたりをコツンと叩け」

・・のような、他の車に乗る時には全く役に立たないノウハウを経験則として知り尽くしていないと乗りこなせない「じゃじゃ馬」のようです。

今は、そうしたノウハウをここ何年かで蓄積してきた企業や個人がドヤ顔で 「これからはXamarinだ！」 「Xamarinのことなら当社におまかせ！」 と言っている状況で、何のノウハウも無い人が新規参入するなら忍耐と覚悟が必要です。

とはいえ、

「iOSとAndroid、Windows Phoneのアプリを共通のコードで作れるようにする」という理念は素晴らしいと思いますし、プログラマー的には大歓迎です。
おそらく、使いこなせるようになったら素晴らしいツールになるのでしょうけど。

しかし現状を見ると、iOSとAndroidの日進月歩で進化しているAPIに対応しながら、且つ、過去のバグも潰していくには、Xamarin社のリソースが足りてないような気がします。

2016年にマイクロソフトがXamarinを買収したので、これからに期待したいところです。

おそらくマイクロソフトとしては、

Windows Phoneを普及させたい。
↓
でもアプリ開発者がiOS/Androidと比べて圧倒的に少ない。
↓
そこでXamarin。
↓
iOS/Androidのアプリ開発者がXamarinを使うようになれば、「よし、ついでにWindows Phone版もリリースするか」となる。
↓
また、C#を覚えた彼らはWindows（デスクトップ）アプリケーションの開発予備軍にもなる。

・・という思惑があるのではと推測しますが、実際のところはどうなんでしょう？

 

尚、ここで書いたのはあくまで個人の感想です（少し愚痴も入っています）。使う人のスキルや立場によっては異なる見解になると思います。
実際、Xamarinを絶賛されてる方もおられるようですし、それなりに利用者がいるということは、メリットを見いだした人も少なくないという事なのでしょうね。