日本酒大好きっ子に向けたアプリ、SakeLoverの開発で知るObjectiveC vs RubyMotion

先日、日本酒大好きっ子に向けたアプリ、SakeLoverをリリースしました。ワイン大好きっ子だったのでワインアプリを作ろうとしていたところ、某氏に日本酒の素晴らしさをとうとうと説かれ、改心して日本酒アプリを作った次第です。この記事では、その技術的な裏側の話をしようと思います。

プロトタイピング with RubyMotion

みなさま、RubyMotionという技術をご存知でしょうか？

Rubyという言語でiOSアプリを開発できるビルドツールです。しかもTitaniumなどとは違い、ネイティブ動作するアプリが開発できます。SakeLoverでも開発初期から採用しておりました!

主な採用理由は以下の通り。

  • XCodeなんて知らんがな、ObjectiveCなんて知らんがなという状態でアプリを作ろうとしていたので、渡りに船だった。
  • 出たばかりのRubyMotion、このビッグウェーブに（ｒｙ
  • RubyMotionが出たばかりでライセンスの割引があったのと、期末で会社のお金に余裕があった(重要!)

期待通り、ほぼサンプルのパクりでそれなりのアプリが開発できたので、プロトタイピングにはもってこいでした!

とはいえ・・・

途中で挫折しました。

主な挫折理由

当時はメタプログラミングをサポートしていなかった(今はできる？)ので、黒魔術に限界

ネイティブコードにコンパイルする関係で、method_missingなどを利用したメタプログラミングは難しいとのことでした。少しずつ使えるようになってきているようですが、今はどうなのでしょう。

ビルドが死ぬほど重くて、動作確認に時間がかかりすぎた

今では改善されていると思うし、工夫次第で乗りきれるようになってきたのですが、当時はなかなかイラついていました。i386のマシンでC言語のソースコードをコンパイルしていた時代を思い出すぐらい遅かったです。

デバッグが難しい!　泣ける!

デバッガは途中でリリースされたけど、XCodeで見るのとでは次元が違うので、一旦ハマると抜け出せない感がありました。RubyMotionの問題なのか、単純にコードの問題なのか、切り分けが難しいのも難易度を加速させてしまう気がします。

既存のiOSビルド向けライブラリを使おうとすると、たまにハマったりした

下記のツイートはNYXImageKitをcocoapodsで読み込んで使おうとしてハマったときのツイート。いろいろ大変でした。

その他

あとは、CoreDataとの相性の悪さでしょうか。CoreDataの定義ファイルはXCodeじゃないと触れないし、コードの自動生成も実装コードがRubyだと上手く利用できないですよね。

そんな理由で当初CoreDataを敬遠してNanoStoreを使っていたのですが、通常使っている分には楽なのですが、クエリが複雑だと実機で死ぬほど重いのです。ActiveRecordばりに簡単に使えるORMがあったらとても嬉しいですね！(期待)

直接SQLiteを叩けるFMDBというライブラリもあったのですが、「CoreDataを、CoreDataを使わなきゃいけないんだ！」という脅迫観念に苛まれていて採用できませんでした。

なんだかAppleの標準技術を使わないと死ぬ、という脅迫観念だけがあったような気がするんですが、今冷静に考えると、普通にFMDB使っておけば幸せになれた可能性が高いです。なんという事でしょう、記事を書きながら気が変わってきました。単純にCocoa Touchの世界のことを知らなすぎたのでしょう。

そしてやっぱりObjectiveCで開発リスタートした理由

RubyMotionで開発しているうちにObjectiveCを覚えてしまった(重要)

[[[SomeClass alloc] init] someMessage]みたいな記法が嫌いでObjectiveCを敬遠していたのですが、RubyMotionで開発するにもObjectiveCのコード例を眺めなければならず、結局ObjectiveCの文法を覚えてしまいました。

一方、Cocoa Touchはなかなか習熟できず、ObjectiveCのコード例をRubyに書き直すような作業が続いてしまい、「これなら最初からObjectiveCで書いた方が早いんじゃ・・・」という状況になってしまいました。

ObjectiveCの習熟が早かったのは、そもそもCやC++でコードを書いていた経験があるからかも知れません(過去にGameSDKやDirectXでゲームを作っていました)。

ビルドはやーい！

RubyMotionよりはやーい！

デバッグが楽ですよー！

XCodeのデバッガも、慣れるとなかなか良い奴です。グラフィカルにブレークポイントを張れるのは助かります。

既存ライブラリを再利用する上でハマるポイントが少ない。あったとしても情報がある

そもそもXCodeで使うように作られているものなので、ハマりどころが少ないですね。ハマったとしてもググれば情報があります。ググって情報があることはかなり重要です。僕が天才プログラマなら問題ないですが、そういう訳でもないので。

その他

iOSのバージョンが許せば、Storyboardで見た目を共有しながら、画面ベースで開発を進めることができます。Storyboardを利用した開発は、なかなかに軽快です。

じゃあ、これからの開発でどちらの技術を採用すべきか？

つい最近、37signalsがRubyMotionでアプリを開発したという話がありましたね。

ここまでに書いてきた経緯で、結局はObjectiveCでアプリを書きましたが、今ここで改めて「どっちがいい？」と聞かれても、採用のポイントは悩ましいです。

Cocoa Touchが何となく分かってきたという理由もあって、今ならRubyMotionで生産性を上げられるんじゃないか？　と思う点もあるからです。

iOSアプリ開発が全くはじめての人が生産性を上げられるツールなのかというとそうではなく、それなりに習熟した人が更に開発を加速できるツールなのかなと感じます。一般の人向けには、Rubyで作られたWebアプリ開発フレームワークであるRuby on RailsのようなフレームワークがRubyMotionで出てきて、既存のCocoaの世界と切り離せたとしたら、その時に真のソリューションと成り得るのかな、という気がしています。

という訳で、「これからの開発でどっちを採用すべきか?」という議論では、期待を込めて、あえてのRubyMotion推しです。

なんでもできるよりも、簡単な機能をしっかりと素早く作れる方が、価値があるような気がしています。Rubyにはテストのしやすさや、無駄なコードを書かなくて済む構造の良さがあるので、この長所をしっかりと生かした展開があると良いですね!