2014年のアプリ開発: マルチプラットフォーム対応

2014年の非ゲームアプリのマルチプラットフォーム対応の大本命はXamarinだったと思う。Xamarinのアプローチにはとても共感できる。しかし、2014年僕がXamarinを選択することはなかった。

Titanium的アプローチの問題点

各OS用のUIを共通のコードで実装するというTitaniumのアプローチは結果的にうまくいかなかったと思う。
一つのコードで、各OSのUI思想を尊重した一貫性のあるUIが実現できれば理想的だが、現実的には思想あるいは仕組みの差を統括的に埋めるのには限界がある。結果、各OSごとに意図通りに動かない箇所を見つけては対応する、という作業に追われることになる。特に、その部分がブラックボックス化されていて影響範囲が不明瞭だと、デベロッパーにとってその作業は苦痛なものとなる。そして、この部分に十分な労力がかけられていないアプリは、ユーザとして使っていると操作性が悪くストレスを感じることが多い。だから僕はこのアプローチが好きではない。

 UI部分は共通化しないという方針

Xamarinを使ったアプリ開発で共通化されるのはUIより下の層のみであり、UI層は各プラットフォーム毎にそれぞれ実装することになる。このアプローチでは、コード量は最小ではなくなるが、構造的に無理のないUI開発が可能で、デベロッパーの意図した操作性を実現しやすくなる。だからこのアプローチ自体にはとても共感できる。
経緯こそ違うものの、RubyMotionも結果的に同じ構造でiOS / Android対応できるようになった。マルチプラットフォーム対応アプリ開発環境の中で、このアプローチが採用されるようになってきたのは、良いことだと思う。

サードパーティライブラリの問題

XamarinはIDEも良くできているし、Monoの信頼性もUnityの実績を見る限り問題がないと見て良いだろう。しかし、Xamarinの採用にはまだいくつか問題がある。
Why I Don’t Recommend Xamarin for Mobile Development
上の記事は2013年の記事だが、コードの再利用性の問題や第三の学習曲線の問題など、Xamarinを使う上での問題点がわかりやすくまとめられている。
これらの点に加え、僕が今年Xamarinの使用を見送った理由には「サードパーティライブラリを使えない」という点がある。例えば、Android側のUIを作るときにはottoやButterKnifeを使いたいし、画像処理アプリならGPUImageなどのライブラリを使いたい。ビジネスロジックの実装を共通化できたとしても、外部ライブラリでまかなえていた部分を自前で用意しなければいけなくなる、というマイナスは結構大きい。

今後の期待

Ruby(あるいはRails)におけるGemsのように、Xamarin用のライブラリさえ充実してくれば、Xamarinの強みは一気に強くなる。実際、ButterKnifeの思想をもとに作られたCheeseKnifeなど、ネイティブライブラリ同等の機能を提供するXamarin用ライブラリも登場してきているが、まだまだ数は十分ではない。来年、ライブラリが充実してきタイミングで、Xamarinを使ったアプリを実際にリリースしてみたい。

Tweet

Pocket