2012.05.072012年5月3日、RubyMotionがリリースされました。RubyMotionは、Objective-Cに代わる最高の選択肢です。RubyMotionはMacRubyをベースにしており、iOSでのアプリ開発をターゲットにしています。MacRubyでは、iOSを開発する事はできませんでした。Collectorに依存しており、それはiOSでは用いる事ができなかったからです。新しいランタイムは軽量で効率的でなかればなりませんでした。コードがiOS上で動くだけではなく、コンパイラーとやり取りできたり、デバッグやパッケージを作成したりするツールが必要でした。RubyMotionがすばらしい製品であることは、誰も疑わないでしょう。考えるべきなのは、「資金や時間や労力を投じてまで、Appleの言語やツールに取って変えるだけの価値があるのだろうか」ということです。この記事では、良い点とそうではない点を、できる限りバランスよく紹介して、RubyMotionについての理解を深めてもられればと思います。TouchXcode/IDEがないUIの作成デバッガーがないだれをターゲットにしているのか明確ではないドキュメント独占的なソリューション結論RubyMotionの長所RubyであるということObjective-Cもよい言語だと思います。日々改良されてきました。それはRubyではないんです。ヘッダーが必要ですし、Xcodeの設定に縛られながらコンパイルが必要で、テストが面倒で、構文がくどいんです。それにくらべてRubyは柔軟性があり、Mixinを使ってコードを再利用できたり、簡単にクラスを再利用できたり、、。MacRubyRubyMotionはMacRubyをベースにしています。MacRubyに投じてきた時間やエネルギーを、RubyMotionでも生かす事ができるのです。ネイティブAPIについてのワークアラウンドを探しまわる必要もないですし、RubyオブジェクトはObjective-cオブジェクトなので、パフォーマンスも良いです。AppleがMacRubyをiOS向けに採用していないことが残念です。REPL/インタラクティブシェルRubyMotionは現状ではデバッガーを備えていません。Objecgtive-C開発者には使えない、REPLというシミュレーターが使えます。学ぶのにも良いでしょう。ビジュアルで要素をクリックでき、編集するとターミナルウィンドウの中でリアルタイムに反映されていきます。html/cssを編集するのにfirebugを初めて使った時のようなあの感動がよみがえってきます。Xcodeに依存しないXcodeはObjective-Cを書くためにはとてもよいのですが、よくクラッシュしますし、UIが複雑で、Objective-CとRubyが異なる要素を必要とするので、MacRubyの開発でうまく動いたためしがありません。それに、Xcodeはオープンソースではありません。完全にAppleのコントロール化にあり、サードパーティ製のAPIも使えません。メモリー管理ARCはObjective-Cの開発においてメモリ管理を容易にしてくれますが、RubyMotionを使えば、そもそもメモリの心配をする必要がありません。Objective-Cでは未だに自動でメモリ管理をしてくれないのですが、RubyMotionでは自動でメモリ管理をしてくれるCoreFoundationが含まれています。メモリ管理はとても明快で、たいてい素晴らしい働きをしてくれます。RubyMotionの短所RubyであるということRubyが完璧で、唯一の選択肢という訳ではありません。低レベルなAPIを用いる時や、C++とやり取りしなければならない時などは、とても重いということがあります。救いなのは、同じプロジェクト内で、Objective-CとRubyMotionを共存させることができるということです。他にも少々悩まされていることとしては、iOS向けにRubyのコードを書いていると、引数のタイプを強制することができないので、Clangで提供されるObjective-C向けの機能が利用できないということです。そのうち実装されることを夢見ていますが、それは別問題ですね。Rubyを使う上で他のネガティブな要素としては、Rubyの開発者はすべての標準的なライブラリが、RubyMotionで利用できると思い込むだろうということです。RubyMotionではRubyの構文が使えるだけだということを覚えておかなければなりません。率直に言って、ほとんどの標準的なRubyのライブラリは、iOSのアプリを作る上では役に立ちません。MacRubyでアプリを作るときでさえも、ノンブロッキングやマルチスレッドの環境向けに作られたライブラリはほとんど役に立ちません。Objective-Cのライブラリを使います。APIが問題になるのです。これらのAPIはアプリとのやり取りをする上で必要になってきます。APIは他のPythonやRubyやJavaと比べて簡単に思われがちです。APIはとても一貫性があるのですが、学ぶのは容易ではありません。iOSでアプリを作るには、Rubyを知っていたとしても、やはりCocoaも学ぶ必要があります。Xcode/IDEがないIDEは新しいAPIを学ぶ上でとてもためになります。コードを完成させ、素早くドキュメントにアクセスでき、デバックし、インターフェースを作り、再構築する際に、Objective-CからRubyに移行した人は苦労するでしょう。RubyやCocoaを知らないのであれば、RubyMotionを始めるのは非常に難しいですので、まだやめた方がいいと思います。UIの作成もしかするとUIを作成するのが簡単になるかもしれません。DSL上でLaurentを動かせるなら、UIの作成が簡単になるので、そうできるようになる事を期待しています。APIの複雑さもあり、それは非常に面倒な作業でしょう。Xcodeのインタフェースビルダーやストーリーボードで、RubyMotionの開発ができるようになることを皆が望んでいます。デバッガーがないデバッガーがないことは、現状ではやはり問題になります。分かりやすいバグではない場合、特にそうです。だれをターゲットにしているのか明確ではない明確なターゲットが存在しない事を、新しい製品に対して責めても仕方ないのですが、開発者としては、「どんなときにRubyMotionを使えばいいのか、どんな弱みがあるのか」という疑問がやはり生じます。RubuMotionを使えば、素早いプロトタイプを作れるようになるのでしょうか、それとも、プロトタイプが不要になるのでしょうか。Liteアプリケーションに取って代わるものなのでしょうか。新しいアプリを作るために時間を割くべき価値があるのでしょうか。Titaniumで作ったアプリを書き換えるべきなのでしょうか。Objective-Cの代わりにいつもRubyMotionを使うべきなのでしょうか。RubyMotionで作ったアプリがAppストアに並んで、それらを試してみるまで、様子を見たいところだと思います。ドキュメントすべてのiOS向けのドキュメントはObjective-Cで書かれており、Appleが提供しているAPIやサンプルコードはすべてObjective-Cです。2つほどMacRubyの本が書かれておりますが、RubyMotionに関しては、初心者向けのドキュメントとは言えません。じきに増えてくると思うんですがね。独占的なソリューションRubyMotionはオープンソースではなく、Laurentという1人の男にかかっています。彼が辞めてしまったら、またアプリケーションをObjective-Cに書き直さなければなりません。RubyMotionを本格的な製品に使うには、リスクが伴います。私はオープンソースが好きですが、iOSのアプリを作る上ではいつもそれが可能という訳ではありません。いまは選択肢がないのです。LaurentがRubyMotionをオープンソースで運営してもマネタイズできることを願っております。一攫千金したら心が変わってしまうかもしれないですけどね。結論RubyMotionをとりあえず試してみる事を強くお勧めいたします。アプリを作る上で何時間も節約できる事は保証できます。モバイル開発をステップアップしたくてもリスクが気になる方は、金銭的なメリットがあることを考えると動かされるかもしれません。RubyMotionは私の中で、Objective-Cに代わる選択肢です。リリースから48時間しか経っていないので、何とも言えません。言語の壁を超えられるでしょうか、そしてPython,PHP,Java,Objective-C,Javascriptの開発者を引きつけるだけのものがあるでしょうか。RubyMotionアプリの魅力はなんでしょうか。ネイティブアプリとWebアプリの競争に影響を与えるでしょうか。大勢の人をiOSの開発に誘うものとなるでしょうか。時が経たねば分かりません。メリット・デメリットの冷静な分析。[...]返信コメントや質問をどうぞ。可能な限り当日中に返信します。コメントをキャンセルメールアドレスが公開されることはありません。コメントやご質問を投稿してくださった場合,可能な限り当日中に返信いたします。